When you start working with AWS one of the easiest ways to interact with the APIs is through the IAM User. Although it's not the advised way it's the easiest way hence the most used one and the most abused one. In this blog I will dive a little deeper into this topic.
Easy to use
Using an IAM User is the oldest way to interact with the AWS API. You only need an AccessKey and a SecretAccessKey and you are good to go! When you have the AWS CLI installed you only need to execute the
aws configure command. This will as for some inputs via prompts:
$ aws configure AWS Access Key ID [None]: AKIAIOSFODNN7EXAMPLE AWS Secret Access Key [None]: wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY Default region name [eu-west-1]: eu-west-1 Default output format [yaml]: yaml
This will result in the following
[default] aws_access_key_id = AKIAIOSFODNN7EXAMPLE aws_secret_access_key = wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
And you are good to go! You can now perform any aws cli command. Assuming the IAM User has the correct policies in place to perform the needed actions. Having these credentials in place makes your life easy. For example: the Boto3 SDK will use your credentials. Super convenient, super dangerous!
When you are developing you often run your code to test if it works. Now I would love to think that everybody uses Test Driven Development but I know this is not true. This could have many reasons, experience is the most obvious one. When you start your development journey there are already a lot of things that you need to learn. Writing unit tests is not the highest priority for someone who wants to learn how to write code. That being said, yes it will slow you down. But only in the beginning! When you master proper testing you will increase your productivity tenfold!
So why are these credentials dangerous again? Assume you are writing some code to clean-up objects from a S3 bucket. If you have a bug in your code, and you run your script it will be using the default credentials as a default. Resulting in potential data loss in your AWS Account! And this is of course one of the examples that can go wrong. Even when you do use test driven development, and you forget to stub one of the API calls. Boto3 will use the default credentials and execute the API call.
Avoid using a default profile
So, should you not use the IAM User credentials then? Well there are "better" alternatives, like Single Sign On. When you configure those credentials as your default credentials, you will face the same problem! So avoid the default profile! Either don't configure it or use mock credentials like I used in the example. They will result in an access denied but that is better than losing data. Next to that you should use the principle of the least privileged. Because when your principal does not have the access rights, it cannot perform them!
Make sure you use the least privileged principle. And avoid sticking your credentials in the default profile.
Photo by Min An