Skip to main content

🛡️ AWS IAM Role Inline Policy allows KMS decryption actions on all KMS keys🟢

  • Contextual name: 🛡️ Role Inline Policy allows KMS decryption actions on all KMS keys🟢
  • ID: /ce/ca/aws/iam/role-inline-policy-allows-kms-decrypt-on-all-keys
  • Tags:
  • Policy Type: COMPLIANCE_POLICY
  • Policy Categories: SECURITY

Stats​

not available

Logic​

Similar Policies​

Description​

Open File

Description​

This policy checks whether an IAM role inline policy allows KMS decryption actions on all AWS KMS keys.

Rationale​

IAM role inline policies should follow least privilege and grant access only to the KMS keys that a workload, service, or automation path explicitly requires.

If a role inline policy allows kms:Decrypt, kms:ReEncryptFrom, or broader KMS decryption-related actions against * or wildcard KMS key ARNs, any principal that can assume the role can potentially decrypt data protected by keys outside its intended boundary. This increases the blast radius of role compromise, policy misconfiguration, and privilege escalation.

Impact​

Restricting wildcard KMS access can require updates to applications, automation, cross-service integrations, or delegated administration workflows that currently rely on broad permissions. Before tightening the policy, identify the exact KMS keys the role must use and validate the updated access in a non-production environment when possible.

Audit​

This policy flags an AWS IAM Role Policy as INCOMPLIANT when all of the following are true:

... see more

Remediation​

Open File

Remediation​

Restrict KMS key scope​

Perform the following to update the IAM role inline policy by replacing wildcard KMS resources with the specific KMS key ARNs that should be allowed and, where possible, narrowing broad KMS actions.

From Command Line​

  1. Retrieve the current inline policy document:

    aws iam get-role-policy \
        --role-name {{role-name}} \
        --policy-name {{policy-name}}

  2. Update the policy document so that KMS decryption permissions are limited to only the specific KMS key ARNs that the role requires.

  3. Apply the updated inline policy:

    aws iam put-role-policy \
        --role-name {{role-name}} \
        --policy-name {{policy-name}} \
        --policy-document file://policy.json

Notes​

Grant kms:Decrypt and kms:ReEncryptFrom only for the KMS keys that the role inline policy should allow.

Where possible, also narrow the allowed actions so the policy does not rely on broad permissions such as kms:* or kms:ReEncrypt*.

policy.yaml​

Open File

Linked Framework Sections​

SectionSub SectionsInternal RulesPoliciesFlagsCompliance
💼 AWS Foundational Security Best Practices v1.0.0 → 💼 [KMS.2] IAM principals should not have IAM inline policies that allow decryption actions on all KMS keys3no data
💼 Cloudaware Framework → 💼 Role-Based Access Control (RBAC) Management29no data
💼 FedRAMP High Security Controls → 💼 AC-2 Account Management (L)(M)(H)10963no data
💼 FedRAMP High Security Controls → 💼 AC-2(1) Automated System Account Management (M)(H)32no data
💼 FedRAMP High Security Controls → 💼 AC-3 Access Enforcement (L)(M)(H)49103no data
💼 FedRAMP High Security Controls → 💼 AC-5 Separation of Duties (M)(H)22no data
💼 FedRAMP High Security Controls → 💼 AC-6 Least Privilege (M)(H)81287no data
💼 FedRAMP High Security Controls → 💼 AC-6(3) Network Access to Privileged Commands (H)16no data
💼 FedRAMP Low Security Controls → 💼 AC-2 Account Management (L)(M)(H)9no data
💼 FedRAMP Low Security Controls → 💼 AC-3 Access Enforcement (L)(M)(H)103no data
💼 FedRAMP Moderate Security Controls → 💼 AC-2 Account Management (L)(M)(H)963no data
💼 FedRAMP Moderate Security Controls → 💼 AC-2(1) Automated System Account Management (M)(H)32no data
💼 FedRAMP Moderate Security Controls → 💼 AC-3 Access Enforcement (L)(M)(H)103no data
💼 FedRAMP Moderate Security Controls → 💼 AC-5 Separation of Duties (M)(H)22no data
💼 FedRAMP Moderate Security Controls → 💼 AC-6 Least Privilege (M)(H)687no data
💼 NIST CSF v2.0 → 💼 DE.CM-01: Networks and network services are monitored to find potentially adverse events187no data
💼 NIST CSF v2.0 → 💼 DE.CM-03: Personnel activity and technology usage are monitored to find potentially adverse events107no data
💼 NIST CSF v2.0 → 💼 PR.AA-01: Identities and credentials for authorized users, services, and hardware are managed by the organization50no data
💼 NIST CSF v2.0 → 💼 PR.AA-05: Access permissions, entitlements, and authorizations are defined in a policy, managed, enforced, and reviewed, and incorporate the principles of least privilege and separation of duties199no data
💼 NIST CSF v2.0 → 💼 PR.DS-10: The confidentiality, integrity, and availability of data-in-use are protected249no data
💼 NIST CSF v2.0 → 💼 PR.IR-01: Networks and environments are protected from unauthorized logical access and usage165no data
💼 NIST SP 800-53 Revision 5 → 💼 AC-2 Account Management132461no data
💼 NIST SP 800-53 Revision 5 → 💼 AC-2(1) Account Management _ Automated System Account Management432no data
💼 NIST SP 800-53 Revision 5 → 💼 AC-3 Access Enforcement15866no data
💼 NIST SP 800-53 Revision 5 → 💼 AC-3(7) Access Enforcement _ Role-based Access Control36no data
💼 NIST SP 800-53 Revision 5 → 💼 AC-3(15) Access Enforcement _ Discretionary and Mandatory Access Control27no data
💼 NIST SP 800-53 Revision 5 → 💼 AC-5 Separation of Duties22no data
💼 NIST SP 800-53 Revision 5 → 💼 AC-6 Least Privilege102580no data
💼 NIST SP 800-53 Revision 5 → 💼 AC-6(3) Least Privilege _ Network Access to Privileged Commands6no data