In AWS, resource access is typically governed by IAM policies or resource-based policies.  There are a few exceptions to this rule and some services support an access mechanism called grants. In AWS, S3 (either via ACL grants or S3 Access grants) and KMS (Key Management Service) both support grants. AWS KMS Keys are used to protect and encrypt data.  With access to KMS keys, it's possible for applications and users to gain access to data.

For KMS Keys, access to keys (and potential data access) can be done by IAM policy, resource-based policies (KMS Key policies), and/or KMS key grants. Additionally, behavior of KMS-specific resource-based policies is atypical of other resource-based policies in AWS. Thus, KMS access can be complex.

Identity and Access is complex and we found the following data access combinations across IAM policies, resource-based policies, and KMS key grants. We'll look at access differently than what is typically shown to gain a better understanding of the possible access combinations and ways to provide data and encryption access via KMS keys.

• 4 minimum access combinations for same account evaluation (IAM principal sits in the same account as the KMS Key).
• 5 minimum access combinations for cross account evaluation (IAM principal is in a different account as the KMS Key).

We can then build on top of those minimum access combinations to get the following 27 total combinations (including the 9 minimum from above).

• 13 different access combinations for same account evaluation (IAM principal sits in the same account as the KMS Key).
• 14 different access combinations for cross account evaluation (IAM principal is in a different account as the KMS Key).

We'll cover the following interesting behavior and deep dive on access for KMS Keys:

• Access to a KMS Key can be granted by a KMS Key Grant itself and does not require access from an IAM Policy or a KMS Key Policy.
• KMS Access is atypical of other resources that support resource-based policies where the KMS Key policy must permit access.
• Default KMS Key Policy allows for delegation that enables IAM policy access to the key.  This relates to the access evaluation point mentioned above.
• Key Grants support nested key grants. When grants are created from other grants, their permissions must be a subset and the same or more restrictive as the parent grant.

We tested and listed all the potential combinations of access granted (in the absence of any explicit denies) for both evaluation within a single account and evaluation for a cross-account scenario. Cross-account scenario would be when the requesting principal exists in Account B and the KMS Key (resource) exists in Account A. in AWS, same account and cross-account scenarios can be evaluated differently.

KMS Key Access Combinations

We took AWS's access and characterized the following possible options for access.  This simplifies AWS policy language and does not factor in conditions and other advanced policy pieces.

• Explicit Allow
  • For KMS Key Grants and Cross Account Evaluation, evaluation is handled different depending on whether the grant is created or not created by the caller account.  Thus we have 2 types of explicit allows for KMS Key grants when evaluating a cross account situation.
• Delegation (only applicable for KMS Key Grants and KMS Key Policies)
• Implicit Allow (represented by a - )
• Explicit Deny (we leave this out of our combinations as this automatically will deny access)

The chart below contains the minimum required access.  For these exercises, we see the explicit allow as the most powerful, then the delegation policy, then implicit allow. For example, an Explicit Allow in a KMS Key Grant created by a Caller Account and an explicit allow in the KMS Key Policy for a cross account use case would result in success since the minimum permissions would only need an Explicit Allow (created by a Caller Account) in the KMS Key Grant.  We have the following 9 minimum access combinations: 4 for same account evaluation and 5 for cross account evaluation.

Note: Delegation in the above chart is a policy where an AWS Account identifier is specified in the Principal element. This delegates authority to the account when an administrator in that account must then grant access to an identity (IAM role or user) in that account. The delegation policy by itself does not grant access. For more information on delegation, see below section on KMS Key Policies and Delegation.

Now, let's look at all of the potential access combinations (not just the minimum).  We found 27 access combinations: 13 for same account evaluation and 14 for cross account evaluation.

‍

We can further split this into separate tables for same account evaluation and cross account evaluation.

Below is the potential combination of access with only KMS Key Policies and IAM Policies which is much less complex. We only have to look for the following:

• Single Account Evaluation: 2 Combinations (4 Combinations with Grants)
• Cross Account Evaluation: 2 Combinations (5 Combinations with Grants)

Access to a KMS Key via Key Grants

• Access to a KMS Key can be granted by a KMS Key Grant itself and does not require access from an IAM Policy or a KMS Key Policy.

Below is a table of testing access to kms:Decrypt via KMS Key Grants where we've modified the KMS Key Policy to reflect an implicit deny.  This testing was done within an AWS Account as evaluation for single account has different logic than multi-account evaluation.

The 2 cases where access was permitted were with the KMS Key Grant having an explicit allow.  Thus, a KMS Key Grant alone (in the absence of any deny policies) can permit access to the KMS key.

Our reference key policy that removes the default delegation (more on that later)

