write-policy: ABAC support, i.e., Condition Keys

[kmcquade]

Just speculating here on how we might implement condition keys support.

There would have to be two separate functions available to users.

1. First, there would have to be a command to list out a table of service, action_name, resource_type, raw_arn, and Condition Keys. This way, a user could identify which condition key they would want to include in their policy.

2. Second, there would have to be a way for the user to supply the condition key to the crud.yml or actions.yml, using something under the current structure. Given that our goal is to abstract the complexity of IAM to the user, we'd want to allow the user to say "I know how condition keys work, but don't feel like determining all the cases where it does or does not apply for specific actions per ARN, so use this condition key wherever possible, and here's the value that I want it to use.

policy_with_crud_levels:
- name: 'PolicyNameWithCRUD'
  description: 'Why I need these privs'
  arn: 'arn:aws:iam::123456789012:role/RiskyEC2'
  read:
    - arn:aws:s3:::example-kinnaird
    - arn:aws:ssm:us-east-1:123456789012:parameter/test
    - arn:aws:kms:us-east-1:123456789012:key/123456
      # Perhaps like this or some other data structure, not sure
      # This will be applied wherever possible, for this specific resource
       condition_key_string: "kms:CallerAccount"
       condition_type_string: "StringEquals"
       condition_value: "123456789012"
  write:
    - arn:aws:kms:us-east-1:123456789012:key/123456
  list:
    - arn:aws:s3:::example-org-sbx-vmimport/stuff
  tag:
    - arn:aws:ssm:us-east-1:123456789012:parameter/test
  permissions-management:
    - arn:aws:secretsmanager:us-east-1:123456789012:secret:mysecret
  # This would be applied wherever possible across all actions
  universal-conditions:
    - condition_key_string: "ec2:ResourceTag/purpose"
       condition_type_string: "StringEquals"
       condition_value: "test"
    # example
    - condition_key_string: "aws:SecureTransport"
      condition_type_string: "Bool"
      condition_value: "True"

Notice how in the above yml file, there are two different places where conditions will be valid:

1. The first is under a specific resource within a CRUD level. This will say, "whenever there is an action under Read access level for this specific KMS key, make sure that you use the Condition Key kms:CallerAccount with a value of 123456789012. However, this will not apply to other CRUD/ARN pairs unless otherwise specified
2. The second is under a new dict titled universal-conditions. This will say, "wherever we are able to use the condition key aws:ResourceTag, set it to aws:ResourceTag/${TagKey} with the K/V pair of TagKey, TagValue.

[kmcquade]

Here's what I'm thinking.

Current state

• Currently, the ArnActionGroup class, which is critical to the CRUD-based Policy writing, uses SIDs as namespaces. The namespaces follow this format: {Servicename}{Accesslevel}{Resourcetypename} So, a resulting statement's SID might look like 'S3ListBucket'

Future state

However, if we are able to support Lazy Condition Keys, we'd have to optionally support longer SIDs to identify unique condition keys.

• If a condition key is supplied (like s3:RequestJob), the SID string will be significantly longer.
  It will resemble this format:
  {Servicename}{Accesslevel}{Resourcetypename}{Conditionkeystring}{Conditiontypestring}{Conditionkeyvalue}
• For example: EC2 write actions on the security-group resource, using the following condition map:

       "Condition": {
            "StringEquals": {"ec2:ResourceTag/Owner": "${aws:username}"}
        }

• The resulting SID would be: Ec2WriteSecuritygroupResourcetagownerStringequalsAwsusername
• Or, for actions that support wildcard ARNs only, an example could be: Ec2WriteMultResourcetagownerStringequalsAwsusername

Question

Hey @0xdabbad00 - I want to ask your opinion on this.

• I want to figure out whether or not I can supply a condition map to a policy statement when:
  • half of the actions under that statement do support the said condition key
  • half of the actions under that statement do not support any condition keys
• ^^ This would reduce the size of any policy files if someone gets aggressive with supplying a ton of Lazy Condition Keys.
• If I am able to do those things, would that throw errors in Parliament? We don't want to create a bunch of policies that will just throw errors in Parliament.

[kmcquade]

I am going to mark this as won't fix. The level of effort to add this feature is quite large. I don't have the capacity for it right now, but if anyone wants to pick it up in the future, please open a new issue and I'm happy to consult/assist.