KMS Other

• KMS Key Policies

  • Control access to KMS keys, “similar” to S3 bucket policies.

  • Difference: you cannot control access without them with KMS, you can with S3s; you must create one.

  Default KMS Key Policy:

  • Created if you don’t provide a specific KMS Key Policy.

  • Complete access to the key to the root user = entire AWS account.

  Custom KMS Key Policy:

  • Define users, roles that can access the KMS key.

  • Define who can administer the key.

  • Useful for cross-account access of your KMS key.
• Default KMS Key Policy

  • It gives the AWS account that owns the KMS key, full access to the KMS key.

  • KMS Key Policy does NOT automatically give permission to the account or any of its users.

  • Allows the account to use IAM policies to allow access to the KMS key, in addition to the key policy.

  
• KMS Key Policies

  AWS Owned Keys.

  • You cannot view or change the Key Policy.

  AWS Managed Keys (e.g., aws/ebs).

  • You can view the Key Policy.

  • You cannot change the Key Policy.

  AWS Customer Managed Keys.

  • You can view the Key Policy.

  • You can edit the Key Policy.

  A) E.g. Policy: not something you have to remember.

  
• Custom KMS Key Policy – Allow Admins

  In Policy example ('Actions' are API calls):

  • KMS Key administrators have permissions to manage the KMS key.

  • KMS Key administrators cannot use the KMS Key Cryptographic Operations (Encrypt / Decrypt...), so they are NOT a key user.

  • You can add IAM Users / Roles as KMS Key administrators.

  
• Custom KMS Key Policy – Allow Users to Directly Use the KMS Key

  In this Policy exmaple:

  • Allows IAM Users / Roles to use the KMS Key directly.

  • IAM Users / Roles don’t need IAM Policies if the KMS Key is in the same account.

  • • The KMS Key explicitly authorises the IAM Principal.

  • • Because the Users explicitly outlined in the KMS Key Policy itself, then they are authorised to use this key. They don't then need an IAM policy.

  • Alternative is Default KMS Key + IAM Policy.

  (Principle root: a target account if you wanted to have cross-accounts).

  
• KMS Grants

  • Allows you to grant access to specific AWS KMS keys to other AWS accounts and IAM Users / Roles within your AWS account

  • Often used for temporary permissions

  • Can be created for a variety of operations, including encrypt, decrypt, sign, and verify, as well as creating more grants

  • Grant are for one KMS Key only, and one or more IAM Principal

  • Once granted, a principal can perform any operation as specified in the Grant

  • Grants do NOT expire automatically, you must delete them manually

  • You don’t need to change KMS Key Policy or IAM Policy
• KMS Grants

  Your key permissions are definitely ruled by your KMS key policy and also any KMS key grant you may have defined on top.

  The benefit of using a grant is that you do not need to change your KMS key policy or the IAM policy.
• Creating a KMS Key Grant

  • Using AWS CLI. (No need to remember example for exam)

  • Make sure to delete a KMS Key Grant when you’re done using it.

  • For now, there’s no support in the AWS Console.

  
• KMS Grants – AWS Service Usage

  • Grants are commonly used by AWS services that integrate with AWS KMS to encrypt your data at rest.

  • The AWS service creates a Grant on behalf of a user in the account, uses its permissions, and retires the grant as soon as its task is complete

  • Users must have the CreateGrant IAM permission

  
• Custom KMS Key Policy –

  Grants for AWS Services Use Cases.

  Use this example KMS Key Policy with:

  • Amazon EBS and Amazon EC2 to attach an encrypted EBS volume to an EC2 instance.

  • Amazon Redshift to launch an encrypted cluster.

  • AWS services integrated with AWS KMS that use grants to create, manage, or use encrypted resources with those services.

  
• Troubleshooting: Can’t Start an EC2 Instance with Encrypted EBSVolume

  Reasons:

  • KMS key might be disabled or deleted.

  • EBS service might not have the required permissions to use KMS key.

  Resolution:

  • Make sure the KMS key is exists and enabled.

  • Make sure that EBS service has the require permissions to create KMS Grants in behalf of the specified principal.

  • kms:GrantIsForAWSResource – allows AWS services to create Grants (e.g., EBS).

  
• KMS Key Authorisation Process

  Only need to remember the idea, not everything.

  Service Control Policies (SCPs) = a type of organisation policy that you can use to manage permissions in your organisation.

  VPC Endpoint = if you're accessing the KMS service privately, otherwise, miss that step.

  Col 2, row 3: the default KMS Policy will be yes.

  Just remember the concepts of:

  1) Grants,

  2) Key Policies,

  3) Default Key Policies - that would delegate actions to IAM

  4) For cross account access

  
