This is just adding metadata. The whole blog can be reduced to...<p>'Tag resources for any cloud you work in'<p>Azure recommends this.
AWS recommends this.
etc.<p><a href="https://docs.aws.amazon.com/whitepapers/latest/tagging-best-practices/what-are-tags.html" rel="nofollow">https://docs.aws.amazon.com/whitepapers/latest/tagging-best-...</a>
<a href="https://learn.microsoft.com/en-us/azure/azure-resource-manager/management/tag-resources" rel="nofollow">https://learn.microsoft.com/en-us/azure/azure-resource-manag...</a>
I've never considered ownership in an IaC repo down to the individual resource and I'm struggling to see the usecase.<p>We also use tags/labels to link the generated "thing" back to the repository that created it with:<p>- The repo URL<p>- The pipeline URL<p>- The commit hash (also retrievable from the pipeline details)<p>These are all discovered via GitLab CI variables [1].<p>From this we would use the Git repository to identify ownership.
We have the benefit of our Infosec team having wide access to our GitLab instance, which might hamper other companies.<p>How would you handle a situation where someone creates a resource but then leaves?<p>The good thing about looking at an entire repository is that it gives you the entire history and who else might have worked on it. In hierarchical Git providers (eg. GitLab), it can also indicate where the project sits relative to others. If you just have a single person, you may struggle to find out who now owns a resource.<p>[1] <a href="https://docs.gitlab.com/ci/variables/predefined_variables/" rel="nofollow">https://docs.gitlab.com/ci/variables/predefined_variables/</a>
NHI => Non-human identity, something I had never heard before reading this (even though i was familiar with the concept of identities for services, like service accounts or iam roles or whatever). I wonder if that's a common acronym.