Designing KMS key policies to limit key usage to authorized users

Can you explain what a KMS key policy is and its purpose within AWS Key Management Service?

A KMS key policy is a resource-based policy attached directly to a KMS key that defines the permissions controlling who can use the key and how they can use it. KMS key policies are used to enforce fine-grained access control over AWS KMS keys, specifying which principals (users, roles, AWS services) can perform actions such as encrypt, decrypt, and manage the key.

How do you ensure that a KMS key policy permits access only to authorized users within the same AWS account?

To ensure that a KMS key policy permits access only to authorized users within the same AWS account, you can use condition elements within the policy to restrict access based on the user’s account. You can use the Principal element along with AWS to list the ARNs of the users and roles that are allowed to access the key, or use condition keys such as aws:PrincipalAccount to match the user’s account ID.

When designing KMS key policies, why might you use IAM policies in conjunction with KMS key policies?

IAM policies and KMS key policies work together to determine the effective permissions for KMS operations. IAM policies grant permissions to IAM users, groups, and roles, while KMS key policies control access to the KMS keys themselves. Using both allows for a layered approach to security, by not only controlling who can access the KMS service but also setting granular permissions on individual keys.

Describe how you can limit the usage of a KMS key to a specific service or a specific set of API operations.

To limit the usage of a KMS key to a specific service or set of API operations, you can use the Condition element in the KMS key policy with relevant condition keys such as kms:ViaService or kms:CallerAccount. You specify the service name or the allowed API operations to enforce the intended restrictions.

What is the significance of the kms:CallerAccount condition key in a KMS key policy?

The kms:CallerAccount condition key is used to restrict key usage to principals (users/roles) within a specific AWS account. This condition ensures that the key can only be used by users who are authenticated from the account specified in the condition, adding an additional layer of control to prevent unauthorized cross-account access.

How do you create a KMS key policy that permits auditing activities but prevents key management actions by certain users?

You create a KMS key policy that allows specific actions, such as kms:Describe*, kms:Get*, and kms:List*, to enable auditing but excludes key management actions like kms:Create*, kms:Delete*, or kms:Update* by not including them in the Action element for those users. Additionally, you can use the NotAction element to exclude a set of actions in one statement.

Explain how to use the kms:EncryptionContext in a key policy to restrict the conditions under which a KMS key can be used.

The kms:EncryptionContext is a key-value pair passed to AWS KMS when calling encryption or decryption operations. In a key policy, you can specify a condition that checks for specific encryption context values, effectively constraining usage of the KMS key to circumstances in which the right context is provided, therefore, adding a layer of security by ensuring the key is used in the appropriate context.

What is the difference between using a KMS key policy and a resource-based policy for controlling access to a KMS key?

KMS key policies are a form of resource-based policies specific to KMS keys that directly attach permissions to the key itself. These are the primary way to control access to AWS KMS keys. In contrast, resource-based policies are broader and used for other AWS services to control access to specific resources. KMS doesn’t support resource-based policies other than its own key policies.

Can you prevent deletion of a KMS key in the key policy? If so, how?

Yes, you can prevent deletion of a KMS key by excluding the kms:ScheduleKeyDeletion and kms:CancelKeyDeletion permissions in the key policy. You can either not grant these permissions to any user or explicitly deny these actions using a Deny policy statement for all users.

How would you limit KMS key usage to specific IP addresses or VPC endpoints?

To limit KMS key usage to specific IP addresses or VPC endpoints, you can use condition keys such as aws:SourceIp or aws:SourceVpcEndpoint in the Condition block of your KMS key policy. You set these to the allowed IP addresses or VPC endpoint IDs to ensure that key operations can only be performed from those specified sources.

Describe using wildcard characters when specifying Principal in a KMS key policy.

In a KMS key policy, you can use wildcard characters (*) when specifying principals in the Principal element to represent multiple users, roles, or AWS services. However, using wildcards reduces the specificity and increases the potential attack surface, so it’s recommended to enumerate specific principals when possible to restrict access to authorized users only.

How can you allow other AWS accounts to use your KMS keys?

To allow other AWS accounts to use your KMS keys, you specify the account IDs or ARNs in the Principal element of your KMS key policy, combined with the relevant permissions. You can also use the kms:CallerAccount condition key to match the specific AWS accounts that are authorized. This cross-account access should be carefully monitored and reviewed regularly to maintain security.