ACM.342 Assume a role that requires MFA and pass short-term credentials to a container for use
Part of my series on Automation of cybersecurity measures. Batch job security. I AM. Container security. Deploy a static website. THE Coded.
Free content on Cybersecurity Jobs | Register at Broadcast list
In the last article, I stopped to look at my costs after adding a private network to my AWS environment. Unfortunately, the cost of security does not currently scale with small business usage.
In the previous post, I kind of had to regroup my thoughts after trying AWS Batch and Lambda to solve a particular problem. Lambda didn’t work and AWS Batch was overkill. I’m considering a not completely fleshed out approach.
I’m picking up where I left off. One of the first concepts was to run a container that could assume a role. The first step was to pass the credentials into the container as parameters. This is opposed to creating a credentials file and storing it in a Docker container for the container to use.
Risks, advantages and disadvantages
I don’t like storing credentials in a container. This was a short-term approach with short-term benchmarks to test something that ultimately didn’t work.
There are pros and cons to passing credentials into the container at runtime. I don’t recommend this approach in all cases. Here’s why:
- The credentials may appear in the logs where you run the container. Where is the history of the command line that runs the container?
- You have to manually manage credentials when testing the container (whatever these credentials can do, the person using them can do) and any attacker stealing them.
- Containers running…