Purpose of This Lesson

This hands-on lesson demonstrates how to create AWS KMS customer-managed keys and configure their permissions through key policies. It covers a general-purpose encryption key and a second symmetric key whose use is restricted to Amazon EC2 and Amazon RDS in the us-east-1 Region.

The key policy is the central access-control document for a KMS key. It distinguishes between identities that administer the key and identities or services that use it for cryptographic operations.

Key Concepts

AWS managed keys, customer-managed keys, and custom key stores

The KMS console separates several key categories:

• AWS managed keys: Created and managed by AWS for supported services. The number of keys in an account depends on which AWS services have been used.
• Customer managed keys: Created and controlled by the customer. These keys can have custom aliases, descriptions, tags, rotations, and key policies.
• Custom key stores: Includes AWS CloudHSM key stores and external key stores.

This lesson creates customer-managed keys rather than AWS managed keys.

Symmetric key configuration

The demonstrated keys are symmetric and have the usage Encrypt and decrypt. The KMS creation wizard also exposes advanced settings, including the source of key material and whether the key should support multi-Region use, but the lesson leaves those settings at their defaults.

Aliases

An alias is a human-readable display name for a KMS key. The first key uses the alias KMS key general; the second uses KMS EBSRDS. A key can have one or more aliases, and aliases can be changed after the key is created.

Key administrators versus key users

These are separate permission roles in the creation wizard:

• Key administrators can manage the KMS key through the KMS API. The policy can also determine whether administrators are allowed to delete the key.
• Key users are authorized to use the key for cryptographic operations such as encryption and decryption.

An identity may be selected in both areas, but the permissions have different purposes. Being a key administrator does not automatically describe the intended cryptographic-use permissions, and being a key user does not make the identity a key administrator.

KMS Key Creation and Policy Configuration

General-purpose customer-managed key

The first key is created with these settings:

• Key type: Symmetric
• Key usage: Encrypt and decrypt
• Alias: KMS key general
• Key administrator: The selected IAM account or identity
• Key user: The selected IAM account or identity
• Administrator deletion permission: Left at the wizard default

The KMS console generates a key policy from these selections. The policy includes statements for IAM user permissions, account-root access, key administration, and key usage.

The usage permissions shown for the selected key user include actions such as:

• kms:Encrypt
• kms:Decrypt
• kms:ReEncrypt*
• kms:GenerateDataKey*
• kms:DescribeKey

The generated policy also includes permissions for grants associated with key use.

Service-restricted EC2 and RDS key

The second key is also symmetric and supports encryption and decryption. It is intended for later use with EC2 and RDS and uses the alias KMS EBSRDS.

For this key, the wizard is completed without making the final permission selections because the key policy is edited directly. The policy contains two important permission areas:

1. Key administration: Grants administrative permissions to the selected account or IAM identity.
2. Restricted key usage: Allows use of the key only when the request is made through EC2 or RDS in us-east-1.

The restriction is implemented with a kms:ViaService condition. The relevant service values are:

ec2.us-east-1.amazonaws.com
rds.us-east-1.amazonaws.com

The policy therefore limits the permitted use path to those services and Region rather than allowing unrestricted direct use of the key.

When adapting the downloadable policy, replace the example account or user ARN in both required locations with the ARN from the account being used. The lesson obtains that ARN from the IAM console before pasting the completed policy into the KMS key policy editor.

Exam- or Assessment-Relevant Takeaways

• Recognize the distinction between AWS managed keys and customer-managed keys. Customer-managed keys provide customer-controlled aliases, policies, and configuration.
• A KMS key policy separates administration permissions from cryptographic usage permissions.
• A key user needs permissions for operations such as encryption, decryption, re-encryption, data-key generation, and key description when those operations are required.
• The kms:ViaService condition can restrict key use to requests made through named AWS services.
• A kms:ViaService value can include the service endpoint for a specific Region, such as ec2.us-east-1.amazonaws.com or rds.us-east-1.amazonaws.com.
• A symmetric key configured for encryption and decryption is appropriate for the demonstrated general-purpose and EC2/RDS scenarios.
• Do not confuse an alias with the key itself. The alias is a changeable human-readable name assigned to the key.
• Editing a key policy directly requires careful replacement of account-specific ARNs. A policy copied from course material must be adapted to the current account.

