You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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:
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
The text was updated successfully, but these errors were encountered:
Describe the bug
Looking at https://aws-samples.github.io/aws-iam-permissions-guardrails/guardrails/kms/guardrails.html
IAM-KMS-1 rationale states:
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
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:
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
The text was updated successfully, but these errors were encountered: