Friday, October 28, 2022
HomeCyber SecurityAWS Altering ARNs in Belief Insurance policies — Massive Issues | by...

AWS Altering ARNs in Belief Insurance policies — Massive Issues | by Teri Radichel | Cloud Safety | Oct, 2022


ACM.94 Making an attempt to revive issues after a consumer will get deleted leaves you in a malformed state for which there isn’t any easy restoration

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

Whereas updating my code in prior posts, the KMSAdmin consumer bought inadvertently deleted so I couldn’t handle KMS keys by assuming the related KMS function. The consumer was faraway from the KMS Admin group. The Developer consumer was additionally faraway from the AppDeployment group which hindered deployments by that function.

I attempted re-running the CloudFormation templates that add the customers to the teams. For the reason that template hadn’t modified re-running it has no impact. CloudFormation solely deploys templates that modified, not issues which are out of sync with what must be deployed.

In case you have been following alongside you realize that I added an output to pressure updating each time a KMS key will get deployed to resolve this downside when AWS magically mangles ARNs in key insurance policies. I attempted that method once more for this downside.

Since I would like a timestamp twice now I created a shared perform for it (the precept of abstraction I’ve been telling you about repeatedly — don’t repeat your self or the DRY precept):

I added the timestamp to my add_user_to_group perform:

Sadly, that didn’t work for this state of affairs. I’m nonetheless getting an error that the KMS Admin can’t assume the group function.

Head over the belief coverage. Aha. AWS does the identical factor in belief insurance policies that they do in KMS key insurance policies, and it’s not updating for a similar causes. The deleted consumer ARN was apparently changed with some type of logical ID and the coverage is now not appropriate, nor does something associated to it work anymore.

Over to the function so as to add the timestamp to pressure an replace identical as above. Good factor I made get_timestamp a typical perform. 🙂

OK issues are getting bizarre. My function is unquestionably re-deploying with the pressure replace. I can see the brand new parameter and output within the template in CloudFormation. I can see the proper KMS Admin consumer handed in as a parameter. The stack exhibits up to date. No errors within the deploy script.

And but…..the belief coverage has not up to date. It is a downside.

If I attempt to delete the function in CloudFormation that can fail as a result of all the important thing insurance policies reference it. And plenty of issues reference all of the keys.

UGGGHHH.

So now I might manually replace the belief coverage, however that will probably be unhealthy. And it’s at this level that I notice that is going to be a single weblog submit as a result of that is very, very problematic.

I actually don’t assume Amazon must be altering buyer insurance policies. 

So what can we do about this…I can attempt to pressure the belief coverage another means because the pressure replace parameter will not be working. I can briefly add one other consumer to the belief coverage after which take away them once more perhaps.

What if I rename the group?

Effectively perhaps the group alone doesn’t replace the belief coverage…

What if I alter permit to disclaim?

Fortunately, my IAM function is in a separate deploy script in any other case I’d lock out my IAM admin if I had delete that consumer and group addition as nicely. I might additionally pull out the KMS admin right into a separate script since I don’t need this alteration to use to each different belief coverage whereas making an attempt to pressure this replace. That appears safer. Let’s do this.

take a look at.sh:

Effectively, one thing occurred however not what we wished. The up to date failed. Right here’s an error:

Right here’s why:

Let’s change it again to Enable and attempt to determine one thing else out.

And now we now have an enormous mess:

That is the type of nightmare you may get into with CloudFormation and the truth that AWS is altering these insurance policies unbeknownst to the client is a large downside in my view. This doesn’t appear to be the proper resolution to no matter downside it was supposed to resolve. Please cease doing this. #awswishlist

Fortunately I’m simply in a POC atmosphere and I can actually delete every little thing and begin over. I ought to most likely write a script for that…

Subsequent submit.

Teri Radichel

In case you favored this story please clap and comply with:

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

© 2nd Sight Lab 2022

All of the posts on this sequence:

____________________________________________

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 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