- Bowdoin Tagging Standards
Page moved to Confluence: https://bowdoin.atlassian.net/wiki/spaces/ITKB/pages/2164589/Cloud+Tagging+Standards
Cloud resources can have metadata assigned to them in the form of tags. Each tab is a label consisting of a user-defined key and value. Tags are used to help manage, identify, organize, search for and filter resources. Tags can be created to categorize resources by purpose, owner, environment, or other criteria.
Each tag has two parts:
- A tag key (such as
costcenterorenvironment). - A tag value (such as
1234556orprod).
This document provides an overview and definition of tags required by Bowdoin College and the standards for those keys and value that are expected. This is not meant to prevent other tags from being created but intended to create a baseline of common tags. Should a new tag become required, it should be added to this document.
In order to maintain consistency between platforms and different people creating tags, the following naming standard is recommended for all tags, defined or custom.
- Valid characters are
a-z,0-9, and-(dash) - Only lowercase letters will be used
- Spaces will not be used; a dash must not be used to separate words only sections of a tag value
- Namespaces will not be used to prefix Bowdoin tags; tags without a prefix are assumed to be in Bowdoin namespace
- Prefixes may be added to third party tags (i.e., AWS)
- A key should not be longer than 63 characters
- Unless specified, valid characters are
a-z,0-9, and-(dash) - Hungarian notation may be used with long names to help improve clarity
- Unrelated values will be placed in separate keys
- Compound tag values should not be used
Status: Required
This tag is a default tag for AWS resources, and has special behavior in the AWS console. Because of this, the key of this tag is an exception to the naming rule in that it contains a capital letter.
The value of the Name tag depends on its resource type.
Status: Required
Reflects the Bowdoin Project Code from the financial system. This is used to identify and report portions of an overall invoice or billing cycle that belong to a group on campus based on their financial project number. Shared resources (i.e., a common vnet/VPC), may be marked with a project number from IT. Important: This is not used for chargeback, but it is used for showback. Valid Characters: Six digits, 0-9 matching an existing project code in the Bowdoin financial system.
Status: Required
A deployment environment is a group of computer, network and infrastructure configuration in which an application is deployed and executed. The values of this tag should reflect the current deployment environments policy.
Valid values:
- prod
- dev
- stage
- test
- experimental
Status: Required
For regulatory compliance, and will be (GDPR, PCI, HIPAA, etc.) as defined by policy.
Status: Required
For data classification. The value should be one of the options in our data classification policy (Public, Sensitive, Restricted, etc.)
Status: Recommended
A free form place to store a note about a resource that does not fit into a defined tag or other process. This tag is intended to be used by humans and should be human readable and values should not be coded into this space
This tag is not mandatory as it is expected that other tags should provide descriptive information about what a resource is or what it does. This tag is provided if more information is needed and does not fit elsewhere.
Valid Characters: Any that are valid to the system it is being used on.
Status: Optional
This tag is a URL used to point to documentation. At this time, Confluence is our source of documentation, but it could a URL to another source.
Status: Optional
Used to identify service, aka resource group which may end up being the name.
Example: All the components of Veeam would have a common value in this tag.
Status: Required
Used to identify responsible group, aka superseding a person which group is responsible for this resource.
Example: Enterprise Systems (be consistent with naming)
Status: Optional
Used to identify primary person that created, architected or was originally responsible for the resource, aka resource group which may end up being the name.
Example: Jeff Doing
Status: Optional
A human readable string that identifies the project with which the resource is associated. This should be a single-valued entry and should not be a list or otherwise compound entry if the resource supports multiple projects. It is intended to be used for finer-grained usage and cost reporting than the costcenter tag.
Examples:
- voyant
- blackboard
account_naming_construct =
teamname-[servicename-]environment
teamname
- networking
- security
- sysinf
- entsys
- academic
- clientservices
servicename
- www
- Foo
- var
- networking-prod
- entsys-dev
- academic-workspaces-prod
appname_construct =
appname-[environment-][number-][region]
appname
all lowercase one word no dashes
number
start at 1
use if multi region only
Examples:
- myduodevices
- sqlmanagedinstance-prod-1-eastus
increment
- Use a zero padded number
- May contain sequential letters
- start at 01
account_naming_construct-vpcpurpose
vpcpurpose
all lowercase one word no dashes This name needs to be determined in consultation with Networking.
Examples:
- networking-prod-sharedservices
- entsys-prod-nonhybrid
- academic-prod-dcsresearch
account_naming_construct-subnetpurpose[-az]
subnetpurpose
all lowercase one word no dashes
az
- a
- b
Examples:
- networking-prod-wvdstaff-a
- academic-workspaces-prod-workspaces-a
- networking-prod-sharedservices-public-a
- academic-prod-dcsresearch-public-a
source_vpc_name-target_vpc_name
Note that there will be two resources, one on each end of the link.
Examples:
- networking-hub-something-foo (networking side of link)
- something-foo-networking-hub (something side of link)
routetype
- public
- private
- isolated
If the route table is distinct for each AZ (e.g. you are routing to different NATs), you must add the following Zone - Zone should be #l (e.g a, b, c, d, e)
Examples:
- networking-prod-sharedservices-vpc-public
- networking-prod-sharedservices-vpc-public-a
appname-resource_type-sgpurpose
- ssh
- http
- http
- elb
- efs
- nfs
- instance
- db
Examples:
- dns
- sql
- banner-instance-443
- entsys-prod-nonhybrid-vpc-private
account_naming_construct-naclpurpose[-nacldirection]
- ssh
- http
- in
- out
Examples:
- networking-prod-ping-in
- networking-test-http-in
appname-service_type-increment
Examples:
- security-prod-sumologcollector-1
- entsys-prod-myduodevices-1
- networking-prod-s3proxy-1
appname_construct[-service_type][-increment]
appname_construct[-service_type][-increment]
appname_construct[-service_type][-increment]
os_name-os_ver-function[-service_type][-unique_identifier]
Future: Create image specific tags for OS, version, and architecture
Examples:
- rhel8base-web-012
os_name
- rhel
- centos
- ubuntu
- windows
os_ver
- 2012r2ent
- 10-{{build number}} i.e. 10-2004
- 7
- staffimage
- base
account_naming_construct-appname_construct
Applies to PaaS and SaaS, not self installed on IaaS Does not apply to databases inside the service
Examples:
- sqlmanagedinstance-dev-1-mssql
- common-dev-sqlmi
- oracle
- mysql
- postgres
- maria
- aurora
- sql
- mssql
- access
- sqlmi
appname_construct-function_name
Examples:
- enrollmentform-prod-updatelivedname
Used when the function is part of a larger app. It should describe what the function does.
account_naming_construct-unique_identifier
Must be globally unique (due to DNS) 3-63 characters
could be appname_construct,
purpose, string, hash
This is up to the eye of the beholder.
primary volume name-diskincrement
Primary volumes will be named the same as EC2 instance. Secondary volumes use this convention.
account_naming_construct-team_name[-service_name]-environment
AWS uses Okta for person based access and a IAM user would not be created. These would be created for service accounts (Terraform, etc.)
Examples:
- entsys-prod-cdk
- network-prod-sharedservices
- security-prod-azurecloudappsecurity
account_naming_construct-environment[-app_name]
Examples:
- security-prod-resourcegroupstaggingapi
- systems-prod-awsbackupservice
account_naming_construct-[-service_name]-environment[-app_name]
Examples:
- security-prod-resourcegroupstaggingapi
- ergw
- vpngw
Optional, to differentiate multiple vngs in a single account
account_naming_construct-unique_identifier
Must be globally unique (due to DNS) 1-1024 characters
Use existing service account naming convention
Imperatives in this document shall be defined as: (based on RFC2119)
-
MUST
This word, or the terms "REQUIRED" or "SHALL", mean that the definition is an absolute requirement of the specification.
-
MUST NOT
This phrase, or the phrase "SHALL NOT", mean that the definition is an absolute prohibition of the specification.
-
SHOULD
This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.
-
SHOULD NOT
This phrase, or the phrase "NOT RECOMMENDED" mean that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label.
-
MAY
This word, or the adjective "OPTIONAL", mean that an item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because the vendor feels that it enhances the product while another vendor may omit the same item. An implementation which does not include a particular option MUST be prepared to interoperate with another implementation which does include the option, though perhaps with reduced functionality. In the same vein an implementation which does include a particular option MUST be prepared to interoperate with another implementation which does not include the option (except, of course, for the feature the option provides.)