{
    "Version": "2012-10-17",
    "Id": "key-policy-test",
    "Statement": [
        {
            "Sid": "Allow access for Root",
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::123412341234:root"
            },
            "Action": "kms:*",
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "aws:PrincipalType": "Account"
                }
            }
        },
        {
            "Sid": "Allow access for Key Administrators",
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::123412341234:role/admin-role"
            },
            "Action": "kms:*",
            "Resource": "*"
        }
    ]
}

‍

Below is a table of testing access to kms:Decrypt via KMS Key Grants where we've used the default key policy provided by AWS.

From comparing these results with earlier, an explicit allow in either the KMS Key Grant or the IAM Policy will result in access permitted.

KMS Key Policies and Delegation

Delegation occurs in resource-based policies when the AWS account identifier is specified in the Principal element.   From AWS documentation, "This delegates authority to the account. When you allow access to a different account, an administrator in that account must then grant access to an identity (IAM user or role) in that account."

An example delegation policy is as follows:

{
  "Sid": "Enable IAM User Permissions",
  "Effect": "Allow",
  "Principal": {
    "AWS": "arn:aws:iam::123412341234:root"
   },
  "Action": "kms:*",
  "Resource": "*"
}

The above delegation policy does not grant access directly to any IAM user or role in the account.  In KMS, the following is true:

• The AWS-Provided default KMS key policy includes a delegation policy that enables IAM policy access to the key.
• KMS Access is atypical of other resources that support resource-based policies where the KMS Key policy must permit access.

The AWS-provided default KMS key policy changes the behavior of KMS access by allowing usage of IAM policies and thus "delegating" the ability to permit access to IAM policies.  Without the delegation policy, the KMS key policy must explicitly allow access.

From AWS documentation on policy evaluation: "For most resources, you only need an explicit allow for the principal in either an identity-based policy or a resource-based policy to grant access. IAM Role Trust policies and KMS key policies are exceptions to this logic, because they must explicitly allow access for principals"

From AWS documentation on default key policies: "This default key policy has one policy statement that gives the AWS account that owns the KMS key permission to use IAM policies to allow access to all AWS KMS operations on the KMS key." and "When the principal in a key policy statement is the account principal, the policy statement doesn't give any IAM principal permission to use the KMS key. Instead, it allows the account to use IAM policies to delegate the permissions specified in the policy statement. This default key policy statement allows the account to use IAM policies to delegate permission for all actions (kms:*) on the KMS key."

Below is our modified version of a key policy to still allow root access in case of lockout as well as adding access for a key administrator. To do so, we added a condition key for aws:PrincipalType and matched that to Account.

{
    "Version": "2012-10-17",
    "Id": "key-policy-test",
    "Statement": [
        {
            "Sid": "Allow access for Root",
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::123412341234:root"
            },
            "Action": "kms:*",
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "aws:PrincipalType": "Account"
                }
            }
        },
        {
            "Sid": "Allow access for Key Administrators",
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::123412341234:role/aws-reserved/sso.amazonaws.com/AWSReservedSSO_AdministratorAccess"
            },
            "Action": "kms:*",
            "Resource": "*"
        }
    ]
}

‍

KMS Key Grants and Delegation

Impact

KMS Key Grants may be a hidden avenue of data access as they're not auditable via the KMS Key Policy nor IAM Policies. Additionally, KMS Key Grants do not appear in the AWS Console and only can be found via the AWS CLI.

Additional points of interest with KMS Key Grants:

• KMS Key Grants are not automatically retired and may linger after they're no longer used.
• AWS Services commonly use KMS Key Grants for access and to manage data encryption.
• KMS Key Grants can only allow Grant Operations such as the following for symmetric encryption keys:
  • Decrypt
  • DeriveSharedSecret
  • Encrypt
  • GenerateDataKey
  • GenerateDataKeyPair
  • GenerateDataKeyPair
  • GenerateDataKeyPairWIthoutPlaintext
  • GenerateDataKeyWithoutPlaintext
  • ReEncryptFrom
  • ReEncryptTo
  • CreateGrant
  • DescribeKey
  • GetPublicKey
  • RetireGrant
• Kms:CreateGrant is similar to Kms:PutKeyPolicy in the manner that it's another permission management permission on a KMS Key and thus, potential data access management.

Recommendations

• Ensure security tooling audits for KMS Permissions including KMS:CreateGrant and KMS:PutKeyPolicy

• Retire unused and stale KMS Key Grants.

• If Grants are necessary, use grant constraints to further restrict access to appropriate access.

• Validate and ensure access is appropriate for key management and access management permissions including KMS:CreateGrant and KMS:PutKeyPolicy.

• Validate usage of delegation in both KMS Key policies and KMS Key Grants.

Conclusion

If you want to chat cloud encryption management and cloud data security, email us at info@fogsecurity.io, we'd love to hear from you. We're passionate about cloud data security and are building tools to help teams with identifying data access and securing data in your AWS-based workloads and infrastructure. More research and resources related to encryption and data perimeters to come!

‍