
AWS Tagging Best Practices: Using Terraform and CloudFormation to Enforce Tags - toeknee123
https://cloudforecast.io/blog/aws-tagging-best-practices-guide-part-2/
======
ldoughty
I really dislike that the solutions for AWS tag shortcomings is custom code.

I'm a big AWS fan and heavy user for 5 years now, but it seems silly to me
that you need to write a custom wrapper (e.g. force the creation through a
managed script/template like Terraform/Ansible/CF)... Or write reactionary
cloud trail policies to handle a situation where someone launches an EC2
instance without providing a specific tag.

The fact IAM policies still can't deny requests missing a tag, or deny
requests by tag-value condition seems silly to me... Or one step further:
allowing some auto-populated tags like what principle was responsible for
making the instance in the first place.

~~~
chrisoverzero
> The fact IAM policies still can't deny requests missing a tag, or deny
> requests by tag-value condition seems silly to me...

Can't it, though?

    
    
      "Condition": {
        "StringEquals": {
          "aws:RequestTag/key1": "value1",
          "aws:RequestTag/key2": "value2"
        },
        "ForAllValues:StringEquals": {
          "aws:TagKeys": [
            "key1",
            "key2"
          ]
        }
      }

~~~
wernerb
The problem is that all IAM conditionals just give a generic "Denied"
statement which is hard to debug. You at left figuring out if you are missing
a uppercase character in your tag key. AWS IAM is currently not meant to be
used in a devops/enforcement of best practices way. They have AWS config for
that, but that's always after the fact while immediate feedback is what you
need to function at scale.

A possible fix is to allow custom deny reasons but large changes like this to
any already extremely large and entangled system like IAM is unlikely.

~~~
whoknew1122
> "A possible fix is to allow custom deny reasons but large changes like this
> to any already extremely large and entangled system like IAM is unlikely."

This would allow an attack to enumerate permissions by seeing what's denied.

Generic statements aren't a bug, they're a feature.

~~~
Spivak
Yes, but what they're talking about isn't a security denial but a
configuration check. Can you imagine if the only output to a git commit pre-
hook was "no" and you were left to figure out why?

~~~
whoknew1122
> "Yes, but what they're talking about isn't a security denial but a
> configuration check."

Configuration is a part of security though.

Let's say AWS credentials are leaked. One of the most common uses for leaked
credentials is to launch EC2 instance for crypto mining. A malicious actor
tries to launch RunInstances on $20k worth of instances and gets denied
because there isn't a tag on the instances. Would you want the error to say
'Access denied because you didn't don't have the following tag...'?

~~~
Spivak
Yes, because lacking a tag isn't a security boundary. The account has
permission to launch EC2 instances and knowing that instances need to have
tags isn't a password designed to keep malicious actors out, it's a safeguard.

------
mcintyre1994
Something that's pretty nice in AWS CDK is that tagging is recursive - so if
you add a tag to eg. a top-level ECS service object then the tags are applied
to all of its children automatically.
[https://docs.aws.amazon.com/cdk/latest/guide/tagging.html](https://docs.aws.amazon.com/cdk/latest/guide/tagging.html)

~~~
acdha
There's a long-running Terraform issue for the equivalent if you want to chime
in:

[https://github.com/terraform-providers/terraform-provider-
aw...](https://github.com/terraform-providers/terraform-provider-
aws/issues/7926)

------
kapilvt
This is one of the bread butter use cases on the opensource cloud custodian
project (auto tagging, tag enforcement workflows, retro-active tagging from
cloudtrail, etc). [https://cloudcustodian.io](https://cloudcustodian.io) (now
a cncf sandbox project).

~~~
toeknee123
100% agree. We're big fans of CloudCustodian and use it ourselves. However, it
can be tough for some org to get approval with using open source tools.

------
yonixw
Tags are not supported for some VPC components (on creation). In that sense,
Azure Resource Group and Google Projects is way better for organising and
project based permissions.

Source:
[https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Ta...](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#tag-
ec2-resources-table)

~~~
acdha
Can you provide a more detailed comparison? I've run into a variety of GCP
services which can't be labeled so I'm curious that this would be described as
“way better”.

~~~
yonixw
Let's say I want to create an IAM to allow creation for a specific project
(Full deploy), I can't enforce it on VPC.

------
tthayer
We use cloudposse's label terraform module for everything. It works really
well and it lets you use common values for everything. Paired with terragrunt
it removes most of the pain of tagging for us.

------
nprateem
Use a tag policy and you can use whatever tool you want