• KMS Key Authorisation Process – Example 1

  C1R2: is the Key Policy allowing the action for the caller? No, because we use the default KMS Key Policy.

  C1R4: The Key Policy is a Default Key Policy, therefore, yes, this one is a box for yes.

  C2R1: Then we look at the IAM Policy, does Alice have the proper IAM permissions (yes or no)? If no: denied. But if yes: then you go into the Key trust.

  C3R1: It's in the same account, and it would be allowed.

  
• KMS Key Authorisation Process – Example 2

  C1R2: No, because we authorise an entire account. So no Key Policy, or Grants.

  C1R4: Yes.

  C2R1: Yes.

  C3R1: No, because we're doing cross accounts. And there is no Grant.

  C3R3: Then we look at the IAM Policy of the caller to perform the action. And if the caller has the proper policy in this account, then, yes, we're good to go and we have an ALLOW.

  
• KMS Key – Cross-Account Access

  As per example.

  ARN = Amazon Resource Names

  
• KMS Key – Cross-Account Access

  Usage of External KMS Keys with AWS Services (not users).

  The Actions in both polices need to match.

  
• KMS Key – Cross-Account Access

  Through assuming an IAM Role.

  The KMS Key Policy in Account A is a simple default KMS key policy, allowing access to the key from anything within the same account.

  
• Sharing KMS Encrypted RDS DB Snapshots

  • You can share RDS DB snapshots encrypted with KMS CMK (Customer Master Key*)/key with other accounts, but must first share the KMS key with the target account using Key Policy.

  *CMK deprecated, being replaced by AWS KMS key and KMS key.

  
• Asymmetric Encryption

  The only thing the public key can do is encrypt.

  The only thing the private key can do is decrypt.

  Asymmetric KMS keys used for encryption/decrytion and/or signing/verification.

  • Private Keys never leaves AWS KMS unencrypted

  
• Digital Signing with KMS Asymmetric.

  • Helps you verify the integrity of messages or files sent across different systems.

  • Verify that file has not been tampered with in transit.

  • Public Key used to verify the signature while Private Key used in the signing process.

  • Use cases: document e-signing, secure messaging, authentication/authorisation tokens, trusted source code, e-commerce transactions, ...

  
• KMS API Calls Limits & Data Key Caching

  • When your application makes multiple API calls to KMS and you hit service limits (requests per second limit)...

  • • (KMS is an expensive service).

  • Data Key Caching allows you to reuse data keys that protect your data

  • Instead of generating a new data key for each encryption operation

  • Reduce latency, improve throughput, reduce cost, stay within service limits, ...

  • Implemented using AWS Encryption SDK

  • Note: encryption best practices discourages reuse of data keys (tradeoff cost / security)

  
• Changing The KMS Key For An Encrypted EBS Volume

  • You can’t change the encryption keys used by an EBS volume

  • Create an EBS snapshot and create a new EBS volume and specify the

  new KMS key

  
• Automate Cross-Account EBS KMS-Encrypted Snapshot Copies

  It's going to be shared to the new account.

  It's going to be decrypted by the first KMS key, and then it's going to be re-encrypt by the second KMS key.

  In the network diagram, the KMS key policy is attached to the target account.

  
• EBS Encryption – Account level setting

  • New Amazon EBS volumes aren’t encrypted by default

  • There’s an account-level setting to encrypt automatically new EBS volumes and Snapshots

  • This setting needs to be enabled on a per-region basis

  
• Encrypt Un-encrypted EFS File System

  • You can’t encrypt an existing un-encrypted EFS File System.

  • Create a new encrypted EFS File System and migrate the files using AWS DataSync.

  When we create the encrypted EFS file system, it will at first be empty. Then we use AWS DataSync to migrate from one to the other.

  EFS (Amazon Elastic File System) provides a simple, scalable fully managed elastic NFS file system for EC2s (Shared File Storage).

  
• KMS with SSM Parameter Store

  • SSM Parameter Store uses KMS to encrypt/decrypt parameter values of type Secure String.

  • Two types of Secure String Parameters:

  • • Standard – all parameters encrypted using the same KMS key

  • • Advanced – each parameter encrypted with a unique data key (Envelope Encryption)

  • Specify the KMS key or use AWS Managed Key (aws/ssm)

  • Works only with Symmetric KMS Keys

  • Encryption process takes place in AWS KMS

  • Note: you must have access to both the KMS key and the parameter in SSM Parameter Store