Using the cloud is good, securing access is better, or how two strings in the wild can cost you tens of thousands of euros.
The Risks of Poor AWS Security
One of the security issues one might encounter with AWS is the management of Access Keys. These are pairs of keys used to access AWS functionalities with command line tools. For example, they allow you to start virtual machines from the console using command line instructions. They also underpin Infrastructure as Code (IaC) tools, and therefore, they are very prevalent and must be secured.
If used by malicious actors, they can enable the creation of resources in AWS (for instance, launching hundreds of machines to mine cryptocurrencies, creating repositories to exchange dubious files, etc.), potentially costing you a fortune and a trip to the police station.
There is much to discuss regarding how to manage and secure AWS accounts (limiting user rights, using temporary roles, completely separating accounts...), but we will focus here on key management and assume that everything else is already in place. And if it’s not, do it now instead of reading this article.
Amazon Web Services Best Practices
First and foremost, and this is basic, these keys should never be visible in plain text in the source code of projects. They should not appear in application logs either and should not be accessible in plain text when used online for CI/CD services. This is really basic and a serious professional mistake, in my opinion. There are secure methods for your applications to use these keys without exposing them, but that is not the subject of THIS article.
It is also important to avoid sharing them within a team (each person should have their own key), and if you insist on making this mistake, then encrypt them for exchange. Finally, consider rotating these keys. Sometimes I see keys that are five years old still active and somewhat risky.
Generally, once the keys are obtained, they should be entered into the configuration files of the AWS CLI, and they should not move until they are replaced.
But even there, it’s problematic. Even though I know you have all secured your machine, that you never leave a session open in your absence, etc... They are there, in plain text, in a directory. If someone retrieves this file, then they retrieve the AWS account.
And that has always seemed problematic to me.
Fortunately, not long ago, I was introduced to AWS Vault.
AWS Vault
AWS Vault is an open-source tool that allows you to locally and securely store these Access Keys. They are no longer in plain text on the machine and their use via the AWS CLI requires entering a password at the beginning of each session. Of course, you keep this password in a password manager. In principle, AWS Vault will store your keys in your OS’s native secret management tool (for example, macOS Keychain) and then, when you want to access the AWS account they belong to, use them to generate temporary access keys (a ++ feature of AWS) which will be injected into a sub-session from which you will execute your AWS CLI commands.
It’s simple, it’s clean, we like it.
Other Features of AWS Vault:
- Support for multiple AWS accounts
- Key rotation management (wow effect on me)
- MFA support
- Available on macOS, Windows, Linux.
If you use AWS and have control over your project's task backlog, I strongly suggest you discreetly add the task of securing your team's cloud access.