Deploy A KMS Key and Key Coverage with CloudFormation | by Teri Radichel | Cloud Safety | Aug, 2022

ACM.27 Testing our generic KMS Key template with the roles we created for encrypt, decryption, and administration

It is a continuation of my collection on Automating Cybersecurity Metrics.

On this put up I’m going to deploy a KMS key with a CloudFormation template utilizing the ARNS for the roles we created earlier. We wrote some preliminary code for our key and coverage however now we’re going to check it out.

Let’s overview what we thought of and created up thus far which we’ll be utilizing to deploy our KMS key and Key Coverage.

A generic KMS Key template:

A job that might be allowed to encrypt knowledge:

A job that might be allowed to decrypt knowledge:

A KMS administrator function that may administer our key:

A key coverage limiting key use to Secrets and techniques Supervisor:

The IAM scripts within the above posts moved to a single folder except our IAM batch job insurance policies:

Now we are going to take a look at the template with the ARNs for the roles we created above and can repair any points with the code we initially wrote.

Function ARNs — template parameters or exports?

We may do what we’ve finished earlier than and use exports from all our different CloudFormation stacks to move within the ARNs utilized by our key template. The issue is that in the long run, among the customers could also be in a distinct account than the one we’re utilizing to create the important thing. For testing functions we’ve all the pieces in a single account however finally the admin function might be in the identical account because the keys however the encryption and decryption person roles will probably be in a separate account.

Based mostly on these necessities, we’ll use an output for the admin function ARN since we are able to anticipate that the CloudFormation stack used to deploy it’s in the identical account as the important thing itself. Nevertheless, we’ll move within the person ARNs allowed to encrypt and decrypt the information since these are probably coming from exterior accounts. If we wanted to we may share secrets and techniques throughout accounts later to get round this dilemma however for our present testing we’ll merely move within the ARNS.

Deploy Script

Alright now we are able to attempt to deploy our key. We are able to use a deploy script like earlier than and move within the two ARNs we’d like. We are able to move in a tough coded description since this specific script is, in the mean time, particular to our credential encryption key. What you’ll discover for those who run that script is that you just’ll get an error like this:

It’s telling us that if we run this script, the person creating the script received’t be capable to replace the important thing coverage sooner or later. Hmm, we’ve key a key administrator. Perhaps the error message signifies that the person deploying the important thing can not replace the important thing sooner or later.

I may briefly take a look at that concept by including the person that’s operating the deployment script (observe this was just for testing functions and has been eliminated):

We are able to get the ARN of the present person with the next command:

aws sts get-caller-identity

Run that command and one of many values it returns is the present function used to run the command. I presume you might be following my prior directions to run these instructions from an EC2 occasion that you just assigned a job. 🙂

We are able to get solely the ARN through the use of the next command:

aws sts get-caller-identity --query Arn

We are able to assign the ARN to a variable in our bash script like this:

myarn=$(aws sts get-caller-identity --query Arn)

There are some things we have to repair with the ARN output by that command:

• Take away the occasion title and trailing slash on the finish of the ARN.
• Exchange “sts” with “iam”.
• Exchange “assumed-role” with “function”
• Take away the double quotes.

We are able to use reduce to take away the occasion ID and sed to exchange and take away the values we don’t need in our ARN, so it matches the format of our different ARNs.

Let’s add yet another part to our KMS key deployment script. For now, we’ll give ourselves full permissions to switch this KMS key whereas we’re testing. We are able to prohibit these permissions additional later after we discover what permissions this ARN requires for deployments.

Delete the CloudFormation stack and check out once more. Sadly, we get the identical error.

Ought to we add the foundation person to our KMS key coverage?

The error message seems to be incorrect as a result of we’ve given our person all entry to any KMS useful resource. Nevertheless, CloudFormation nonetheless warns us that we’re locking ourselves out of the power to replace the important thing coverage. Maybe the CloudFormation deployment code checks to see if the foundation person within the AWS account the place the important thing exists has entry? It’s laborious to know as a result of the error message isn’t pinpointing precisely what the issue is.

Why would possibly CloudFormation need the foundation person to have entry? It could possibly be because of the truth that individuals have been identified to utterly lock themselves out of their very own assets utilizing a defective coverage. At that time, the one recourse is to contact AWS to right the issue. So what does AWS need us to do? Maybe we’re supposed to make sure the foundation person in our account has full entry to the important thing.

It will be straightforward sufficient to outline a coverage assertion for the IAM person root, however in some circumstances “root” refers to greater than we predict it ought to. Discuss with the documentation to find out precisely what including root to a key insurance policies does (which could possibly be completely different for different assets, so at all times examine the documentation.)

When the principal in a key coverage assertion is an AWS account principal expressed as arn:aws:iam::111122223333:root", the coverage assertion does not give permission to any IAM principal.

Nicely that’s good however I do know that root provides entry to extra than simply the foundation person in an account so what does it do?

As a substitute, it provides the AWS account permission to make use of IAM insurance policies to delegate the permissions laid out in the important thing coverage. (A principal in arn:aws:iam::111122223333:root" format does not characterize the AWS account root person, regardless of the usage of “root” within the account identifier. Nevertheless, the account principal represents the account and its directors, together with the account root person.)

I’m wondering how, precisely, does AWS decide who an “administrator” within the account is. A job? A person? The managed admin coverage? I’m unsure so I are typically extra express after I grant permissions.

However we may attempt to add the foundation person of the account the place the secret’s being deployed to permit any administrator in that account to alter the important thing coverage to see if that resolves our downside.

Let’s add the foundation person to the assertion that enables any KMS motion for our present person. We are able to reference the present account ID the place the secret’s being deployed:

- !Sub arn:aws:iam::${AWS::AccountId}:root

Delete the stack and check out once more.

Identical error.

Buggy error messages and parsing logic in CloudFormation?

I later realized the error message will not be correct in any respect. Is it a bug? Is it an issue with the parsing logic utilized by CloudFormation? I’m unsure.

In response to a weblog put up I discovered, you don’t want so as to add the foundation customers to your coverage. You solely want the admin coverage, which we’ve. (??) So I fiddled round with the coverage, evaluating it to that weblog put up, and I lastly bought it to deploy with just a few tweaks associated to single and double quotes probably. I modified a few issues and wrote in regards to the potential explanation for the error message right here and the way I bought it working:

Since I bought this working I simply left my three IAM identities in there as directors for the second. I plan to take away them however I’ve to arrange the important thing administrator person to deploy this script first. That’s going to require an AWS CLI profile with MFA to imagine the important thing administrator function. I’ll clarify how to do this in an upcoming put up.

Right here’s our code in the mean time I wrote this put up.

KMS Key and Coverage CloudFormation Template (for the second — comply with for updates):

Parameters:

Assets

Deployment Script:

As with most builders, I wish to get on and really get the system working and all these AWS insurance policies are taking over lots of time. And that’s the place the not-so-zero-trust insurance policies sneak in. However I’ll revisit this. In actual fact, for those who’re trying on the code in GitHub it’s already been up to date. I’ll clarify how I did that and what you’ll want to do to execute the code with AWS CLI profiles that use MFA in upcoming posts.

Observe for updates.

Teri Radichel

When you favored this story please clap and comply with:

Medium: Teri Radichel or E mail Listing: Teri Radichel
Twitter: @teriradichel or @2ndSightLab
Requests providers by way of LinkedIn: Teri Radichel or IANS Analysis

© 2nd Sight Lab 2022

All of the posts on this collection:

____________________________________________

Writer:

Cybersecurity for Executives within the Age of Cloud on Amazon

Want Cloud Safety Coaching? 2nd Sight Lab Cloud Safety Coaching

Is your cloud safe? Rent 2nd Sight Lab for a penetration take a look at or safety evaluation.

Have a Cybersecurity or Cloud Safety Query? Ask Teri Radichel by scheduling a name with IANS Analysis.

Cybersecurity & Cloud Safety Assets by Teri Radichel: Cybersecurity and Cloud safety lessons, articles, white papers, displays, and podcasts