Summary

Initially, this document was intended to guide tagging resources in AWS Prod Account (grid-ace-prod). So, whenever the Infra team is willing to provide any resource in AWS should refer to this document first for tagging guidance for those resources.

During this edition, we aim to revise our tagging strategy and use the best practices guided by this aws white paper.

General Conventions

This part describes general conventions on tagging strategy and limitations.

Based on this aws document, here are the general limitations, but they may vary between the resources:

• Each resource can have a maximum of 50 user-created tags.
• The tag key must be a minimum of 1 and a maximum of 128 Unicode characters in UTF-8.
• The tag value must be a minimum of 0 and a maximum of 256 Unicode characters in UTF-8.
• In general, the allowed characters are letters, numbers, and spaces representable in UTF-8, and the following characters: _ . : / = + - @.
• There is a total maximum of tag characters of 2048 characters.

Here are our general policies:

• All tags key/values are lowercase, with no spaces (use -), and are delimited by :.
• Each tag key consists of at least two parts: <purpose>:<tag_name> that is like cost:budget-team or opts:owner.

Use Cases

This section describes the identified use cases of resource metadata by multiple stakeholders. Use cases are classified into X categories as follows.

• Finance/Cost: Use cases provided by project owners and budget management.
• Governance/Compliance: Use cases provided by IMO and other compliance providers.
• Development: Use cases provided by development teams.
• Operations: Use cases provided by the infra team to ensure observability, monitoring, automation, etc.
• Access Control: Uses cases provided by the infra team to ensure correct access controls are in place.

Finance and Cost

This is placeholder

Governance and Compliance

The purpose part: comp I have a question here:

• What is an IMO approval?
• Who decides on these?

Currently, the only use-case I can think of is tagging S3 buckets based on the dataset, such as sensitive, psudo-anonymized, anonymized.

The other is the dataset type public, internal, or licensed.

Development

We might even drop it, but this is just a placeholder.

Operations

We must decide on our operation’s use cases and requirements. Here are some that come to mind at the moment. This document is intended to be revised multiple times during the next few months, and then we should have regular revisions, maybe every two quarters.

• Specify the environment (dev/qa/prod)
• Specify the terraform workspace
• Specify operations owner
  • The operations owner is responsible for the maintenance and support of the resource. This comes from use cases of advanced teams, such as IMO, who need administrator access over their ec2 instances.
• Specify monitoring dashboard
• Specify logs location
• Allows adding extra optional tags for operational needs of some resources, such as patch-level for ec2 instances
• Specify the Expiration date.

Access Control

We use access control tags to annotate which teams have access to a specific resource. Whenever possilbe, we prefer to manage access using AWS ABACS; however, these tags are required even when ABACs are not implemented for the spcefic use-case.

The following are the requirements that we aim to implement:

• Access must be granted to teams, not specific users.
• Support multiple levels of identity (team | function | org | all | public) [not-implemented]
• Allow multiple levels of access (read/write/user/admin)
• Allows adding a specific level of access to multiple identities (admins: infra,data-engineering | write: some-ai-team | read: gRED)
• Enables delegation of control decisions to other teams
• Allows extra specific controls over some resources such as s3 buckets, FileSystems, and EKS.
• Allows service account access management as well:
• We don’t want to give team A access to an ec2 instance with write access to an s3 bucket for which team A is not authorized.

Tags defined in this context

All access control tags on resources have the prefix ac: while all identification tags on roles have the prefix id: to determine the identity of the role. Whenever possible we implement policies via abacs granting access to resource. Here are the generic tags proposed to use:

Note that for some resources we use different tags as they make more sense. Please refer to the specific resource access control page for more information. Principal tags:

We agreed upon adding the following tags to all principal (user roles and service roles). The values for id:team and id:function should come from the CIDM Roles and Groups sheet.

• id:team: Identifies the team.
• id:function: Identifies the function.
• id:app: Identifies the application. (only for service-roles created from applications)
• id:department
• id:organization

Resource tags:

The ac:owner tag should only contain one specific team. Any other resource tag is a delimited string containing any combination of team, function, department, and organization. NOTE: We define the default delimiter as :; since some resources may not support :, the delimiter for these resources must be clearly specified in its documentation.

The infra and the ac:owner teams are the only teams with access to changing these tags.

Please refer to specific access control tags for each resource.

Resource Specific Docs

You can use the Access Control Template to write consistent reference documents on implementation of access controls.

Here are the references for resources with access controls defined:

• EC2 Instances
• S3 Instances

Deprecated Tag Definitions/ Verbiage for tag values

• Enterprise: Options are Roche or Genentech. Used to identify which entity requests the infrastructure

• Organization: The organization under the enterprise that will be billed for the resource. Examples, gRED or pRED

• Department: The department under the organization that will be billed for the resource. Examples, ECDi, Research Biology, etc

• Function: The function under the department will be billed for the resource.

• Team: The team that will be billed for the resources being used (Cost tag). In some cases, this will be the same as the function if that department has only one function and one team

• Requestor: The stakeholder or manager for the project

• Application: The application being deployed. If there is no application, leave blank.

• Component: The component of an application. This can be worker nodes, backend notes for API, frontends, etc. If an application is not being deployed, the component becomes the infrastructure technology, for example, S3, RDS, etc.

• Project: The name of the project that the infrastructure is supporting. This should be collected from the team.

• WBS Code: This was supposed to be used for budgeting but cannot be used.

• Environment: The environment of the application or infrastructure. This can be dev, test, or prod.

• Ansible: Boolean value if Ansible is being used or not.

• Terraform: Provide the link to the Terraform Cloud workspace used to build the infrastructure. Terraform Workspaces should follow the following naming standard [team/owner]-[application]-[component]-[environment]-[region]

• Version: Version of terraform being used.

• Public: Boolean value, is the resource accessible from the Internet or not.

• Dataset: The name of the dataset being used with the resource. This does not always apply to storage infrastructure. For example, if an EC2 instance accesses a specific dataset, then the Dataset tag for that EC2 instance would have the name of the dataset. If there are multiple datasets being accessed, then the value for this tag becomes each dataset name delimited by a comma. If it is not applicable add N/A

• Expiration: Data of when the resource will expire if it is short-lived. Set to never for resources that never expire.

Valid Team tag values

To find list of valid team tag values please check CIDM roles and groups sheet.