API keys = API Key + API Secret Key
Never enter your IAM API keys into your EC2 instance. Unless you are the single user in that EC2 instance. If not, it’s like not doing yourself a favor, on the contrary.
Some words briefly about the definition of what is an EC2 instance: EC2 instance on AWS it’s a virtual machine or server. But the term “server” it’s not to be understood always as a computer on a rack of servers (typical definition when IT is on premises). A server could be also a piece of software. Many are confused about this term, so I wanted to briefly clarify.
Coming back to the main topic of this article, I was a little surprised to see that Amazon sometimes invites users to do strange things, like this one below:
Basically, they are inviting you to enter your API credentials (API Key and API Secret Key) into an EC2 instance, after AWS said it is “unable to locate credentials”. At the first sight asking this might seem logic.
Think twice. Aaaa …. no way!
Do not enter your AWS credentials using “aws configure” command because when you enter your personal details in an EC2 instance anyone else in your account could connect to that EC2 instance (either connecting using ssh or – for example – using EC2 Instance connect) and that person could retrieve the value of your credentials stored in that EC2 instance.
This is not what you want. Don’t fall that trap.
Instead, use roles (I mean IAM roles).
It seems Amazon woke up one day and realised that security bad practice and issued in its documentation a section named “Best practices for managing AWS access keys” (see the below text). So, you might want to take notice of this section (at the end of the below text there is the link to the source).
Use IAM roles instead of long-term access keys
In many scenarios, you don’t need long-term access keys that never expire (as you have with an IAM user). Instead, you can create IAM roles and generate temporary security credentials. Temporary security credentials consist of an access key ID and a secret access key, but they also include a security token that indicates when the credentials expire.
Long-term access keys, such as those associated with IAM users and AWS account root users, remain valid until you manually revoke them. However, temporary security credentials obtained through IAM roles and other features of the AWS Security Token Service expire after a short period of time. Use temporary security credentials to help reduce your risk in case credentials are accidentally exposed.
Use an IAM role and temporary security credentials in these scenarios:
You have an application or AWS CLI scripts running on an Amazon EC2 instance. Do not use access keys directly in your application. Don’t pass access keys to the application, embed them in the application, or let the application read access keys from any source. Instead, define an IAM role that has appropriate permissions for your application and launch the Amazon EC2 instance with roles for EC2.
Source: https://docs.aws.amazon.com/general/latest/gr/aws-access-keys-best-practices.html.
Others unnecessay complicate things (unless the risk is so high that you really need to complicate it as much): https://medium.com/poka-techblog/the-best-way-to-store-secrets-in-your-app-is-not-to-store-secrets-in-your-app-308a6807d3ed
As a conclusion, it seems simple and tempting to configure credentials in AWS CLI (Command Line Interface) especially when you want to get the job done quickly. But you might not want to do that. Don’t shoot yourself in the foot.
IT Consulting 