Take a look at Automation for Deployments. ACM.26 Ensuring code modifications don’t… | by Teri Radichel | Cloud Safety | Aug, 2022

August 11, 2022

1

ACM.26 Ensuring code modifications don’t break one thing else

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

This publish goes to be quick and candy. If you happen to comply with on Twitter you might need observed that I lastly bought covid and it hasn’t precisely been “no signs”. Hopefully, I'm on the mend. The bugs in my code must wait.

In my final publish I defined how and why I centralized the IAM scripts to a central location. Nonetheless, I left the insurance policies for particular batch jobs in their very own folders. The concept is that the IAM workforce can deal with the core performance and the batch-job particular insurance policies could also be dealt with by others. Even when they don’t seem to be, I anticipate the core performance would require few modifications sooner or later, equivalent to who can assume the roles, versus a brand new coverage doc we have to create for every new batch job in accordance with zero-trust safety insurance policies.

Despite the fact that I don’t have a whole lot of code but, these modifications had been in depth sufficient that I used to be frightened about introducing an error. Any time you modify a chunk of code there’s an opportunity of error. So I wished to check all of it out. After I did that I noticed that it was getting a bit tough to recollect which roles go the place. I might be higher off documenting this now, and one of the simplest ways to doc it’s by way of some take a look at scripts.

I added a take a look at.sh file in all of the pertinent folders after which name all these take a look at scripts from the foundation folder. That method I can take a look at unbiased folders or all of the code directly.

For instance should you have a look at the up to date codebase in GitHub now you’ll see the next:

There’s a take a look at.sh file contained in the iam folder.
Contained in the iam folder I’ve folders for every of the iam identities I’ve created to this point (customers or roles.)
If you happen to’ve been following alongside you’ll discover that I constantly put a deploy.sh file in every folder the place I deploy one thing so every of the iam folders has a deploy.sh file in it.

So my take a look at.sh script is fairly easy:

The one distinction you would possibly discover is that for one of many scripts the place I’ve to go in an ARN I look that up from the outputs of the template. If and once I transfer issues into separate accounts I’ll want to consider how I’m going to to deploy that, however for now it permits me to check the code and helps me keep in mind who is meant to be allowed to do what and what arguments I have to go to which scripts.

In my root folder I take a look at all of the scripts within the subfolders utilizing one other take a look at.sh file.

Now each time I re-run my code I can validate that I haven’t damaged one thing else within the course of.

Be aware: The take a look at automation code on this publish makes use of to AWS CLI profiles for the IAM and KMS person and function that require MFA. I’ll clarify how to try this in an upcoming publish as some of what’s on this repo I haven’t written about but. I even have one failing take a look at in the mean time I’ll repair earlier than I publish the associated publish. I haven’t written about that code but.

Take a look at your deployments

It is extremely necessary to check not solely the performance of purposes but additionally deployment code.

Take a look at in a separate setting

Though I’m testing in my very own account hopefully I’ve used applicable parameters so this runs in any account. I’ll take a look at that later. If you end up deploying code to a different setting later, equivalent to a manufacturing setting vs. a dev setting, you wish to take a look at your deployment code first in another setting to ensure the deployment works. Ideally you’ve gotten a separate staging setting that mirrors manufacturing however at a minimal take a look at your deployment in a QA setting.

Take a look at Automation

It will be very tedious for me to enter each file and take a look at it individually to ensure my modifications haven’t damaged the code. Take a look at automation helps you verify each time you make a change that you simply haven’t damaged one thing else.

That is quite simple code. We had way more sophisticated code when writing saved procedures for banking programs with advanced parameters and logic. Every time attainable I attempt to break issues up into smaller elements which might be simpler to check when you possibly can. Too typically these advanced unit checks could be ignored or turned off for the sake of getting tasks out the door. Nonetheless, typically it’s not attainable to make issues less complicated.

Testing person interfaces that change rather a lot can be sophisticated. Every time the code modifications, the take a look at must be up to date. Because of this it’d finest to do your take a look at automation on a person interface after it’s considerably secure.

Take a look at automation just isn’t simple and I’m not a stickler like another those who say you should have a unit take a look at for each single code change, however each time you possibly can, take a look at automation will aid you stop errors by shortly validating {that a} code change hasn’t damaged one thing.

Code on Github:

Comply with for updates.

Teri Radichel

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

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