A KMS Key Administrator Position and IAM Coverage | by Teri Radichel | Cloud Safety | Aug, 2022

August 8, 2022

2

ACM.23 Making a KMS Key administrator consumer and position plus IAM insurance policies versus Managed Insurance policies in CloudFormation

This can be a continuation of my collection of posts on Automating Cybersecurity Metrics.

With a purpose to deploy a KMS key I’m going to want to assign a KMS key administrator. I may assign a consumer who has to login and take actions with MFA however I’m in all probability going to need to automate a few of these actions. Because of this, I’m going to make use of a job for key administration however I’ll permit sure customers to imagine this position, with MFA.

I can’t give permission on to an EC2 occasion for this objective so I can require the administrator to imagine a job with MFA. I believe. I bumped into problems making that work once I examined with an precise KMS key, which I clarify in a separate submit.

Inputs and Outputs for KMS Key Administrator

For now, I’m testing this all out in a improvement account. However I need to plan for future deployment of KMS performance in a separate account. The AWS identities who can assume the administrator position might or might not be in the identical account so I’m protecting this template versatile and passing within the ARN for the identification allowed to imagine the position.

I can’t use a CloudFormation output if the script to deploy the consumer who can assume the position is in a separate account from the one the place I run the CloudFormation template to deploy this key administrator.

Listing Construction for KMS Supply Code

All of the CloudFormation templates associated to KMS exist within the /kms/cfn listing of our codebase. We’re going to deploy one administrative position. We may create a approach so as to add extra admins who can assume the position later, however for now I created a single consumer named KMS Consumer with CloudFormation the identical approach I created a Batch Administrator on this submit:

In a big group, the code within the /kms listing in our code base could possibly be maintained in a separate repository restricted to individuals who deploy and administer KMS keys in a separate AWS account.

I’m going to interrupt aside the KMS admin coverage right into a separate CloudFormation template. Then I’ll reference the output from the KMS administrator template in my KMS administrator coverage.

This provides me some flexibility if I have to reuse both the administrator template or the position template sooner or later.

I’ll deploy that coverage finally within the KMS AWS account and directors can have entry to all keys in that account for now, so I’m going to permit directors for now to take motion on any key in that account.

I’m leveraging a pseudo parameter described in earlier posts so this template will work in any account the place it’s deployed. This parameter will retrieve the present AccountId the place the script is deployed to outline the important thing ARN variable.

AWS::AccountId

Attaching a Coverage to our Position

Right here’s the place it will get tough. We have to discover some choices.

The CloudFormation documentation for AWS IAM insurance policies doesn’t checklist any choices for GetAtt so we’ll solely have the ability to output the identify of the coverage if that is correct:

Then if you verify the documentation for a job it doesn’t appear to point you can move in a customized position ARN or Title to your coverage. You may solely use a reference to a coverage that’s in the identical template and an inline coverage.

Nicely that’s not good if we need to create a number of roles and have them reference the identical coverage with out re-deploying our coverage on a regular basis.

It seems to be like we will move within the ARN to a AWS Managed coverage into the position template to affiliate it with our position:

I ponder if CloudFormation truly is aware of the distinction between an ARN for an AWS managed coverage and the ARN for a coverage we created ourselves. Let’s see if we will move in our personal ARN to this parameter. Why not?

Sadly, since we will solely output a reputation from our coverage CloudFormation template and never the complete ARN, we’ll should assemble the ARN the best way I confirmed you in an earlier submit with the Sub operate.

Proper about now’s the place I make a request to AWS to add AWS:IAM::PolicyDocument to the AWS CloudFormation documentation. #awswishlist

I’ve to attempt to determine whether or not the Motion takes a single useful resource or a listing, and likewise you’ll should put a splash above and never inline with Impact within the following instance to create a listing of statements, not a listing of results. This will get a bit complicated and stable yaml examples with a separate web page documenting coverage paperwork would assist.

You may examine this iteration to my beforehand first lower of this coverage to see the distinction in the place I’ve put dashes after testing out my coverage.

Unique:

It’s at this level of testing the place you’ll be taught that you just can’t create a coverage with out assigning a consumer, position, or a bunch:

Solely as a result of I’m actually curious if I can use our coverage within the managed ARN parameter above, I’m going to create an empty group on this template and move it in, with nobody in it, as a result of I need to see if I can then move the coverage in as a managed ARN coverage. As if I’ve time for this however I’m at all times extra curious than I ought to be.

If we take a look at the required fields for an IAM Group in CloudFormation not a single worth is required. Nonetheless, we’ll give this group a reputation to keep away from confusion and move it into our coverage in the identical template. We gained’t assign any customers to our group or any permissions.

What’s actually odd at this level is that I spent far too lengthy attempting to resolve a bug with an invalid group identify. In the long run it appeared to work and I didn’t change something (that I do know of). If I truly had a typo right here I couldn’t see it and the error message was not precisely telling me what the precise downside was. I copied and pasted the identify of the useful resource I referenced so I do know it was right.

In any case, I lastly obtained my placeholder group and the coverage deployed.

Nonetheless, once I take a look at the outputs of this template, I discover that the output of the reference to the coverage doesn’t match the coverage identify I offered within the template:

Hmm. The documentation is wrong. The PolicyName seems to do nothing on this case. The worth we see above is outwardly the useful resource bodily ID:

After I take a look at the useful resource for CloudFormation there is no such thing as a hyperlink to my coverage, nor can I discover it in my coverage checklist in IAM:

After I navigate to my group I see that this coverage obtained utilized as an inline coverage for my group. So regardless of the way you attempt to create a stand-alone coverage with AWS::IAM::POLICY you’re not going to get one.

The documentation could possibly be higher on all the above factors.

However the factor is — you’ll be able to create a brand new managed coverage on your account:

That’s actually what we want on this case. Maybe the documentation for an IAM Coverage ought to level to this different sort of coverage customers can create standalone. I’m undecided why it’s known as “managed” when customers can create it themselves.

Let’s change our coverage from:

AWS::IAM::Coverage

to

AWS::IAM::ManagedPolicy

What do we have to change in accordance with the documentation? Change PolicyName to ManagedPolicyName. Let’s attempt to take away the reference to the group.

As a result of we modified the kind we get this errors:

An error occurred (ValidationError) when calling the CreateChangeSet operation: Replace of useful resource sort just isn't permitted. The brand new template modifies useful resource sort of the next sources: [kmsadminpolicy]

Delete the CloudFormation stack and begin over. The stack creation accomplished shortly with out the necessity to affiliate the coverage with a useful resource.

Greatest apply in AWS is to make use of a standalone coverage somewhat than an inline coverage, so any more we’ll use the ManagedPolicy sort somewhat than the Coverage sort. Sooner or later we must always return and regulate our batch admin scripts to align with that finest apply.

Though our “checklist” of finest practices says we must always not use inline insurance policies, that’s not likely an entire thought. If the one place you ever use a coverage is with one consumer, group, or position, it may be higher to deploy an inline coverage so nobody else can assign it to the mistaken identification sooner or later.

Deploy the KMS Administrator Position

Alright now we will attempt to deploy the KMS admin position. Nonetheless, if we verify the outputs of our final deployment you’ll discover that the ManagedPolicy CloudFormation stack output an ARN, not a coverage identify.

Again to our KMS admin position template once more. This time we’re going to take away our sub and the concatenation of values to create our position ARN. We’ll as an alternative use ImportValue to reference the output of our coverage template. As well as, I’m going to rename the output worth to an acceptable identify for the reason that output is an ARN, not a reputation.

With a purpose to deploy our KMS administrator a parameter for the ARN of an identification that may assume the position. In the end totally different AWS accounts will likely be concerned, however for now, with a purpose to take a look at this script and deploy an admin in our take a look at account, I’ll move in the ARN of a consumer I created to simulate a KMS administrator consumer related to a digital MFA system and take a look at with all of the sources in a single account.

When utilizing separate accounts we’ll have to additional modify our code however let’s hold it easy for now and take a look at out this deployment script. It’s at all times a good suggestion when writing code to check it in as small as items as doable as you go. I’ve already written a number of code with out testing it up thus far, greater than I would love, resulting from all of the dependencies. Pondering again, I may have examined this admin position quite a bit sooner however I needed to ponder the entire design a bit so simply getting again to this now.

To seek out the ARN for the position or consumer you need to move into this script, navigate to IAM within the AWS console, then roles or customers, after which click on on the identification you need to permit to imagine the important thing administrator position. There, you’ll see the ARN. Copy and paste it to be used with our deployment script.

Tip: You may click on the copy icon to repeat the ARN.

Now execute the deploy script:

./deploy.sh [your arn here without the brackets]

As anticipated, I discovered just a few typos once I tried to deploy the code and glued them. Then the position efficiently deployed.

Right here’s our working supply code (for the second — it modified fairly a bit on subsequent testing with a KMS key as will likely be defined in a future submit):

KMS Admin Coverage

KMS Administrator Position

Deployment Script

Comply with for updates — these templates had some adjustments upon additional testing.

Teri Radichel

If you happen to favored this story please clap and comply with:

Medium: Teri Radichel or Electronic mail Record: Teri Radichel
Twitter: @teriradichel or @2ndSightLab
Requests companies by way of LinkedIn: Teri Radichel or IANS Analysis