Questioning why CloudFormation doesn’t use the identical coverage validation logic because the AWS Console
This one actually bites. I used to be spinning my wheels on it for some time. I deployed coverage for a job that permits it to solely act on sure CloudFormation stacks. The coverage deployed with out error in CloudFormation.
Then, whereas attempting to run actions on the CloudFormation stacks with my function, I stored getting errors that I didn’t have permissions to run DescribeStacks on a specific stack. I used to be staring on the coverage again and again and reviewing a stack ARN character for character to verify I didn’t have an error within the ARN for the CloudFormation stacks and it seemed OK.
I reviewed the coverage within the console and in my code and it was driving me a bit nuts.
Lastly, I assumed only for a check I’ll manually make some change to the coverage to see if it really works. After I went to edit the Coverage within the AWS Console, the IAM coverage editor instantly instructed me that I had an error.
I had spelled CloudForamtion incorrect! I wrote this:
clouddformation
As an alternative of this:
cloudformation
OK so certain, I would like glasses. It’s true. Nonetheless, evidently if the AWS Console can spot the error, then most likely CloudFormation can too. Don’t completely different teams at AWS share validation routines through an API name to the “proprietor” of the useful resource?
I’d count on that the CloudFormation workforce might make an API name to the IAM workforce for coverage validation and the outcomes can be the identical in both case.
Shouldn’t that simply be a rule at AWS because the proprietor of the useful resource ought to know greatest methods to validate it? And different groups can suggest adjustments the validation guidelines through a fork as an alternative of rolling their very own?
An excessive amount of wasted time on all these little bugs!
Teri Radichel
When you appreciated this story please clap and comply with:
Medium: Teri Radichel or E mail Record: Teri Radichel
Twitter: @teriradichel or @2ndSightLab
Requests providers through LinkedIn: Teri Radichel or IANS Analysis
© 2nd Sight Lab 2022
____________________________________________
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 check 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, shows, and podcasts