ACM.342 Assuming a role that requires MFA and passing short term credentials to a container to use them
Part of my series on Automating Cybersecurity Metrics. Batch Job Security. IAM. Container Security. Deploying a Static Website. The Code.
Free Content on Jobs in Cybersecurity | Sign up for the Email List
In the last post I paused to look at my costs after adding private networking to my AWS environment. The cost of security does not scale according to small business usage at this time, unfortunately.
In the post before that, I kind of had to regroup my thoughts after trying out AWS Batch and Lambda to solve a particular problem. Lambda didn’t work and AWS Batch was overkill. I’m thinking through a not fully fleshed out approach.
I’m picking up where I left off there. One of the first concepts was running a container that can assume a role. The first step was to pass the credentials into the container as parameters. That is opposed to creating a credentials file and storing it in a Docker container for the container to use.
Risks, pros, and cons
I don’t like storing credentials in a container. That was a short term approach with short-lived credentials to test out something that ultimately didn’t work.
There are pros and cons to passing credentials into the container at run time. I don’t recommend that approach in all cases. Here’s why:
- The credentials may appear in logs where you are running the container. Where is the command line history that runs the container?
- You’re having to manually deal with credentials while testing the container — anything those credentials can do the person using them can do — and any attacker who steals them.
- Running containers…
#Passing #AWS #Credentials #Container #Teri #Radichel #Cloud #Security #Oct