Tool / Feature Decision Guide

Requirement	Appropriate choice	Reason
Let AWS manage service encryption keys behind the scenes	AWS managed key	AWS creates these as supported services are used; customer control is more limited.
Control the key policy and identify the key with a custom name	Customer-managed key	The customer creates and configures the key.
Perform the demonstrated encryption and decryption workflow	Symmetric key	The lesson uses symmetric keys for both examples.
Name a key for easier identification in the console	Alias	Aliases are human-readable and can be changed or have additional aliases assigned.
Grant authority to manage the key	Key administrator permissions	Administration is separate from cryptographic use.
Permit an identity to perform cryptographic operations	Key user permissions	These permissions cover actions such as encrypt, decrypt, re-encrypt, and data-key generation.
Allow use only through EC2 and RDS in us-east-1	kms:ViaService condition	The condition restricts the request path to the specified services and Region.
Apply a policy supplied as a document rather than wizard selections	Edit the key policy directly	This provides more precise control but requires correct ARNs and conditions.

Common Traps / Misconceptions

• Treating administrators and users as the same role: Key administration and key usage are distinct policy categories.
• Assuming the number of AWS managed keys is fixed: AWS managed keys are created when supported services are first used, so the count varies by account.
• Using the wrong ARN in a copied policy: The account or user ARN in the sample policy must be replaced with the ARN for the current environment, including every required occurrence.
• Reading kms:ViaService as a general IAM permission: It is a condition that limits how the key may be used; it does not by itself define all required key actions.
• Forgetting the Region in the service value: The demonstrated condition uses Region-specific service endpoints for EC2 and RDS in us-east-1.
• Deleting the demonstration keys too soon: The lesson states that both keys are used in subsequent lessons, so they should remain available.
• Confusing an alias with key material: An alias is a display name and reference; changing it does not mean creating a new encryption key.
• Assuming wizard defaults express every desired restriction: The second key requires direct policy editing to impose the EC2/RDS service restriction.

Real-World Engineer / Analyst Notes

• Start by deciding whether the workload needs a customer-managed key or whether an AWS managed key is sufficient. Customer-managed keys add control but also create policy and lifecycle responsibilities.
• Keep administrative permissions narrower than cryptographic-use permissions where practical. The lesson’s wizard exposes these as separate decisions for a reason.
• Review generated policies instead of accepting them blindly. The policy preview is an opportunity to verify principals, actions, resources, and conditions.
• Service restrictions are especially useful when a key is intended for a particular integration, such as EBS-related EC2 use or RDS encryption. Confirm that the service value and Region match the actual workload.
• Treat account-specific ARNs in downloaded policy templates as placeholders. Validate every principal before saving the policy.
• After creation, inspect the key policy, cryptographic configuration, tags, key material and rotation settings, and aliases from the key details page.

Quick Reference Summary

• Create customer-managed keys from the KMS console under Customer managed keys.
• The demonstrated key type is symmetric, with usage set to Encrypt and decrypt.
• Use aliases such as KMS key general and KMS EBSRDS to identify keys.
• Configure key administrators separately from key users.
• General key usage includes encryption, decryption, re-encryption, data-key generation, and key description actions.
• Restrict the EC2/RDS key with kms:ViaService values for ec2.us-east-1.amazonaws.com and rds.us-east-1.amazonaws.com.
• Replace sample principals with the correct account-specific ARN before saving a policy.
• Preserve the two keys for the subsequent hands-on lessons.

Flashcards

Q: When should you choose a customer-managed KMS key instead of relying on an AWS managed key in this lesson’s context?

A: Choose a customer-managed key when you need to control its policy and configuration, including aliases and permitted administrators or users. AWS managed keys are created and managed by AWS for supported services.

Q: What is the decisive difference between a KMS key administrator and a KMS key user?

A: A key administrator manages the key through KMS permissions, while a key user performs permitted cryptographic operations such as encryption or decryption. The policy should represent these as separate permission areas.

Q: You need a key for the general encryption and decryption workflow demonstrated in the lesson. Which key configuration should you select?

A: Select a symmetric key with key usage set to Encrypt and decrypt. The lesson leaves advanced options at their defaults.

Q: What does the alias KMS key general represent?

A: It is a human-readable display name assigned to a customer-managed KMS key. It is not the key material itself and can be changed or supplemented with other aliases.

Q: Which policy condition restricts a KMS key to use through particular AWS services?

A: The kms:ViaService condition restricts use to requests made through specified services, such as EC2 or RDS.

Q: A key should be usable only through EC2 and RDS in us-east-1. Which service values should the policy allow?

A: Allow ec2.us-east-1.amazonaws.com and rds.us-east-1.amazonaws.com in the kms:ViaService condition.

Q: Why might the AWS managed key count differ between two accounts?

A: AWS managed keys are created behind the scenes when supported AWS services are first used. Accounts that have used different services can therefore have different counts.

Q: Which actions are represented in the demonstrated general key-user permissions?

A: They include kms:Encrypt, kms:Decrypt, re-encryption, data-key generation, and key description, along with grant-related permissions shown in the generated policy.

Q: When is directly editing a KMS key policy preferable to using only the creation wizard selections?

A: Direct editing is useful when the policy needs precise restrictions, such as allowing use only through EC2 and RDS in a specific Region. It requires careful validation of principals and conditions.

Q: What is the main operational trap when copying the downloadable EC2/RDS policy document?

A: The example contains account-specific principal values that must be replaced with the correct ARN for the current account or IAM identity in every required location.

Q: What should you inspect after creating a customer-managed KMS key?

A: Review its key policy, cryptographic configuration, tags, key material and rotation settings, and aliases from the key details page.

Practice Questions

Question 1

An operations team is creating a KMS key for a workload that must support encryption and decryption. They do not need asymmetric cryptography or multi-Region settings for this exercise. Which configuration best matches the lesson?

A. Asymmetric key with signing and verification usage
B. Symmetric key with Encrypt and decrypt usage
C. Symmetric key with signing and verification usage
D. AWS managed key with no key policy

Correct answer: B

The demonstrated keys are symmetric and configured for encryption and decryption.

Question 2

An engineer gives an IAM identity permission to administer a KMS key but then discovers that the identity cannot perform the intended encryption operation. What is the most likely explanation?

A. The alias must match the IAM user name
B. Key administration and key usage are separate policy permissions
C. AWS managed keys cannot be used for encryption
D. The key must be converted to asymmetric mode

Correct answer: B

The lesson separates key administrators from key users. Administrative authority does not replace the cryptographic-use permissions required by the workload.

Question 3

A customer-managed key is intended for an EC2 and RDS integration in us-east-1. The team wants to prevent the key from being used through unrelated services. Which policy design is most appropriate?

A. Add an alias named EC2-RDS
B. Grant only key administrator permissions
C. Add a kms:ViaService condition for the EC2 and RDS service endpoints in us-east-1
D. Remove the key description from the policy

Correct answer: C

The decisive requirement is restricting the request path to particular services and a Region, which is what the kms:ViaService condition provides.

Question 4

An engineer copies the course’s KMS key policy into a different AWS account without changing the principal values. What should be checked first when adapting the policy?

A. Whether the alias is globally unique
B. Whether the account-specific ARN values identify the intended administrator and key user
C. Whether the key is listed under AWS managed keys
D. Whether the console automatically changes all principals

Correct answer: B

The policy document must be updated with the correct ARN for the current account or IAM identity wherever the sample principal appears.

WordPress Metadata

Suggested Slug:
aws-kms-customer-managed-keys-key-policies

Meta Description:
Learn how to create AWS KMS customer-managed symmetric keys, configure administrators and key users, and restrict one key to EC2 and RDS with kms:ViaService conditions.

Tags:
AWS KMS, customer-managed keys, KMS key policies, symmetric encryption, IAM, EC2, Amazon RDS, kms:ViaService, AWS security, SOA-C03