Skip to content

Instantly share code, notes, and snippets.

@mikegrima

mikegrima/kms.md

Last active April 5, 2023 16:00
Show Gist options
  • Save mikegrima/192d378c483855ae7bc3d94a7f75de25 to your computer and use it in GitHub Desktop.
Save mikegrima/192d378c483855ae7bc3d94a7f75de25 to your computer and use it in GitHub Desktop.
Download ZIP
Some AWS Access Control notes
Raw
kms.md

KMS policies are funky as hell:

  1. KMS key access is almost like cross-account policies but with some differences. KMS keys must have a policy that either:

    • Explicitly grants an IAM Principal access
    • Permits the AWS account in question the ability to delegate access to the key
    • Cross-account access works like any other: you need permissions on the resource and the IAM principal.
    • Same account access needs the first and/or second bullet -- this is unlike other resources, which by default, delegates IAM access to it.

  2. The root principal ARN means that IAM in the account has permissions to delegate permissions to Roles/Managed Policies/etc. in the account. It does not grant access to all principals in the account.

  3. If the root principal is supplied, then you need to grant KMS permissions to the IAM role to access the key. (This is always preferred)

  4. In the same account, if the KMS key policy explicitly grants an IAM principal (either through '*' or through the ARN itself), then the IAM principal is granted access, regardless of what the IAM policy says (if there is a DENY, then that is always enforced). (We prefer number 3 and want to avoid number 4 because it makes debugging access control more difficult)

  5. In a different account, if the KMS key policy grants an IAM principal (either through '*' or through the ARN itself), then the IAM principal is ONLY granted access if the IAM policy grants access too.

References:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment