Friday, September 23, 2022
HomeCyber SecurityIncluding a KMS Key Id to AWS SSM Parameter Retailer | by...

Including a KMS Key Id to AWS SSM Parameter Retailer | by Teri Radichel | Cloud Safety | Sep, 2022


ACM.59 Encrypting our batch job session parameter with a key {that a} batch job can use to acquire session credentials

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

Within the final submit we added the flexibility for our Lambda operate that generates a cryptographically safe batch id to retailer a price in AWS SSM Parameter Retailer.

When encryption doesn’t prevent

Though we used a SecureString we used the default AWS encryption. What does that do for us? It encrypts the info such that the one individuals with permission to make use of our AWS account can decrypt the info. So mainly, the encryption just isn’t doing that a lot for us internally. I’m not even certain if that encryption prevents individuals who work at AWS from seeing the info however I by no means dug into it as a result of it’s merely not adequate as an encryption resolution. I wrote about this in my ebook and on my weblog — the encryption fallacy.

AWS Parameter Retailer deficiency — No Useful resource Coverage

AWS Parameter retailer doesn’t provide useful resource insurance policies. Though Parameter Retailer has the idea of “insurance policies” it serves a unique goal at the moment. We will’t put a coverage on a parameter to restrict who can entry it from the parameter facet.

If we need to stop anybody in our account from making a batch job session ID parameter with a reputation beginning with “batch-job-” utilizing IAM insurance policies, we would want so as to add a deny assertion to the coverage for each consumer and each function {that a} consumer can or different utility can assume that denies them from making a batch job parameter that begins with “batch-job-”, or we will merely deny their entry to SSM Parameter retailer.

KMS to the rescue

There are a couple of methods to unravel the above issues however one among them can be to make use of a KMS. We will create a KMS key and use it to encrypt our batch job session parameters. We will limit the flexibility to encrypt with this KMS key to our Lambda operate that kicks off batch jobs. No customers can assume that operate function as a result of it’s restricted by the belief coverage to Lambda.

We do face the issue of somebody assigning the function to a unique Lambda operate. I’ll handle points with function assumption in a unique submit.

Who ought to encrypt and decrypt our parameter?

It’s fairly clear the Lambda operate goes to encrypt the parameter. We’ll cross in its function to our KMS script for the encryption ARN.

Who must decrypt the worth? Effectively, our subsequent batch job step goes to make use of the ID to retrieve the batch job title so it might probably set off the suitable job. That will be our TriggerBatchJob Lambda function we created for the Lambda operate we created and examined manually in a previous submit. The function was created by way of CloudFormation so we will reference the outputs of that stack to cross within the decryption ARN to our KMS key template.

Retrieve the ARNs and deploy the important thing

In case you recall we have already got a template and deployment script for this goal. Our deploy script deploys our present key from a previous submit like this:

We will simply copy the code that deploys our different KMS key and alter the ARNS and title.

With the assistance of our naming conference we will simply discover the Lambda roles in our CloudFormation stack. We want the names of those two stacks for our deploy script.

The primary is our encryption function. Get the output title to make use of in our deploy script:

Get the output title for the decryption function:

Replace the copied and pasted code for the brand new key within the deploy.sh script:

Run the deploy script within the Key folder:

./deploy.sh

Repeat the method above for the KeyAlias/deploy.sh script. Copy the code for the prevailing alias and edit it to work for the brand new alias.

Add the KMS key to the code that creates the SSM Parameter

Return to our Lambda operate code from the final submit.

[link here]

Recall from the put_parameter documentation how we add a KeyId.

We have to edit the road of Boto3 Python code within the CloudFormation script that creates the parameter and add the KMS Key ID. Recall that you would be able to get the KMS Key ID from the CloudFormation stack outputs or look it up within the KMS console.

We may hardcode this key ID into our code, however what’s the issue with that?

Later after we need to deploy our code to Dev, QA, and Prod environments we’d have to change the code to deploy it. Even id I wished to share my code on GitHub I’d need to hardcode and checkin my KMS key ID after which the code wouldn’t work in your setting. In case you discover that you must alter code to deploy an utility, the deployment for the appliance just isn’t carried out appropriately. You must actually repair that.

In our case, we will retrieve it from the output of the KMS Key stack we simply created and insert it into our code. Although I warn prospects about unencrypted setting variables in Lambda features on this case we’d be creating an encryption key for the Lambda operate to encrypt the the ID of one other KMS key. I’m nonetheless considering it over however for the second I’m going to simply add the important thing ID to an setting variable and reference it within the code.

You possibly can see the place I added the setting variables under, per the Lambda CloudFormation documentation, and the way I get the worth from the setting variable when the code executes. I additionally must import the os bundle.

Re-deploy your Lambda code. Check your Lambda Operate.

Inconsistent KMS implementations throughout AWS Companies

Right here’s the place it will get fascinating……We get the next error:

In case you recall after we carried out this performance with AWS Secrets and techniques supervisor we had so as to add Encrypt permissions to each the encryption and decryption ARNs in our coverage.

Odd, however OK. One way or the other defined away by envelope encryption in some locations. Nevertheless, now I’m not so certain about that rationalization on condition that two related providers deal with the identical state of affairs otherwise.

