Platform Engineering#

• DevOps: bookmarks
• Pragma: IT operations maturity model(todo: document company best practices)
• Rackspace: fanatic support

Platform Security Squad#

• Owasp Best Practices

Platform Strategies#

• Resource naming
• Tagging strategy
• Tagging Schema
• Tagging userguide

Tagging#

Data Classification - info-sec:data-classification -> sensitive, company-confidential, customer-identifiable
Disaster recovery - disaster-recovery:rpo -> 6h, 24h
Cost allocation - cost-allocation:business-unit ->   engineering, networking recrutment

• What are tags
• Tagging rules
• Tagging restrictions
• Tagging assets
• Tagging
• Tagging and Labeling Best practices
• Azure Tagging

Note that standardizing on and adhering to a labeling policy is crucial for centrally-managed labels. Product teams and departments can also add custom labels to resources to share team-specific information. For more information, see Apply non-standard labels.

Here's an example of how you can define a standard set of values for each of the keys:

• Environment: prod/dev/staging
• Data-classification: public/internal-only/confidential/restricted/na
• Cost center: c23543
• Team: shopping-cart
• Component: frontend/cache/backend/database
• Application: shopping-cart-payments
• Compliance: pci-hippa

Avoid confidential information#

Protecting personally identifiable information (PII) is critical for security. Avoid storing PII or other confidential information in your labels.

Apply non-standard labels#

Although adhering to a label policy is crucial, labels can also be used to share information that is specific to a product team or department. In such a scenario, providing resource owners of individual teams the option to apply non-standard labels for each resource can help provide more context about the resource. This makes it easier to search, filter, and share information specific to these product teams or departments. For example, a single resource can have a set of standard labels such as environment:prod, data-classification:restricted, cost-center:c23543, team:shopping-cart, app:shopping-cart-payments, component:database, compliance: pci. The resource owner can add non-standard labels such as version:5.0.1 and replica:primary to indicate the version of the database cluster and the node's replication status.

Consider change implications#

Your labeling strategy is likely to change in times of evolving business requirements. Be aware of the implications that these changes may have. For example, the addition of new cost centers, microservices, or new tools can impact your labeling strategy.

Label naming scheme and pattern#

Every organization has its own way of organizing resources. You can use labels to categorize the resources in your hierarchy in multiple ways, helping users to filter for the resources they need. When defining your label naming scheme, consider the following:

• Environment, cost center, team, component, applications, compliance, and ownership associated with the resource.
• Data classification of any data stored in the system. This is only applicable to stateful systems.
• Labels that need to be applied at the specific resource level like Compute Engine, Cloud Storage bucket or at the project.
• Flexibility to use optional labels, as needed, to provide more information on resources.

Example of defining labels#

To define labels, here are some attributes that you need to keep in mind.

In the following label example, altostrat corresponds to the name of the enterprise.

Label all you need#

Labels are a key-value pair so use that to your advantage to add in as much data as you need onto them.

Here are some examples of labels to use:

1. Environment names Labeling a resource as belonging to development, staging, testing, production, etc. is always a safe choice so searching for all resources in production later for a billing report is much easier.
2. Role If you have a set of Compute Engine resources acting as web servers, another set in a GKE cluster, and one for a database server label them as such.
3. _Application name _Using the application name as a label makes it easier to group resources by the business project or application they are associated with makes it easier to look at costs per application.
4. _Region name _If your application or project stretches multiple regions adding the region value will help sort them later. This can be the GCP region name, a logical region you have setup in your application, or having a label for each.
5. _Resource Creator _Putting the name of the creator in a label will help sort out who created what resource later instead of having to dig through audit logs that may or may not have been retained.
6. _Owner or maintainer _Labeling a resource with the owner or maintainer’s name assists in who to contact in the case of an issue or question later. A common example of this would be the team that owns or maintains the resource.
7. _Cost, billing, or budget code _Some organizations have codes for different expenditures or budgets. Adding these into the label makes it easier for billing administrators or auditors to track these.
8. Department If the resource belongs to a certain department then adding it as a label makes it easier to track down a department later.
9. _Bucket name (Google Cloud Storage only) _If you have ever had to look at a GCP billing report or invoice you realize it groups all of the storage buckets together into one line item. This is a nightmare if you want to know what each bucket costs, so adding the bucket name as a label to each bucket will allow this to be broken out into separate line items.
10. _Associated resource name _If you have a resource that’s tied to another resource it’s a good idea to add a label naming that resource to it. Examples of this might be a persistent disk tied to a Compute Engine instance or a Dataproc cluster. An external IP that is tied to a Compute Engine managed instance group is a great example of this as well.
11. _Data classification _This is a broad labeling use case, but if you have any sort of data that needs to be labeled in a bucket or BigQuery dataset then add a label for it to denote this. Examples might be data that falls under regulatory compliance such as HIPAA or PCI or encrypted data. It’s best to label these resources with this so when a C-level executive asks how much money is spent on storing PHI (protected health information) per month it can be pulled up very quickly.
12. Resource state If a resource is active, pending deletion, disabled, etc. then labeling it as so makes it very easy to see how much is being billed to resources in a particular state.
13. _Folder or organization name _If you utilize folders or different organizational units in your organizational structure make a label them to be able to see what each organization or folder costs you later.