✍️ Initial draft of tagging standards

[spikeheap]

This is a consolidation of our tagging standards for AWS, based on https://github.com/LBHackney-IT/aws-tags-lbh and https://docs.google.com/document/d/1iWsgVYWXAbZQZDYP4PJ-Gv74rFRQUSdDC_XHHSiliXk/edit?pli=1&tab=t.0.

Deadline for comments

Comments and improvements are welcome! We'll iterate on this and discuss things both in Slack and on this PR directly.

The decision to approve and merge (or discard) this PR will be taken by Monday 27th of January. We'll aim for broad consensus (i.e. no major objections), but if there's disagreement, @LBHSPreston will have the final say.

Why this PR?

We need to keep track of the resources we're running in AWS to meet our security obligations:

1. We need to know which team is responsible for each resource so we know who to talk to if there are suspected vulnerabilities or security incidents.
2. We need to be able to generate aggregate reports to help teams know what they need to do, for example producing a list of RDS databases each team needs to upgrade or do some reporting of.
3. We need to know what resources are used for, i.e. which application or system they're part of, in order to manage decommissioning old infrastructure, managing cost, and responding to cyber security incidents.

All of this is currently tricky. We use tagging inconsistently across the estate, so some things can be reported on easier than others.

This PR introduces a baseline standard that consolidates the rules around tagging, but that introduces a new problem: what are the specific steps a developer needs to take for a system to be consistent with our approach?

This PR addresses both of those issues, following the Diataxis approach to technical documentation authoring.

Changes

This change adds:

1. A new section named "Technical Standards". The intention is to only include "standards" here with "must", "should", "must not", and "could" language.
2. A tagging standard as a proof of concept.
3. A tagging "how to" guide to complement the requirements.

ℹ️ The screenshots below show roughly how the pages will look. Please see the Files Changed section in the PR for the actual text of the pages, as these won't be updated as the PR progresses.

Other areas of the site include content which could be a requirement or standard, however they're interspersed with other types of content and many are not current (or at least, not followed). This is an attempt to start archiving the old, irrelevant content and documenting the current standards we work to.

This first commit is very much a work in progress, for comments and iteration.

Things to do if this PR is merged:

1. Remove tags we're no longer using from https://github.com/LBHackney-IT/aws-tags-lbh:
   • AutomationTool: The tool used for Infrastructure as Code, e.g. Terraform or Serverless Framework.
   • Phase
   • Stack
   • Patch Group
   • Project
   • OOOShutdown (has been superceded)
   • Team (replaced by TeamEmail)
2. Update https://github.com/LBHackney-IT/aws-tags-lbh to match the new tags
   • Add OOHShutdown and WeekendShutdown tags
3. Update tooling to use OOHShutdown and WeekendShutdown and deprecate ooh_shutdown and weekend_shutdown
4. Update any other docs about tagging that reference things that have changed 🕵️ .

[stonest]

finally having a standard for tagging will enable us to get better transparency visualisation on cost and governance, make it easier to find where resources in AWS are originally defined in Github and gives us potential to make our iam policies for users better so i'm a big fan of this

[LBHMKeyworth]

Agreed, this all seems sensible to me.
A few thoughts:

• Is there a need to tag resources with a commit hash (and/or version) that deployed them?
• I wonder whether there's scope to eventually have some conditional-mandatory tags based on the resource type. (i.e. the Confidentiality tag for anything that holds data). I'm not sure how easy (if it's possible at all) it would be to put controls in place to check this.
• I also wonder about some resources we have now that have tags on them that are not relevant at all because we've tagged ALL resources at the provider level. For example a VPC with the Backup tag is pointless and noisy. (Not a priority now, but maybe something to look at in the future?)

[spikeheap]

@LBHMKeyworth:

I agree with your last two points. Hopefully this standard makes the tags more valuable, so further down the line it's even more worthwhile to do housekeeping like you described.

Is there a need to tag resources with a commit hash (and/or version) that deployed them?

It's a good question. We'll get that with the AutomationBuildUrl (and I've added steps in the how to guide for that), but I reckon that'll create noise with myriad label updates for every build. I'm not sure if there's a better way which would only tag the resources that changed with the updated build ID/URL.

Even just getting back to the repository with the IaC code would be good, so we could loosen the requirement to "either build URL or IaC source code URL", or use separate tags for that. Promoting "something is better than nothing" could get us more, better data.

[manimaran-ramalingam]

Hi,
Please find my comments below :
For Point 1 :
In addition to identifying the team responsible for each resource, I recommend including primary and secondary contact details (e.g., email, phone number, Slack) alongside the team email. This would help us quickly identify and reach out to the right person when dealing with suspected vulnerabilities or security incidents.

[acanbym]

Hi, Please find my comments below : For Point 1 : In addition to identifying the team responsible for each resource, I recommend including primary and secondary contact details (e.g., email, phone number, Slack) alongside the team email. This would help us quickly identify and reach out to the right person when dealing with suspected vulnerabilities or security incidents.

this feels a little like a 'nice to have' and could perhaps be an iteration planned for a later date?
I also wonder if it might not make sense to have information in tags that might be best placed in the service catalogue

[acanbym]

needless to say, I'm a big fan of this. there are myriad ways that we could use tags to improve, amongst others, our security, budgeting abilities, disaster recovery/business continuity planning -- the list goes on.

I've had to reign in my own enthusiasm and desire to add more and more tags to this strategy, however, because I needed to remind myself that in the absence of any form of consistent tagging across all our services and applications, we need to try to achieve consistent coverage with a handful of 'must haves', before we tackle the 'should haves' and 'could haves'. in other words, let's agree an MVP, roll that out and then iterate.

[acanbym]

one last thing I forgot to mention:

• we have swapped out all snake_case, kebab-case versions of the new out of hours and weekend shutdown tags. they are now as follows:
  -- OutOfHoursShutdown
  -- WeekendShutdown

[stonest]

Agreed, this all seems sensible to me. A few thoughts:

• Is there a need to tag resources with a commit hash (and/or version) that deployed them?
• I wonder whether there's scope to eventually have some conditional-mandatory tags based on the resource type. (i.e. the Confidentiality tag for anything that holds data). I'm not sure how easy (if it's possible at all) it would be to put controls in place to check this.
• I also wonder about some resources we have now that have tags on them that are not relevant at all because we've tagged ALL resources at the provider level. For example a VPC with the Backup tag is pointless and noisy. (Not a priority now, but maybe something to look at in the future?)

for the second point, we can have an SCP the request that tag on a resource, and then with the tag policy et the values that it must be (if we cant just do that in the SCP as well) i.e. buckets must have a confidentiality tag with a value of INTERNAL, RESTRICTED, PUBLIC