Not solely that I went on to attempt to clear up the issue by switching out the motion when utilizing AWS Secrets and techniques supervisor as follows and hit different inconsistencies.

First the straightforward half.

An If assertion for an IAM Coverage Motion primarily based on a Situation

Initially we we have to know which service we’re deploying the important thing for thus I added a brand new parameter to point the service:

I need to use the CloudFormation if operate. It modifications the worth included in a template primarily based on whether or not one other worth is true or false.

Our service title just isn’t a real or false worth, so now we have to make use of one different CloudFormation assemble earlier than our if assertion known as a situation (to not be confused with IAM coverage situations). We might want to add a Circumstances part to the template much like Parameters, Sources, Mappings, and Outputs and outline our situations.

Our situation will consider the next:

If the providers just isn't Secrets and techniques Supervisor then the worth is true, in any other case it's false.

or in CloudFormation syntax:

Then we will use an if assertion to alter the motion in our coverage if it’s Secrets and techniques Supervisor:

Change the deploy script to cross within the service parameter. Don’t add it to the tip of the listing. The important thing description parameter has areas and points that aren’t absolutely resolved on the time of this writing so we would like the important thing description to be the final parameter.

Advert the brand new service title parameter because the second to final parameter we cross into the deploy_key() operate in our kms_functions.sh file.

Then add the parameter to the deploy_key operate.

Observe that I altered the parameters on this file to make use of the worldwide add_parameter operate I wrote about in a previous submit:

Deploy the keys utilizing the deploy script within the Key folder.

./deploy.sh

Examine to see that the 2 key insurance policies have the correction motion.

Sure. Relying on which service is handed in to the parameter, the actino can be Decrypt or Encrypt.

Limiting a key to make use of with Parameter Retailer — not potential

Because it seems, there may be further inconsistency in the way in which that Secrets and techniques Supervisor and System Supervisor Parameter Retailer work together with KMS.

I assumed we may merely alter this situation to the suitable service.

I modified the situation to reference the service:

Check…no pleasure.

After I examined the above, I received an error stating that the IAM Coverage for my function didn’t have the PutParameter permission. Effectively, it does…in order that error message was deceptive.

However I ended up mainly eradicating the useful resource restriction as follows quickly to see if this resolved the issue.

After doing that, I used to be again to the unique error above in our submit. It says that the useful resource coverage on the important thing doesn’t permit the Lambda function to encrypt utilizing the KMS key. That will be our Key Coverage. That is also a deceptive error message as a result of the permission for that motion exists, however now we have one other downside. I think it’s the situation within the coverage.

Over to CloudTrail. Let’s see what the error messages report.

The error message for the PutParameter name isn’t that useful:

Right here’s the error message we get from the try to Encrypt the SSM Parameter with the KMS key — that is the one which will get reported within the Lambda operate.

Concerning the situation…

I don’t see the “ViaService” attribute on this request so I assume that’s not an choice with AWS ParameterStore.

Check the coverage with out the situation to show our idea

First I eliminated the situation to make sure that was the issue. It was. My parameter deployed and once I tried to view the worth I received a KMS error as anticipated. My present consumer doesn’t have permissions to decrypt values created with that key. If I must view the important thing I would want to imagine the function that has permission to decrypt.

I restore the batch job coverage to its authentic type and examined my Lambda operate once more and it nonetheless labored.

Conditionally including a Coverage Situation in CloudFormation

So now my quandary is how am I going to take away that useful resource coverage situation? I attempted many variations and iterations to search out syntax that works and would permit me to conditionally. Wow. I couldn’t discover something wherever about how to do that so it was a trial and error course of. After many iterations I got here up with this:

Wanting it it after the very fact, it appears so apparent, however belief me it wasn’t.

  • I couldn’t use a CloudFormation Situation on the Coverage Situation as a result of the Coverage Situation doesn’t appear to actually be a part of the CloudFormation construction (I assume).
  • I couldn’t use the AWS::NoValue Pseudo Parameter as a result of as soon as I added the Situation: assertion I had to offer one thing to it.
  • The kms:ViaService attribute wasn’t in my key request, so I simply discovered one thing that was and used that.
  • Attempting to make use of two if statements — one for the second line and one for the third line didn’t work. I received the error: unhashable sort: ‘dict_node’
  • I couldn’t use mappings since as mentioned in an earlier submit we will’t use pseudo parameters in mappings.

Anyway that labored, the coverage up to date, and my Lambda Operate labored once more after that change.

Yet another change —don’t print out delicate values unnecessarily

Yet another change. Our Lambda code prints out the worth of the batch job ID. That was just for testing and is pointless so I eliminated it.

We’re nonetheless not achieved securing our Lambda operate or its interplay with AWS SSM Parameter retailer. Observe for extra.

Teri Radichel

In case you appreciated this story please clap and observe:

Medium: Teri Radichel or E-mail Record: 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 sequence:

____________________________________________

Creator:

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 Sources by Teri Radichel: Cybersecurity and Cloud safety courses, articles, white papers, displays, and podcasts



RELATED ARTICLES

LEAVE A REPLY

Please enter your comment!
Please enter your name here

- Advertisment -
Google search engine

Most Popular

Recent Comments