Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

IAM-KMS-1 description is not accurate #61

Open
faust64 opened this issue Dec 31, 2024 · 0 comments
Open

IAM-KMS-1 description is not accurate #61

faust64 opened this issue Dec 31, 2024 · 0 comments

Comments

@faust64
Copy link

faust64 commented Dec 31, 2024

Describe the bug
Looking at https://aws-samples.github.io/aws-iam-permissions-guardrails/guardrails/kms/guardrails.html
IAM-KMS-1 rationale states:

Key lockout will occur if there are no principals that have access to the key policy. For example, say only IAM users or IAM Roles or included in the key policy. If the IAM users and IAM Roles are either deleted or they are removed from the key policy, no principal has access to the key policy. Ensuring root is included on the key policy means that in exceptional circumstances the root user can reestablish delegation to the appropriate IAM Role. This is not recommending daily or frequent root usage, rather this root is included as a precautionary measure for exceptional circumstances. The AWS Account root user is included with all created AWS Accounts. Root user is superadmin and can’t be deleted.

I'm noticing a bunch of my colleagues are citing this as a referrence, when setting up KMS keys.

While it is true, that removal of IAM roles/users can have dramatic impact on objects whose inline policy restricts usage/management of resources they apply to.
It is wrong, to suggest that "only the root" account would be subject to such bypass here.

See: https://docs.aws.amazon.com/kms/latest/developerguide/key-policy-overview.html

When the principal in a key policy statement is an AWS account principal expressed as arn:aws:iam::111122223333:root", the policy statement doesn't give permission to any IAM principal. Instead, it gives the AWS account permission to use IAM policies to delegate the permissions specified in the key policy. (A principal in arn:aws:iam::111122223333:root" format does not represent the AWS account root user, despite the use of "root" in the account identifier. However, the account principal represents the account and its administrators, including the account root user.)

My colleagues following that advice, adding ":root" to their inline policy, are actually setting up keys that can be used encrypting and decrypting data, by just any IAM user or role, or assumed role, within that account, which would have kms access.

To Reproduce
Steps to reproduce the behavior:

create kms key, attaching a policy with a single statement:

  statement {
    sid     = "root bypass"
    actions = ["*"]
    effect  = "Allow"
    principals {
      type = "AWS"
      identifiers = [
        "arn:aws:iam::${data.aws_caller_identity.current.account_id}:root",
      ]
    }
    resources = ["*"]
  }

create 2 IAM users, granting yourself with kms:* privileges.
With any of those users, Terraform a KMS key, attaching that policy above
With the other user, try to terraform that key again: works.
Now change that policy, allowing only one of your IAM users managing that key. You should see that only that user may the Terraform/manage that key.
Usage of ":root" allow just any identity within your account. It's not "only if you login as root, you may fix it".

Expected behavior
Clarify rationale, update links which seems to be pointing to non-existing anchors

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant