AWS SAS – Securing your Root account via IAM, User Setup within IAM, and creating / using the AWS CLI Feature!

Upon jumping into AWS I completely overlooked created non-Root user accounts!

This “IAM” service is one of the first things you should configure within your AWS Cloud to create non-Root level users, even if its just for yourself, so if you do fall victim to certain Injection attacks I’ve described in DevNet Week 4 “Security” topics, they won’t be able to setup an Enterprise Data Center in AWS while you are AFK with a web session that has been hi-jacked by a bad actor.

To be clear – Even with all the security bells and whistles on like MFA / Strong Password Policies / Etc, if you get your web session hi-jacked that is already logged into a Root User account, a malicious person could setup their own admin account!

For this reason it is critical to give yourself an account with TONS of access, but not the ability to change your Root account details, so you should be logged into it as little as possible (only to adjust permissions / view bills / Root levels tasks)!

One of the most important things, which oddly added after user setup, is MFA!

This provides several options for Authenticator apps such as Microsoft Authenticator, Google Authenticator, DUO Authenticator – So there are many options for IT Engineers who already have one Authenticator for all their accounts this probably supports it.

To get there you must Click ‘Users’ on the left side-bar, click on the user-name you want to edit, then click on the “Security Credentials” under “Assigned MFA Device” shown:

I wanted to show this right up front as MFA is a critical front-door security feature for all accounts even with read-only access, depending on what they are able to read!

Before creating the user, you will need to create Groups that contain Policies!

I have learned this is a constantly moving target when setting up a user that fits your needs while having minimal access to turn on bells and whistles that you don’t need.

When setting up a Group Policies, you will NOT be able to see Policy details on this page:

Some things to note here:

A Group can only contain a maximum of 10 Policies
You can search using the service name / filters to find the proper Policy
There is only a brief description of the Policy with no way to drill into details
Users can belong to several or no Groups, so this will remain a moving target

To find detailed descriptions of these Policies to make more refined Groups:

I have only used the “Policies” page to review the detailed description for usage in groups, however you can create Policies here that can allow certain AWS Services to Invoke others, though Policies are actually Dynamically created when you are creating one service that Invokes another such as when I created an API Gateway that utilized Lambda as its public facing entry into my AWS Service / API Gateway.

This Dynamically makes “Roles” shown below that you can verify are correct:

These have all been created Dynamically through working with support, and some functions I have played with since opening my AWS account, so this is good to audit manually from time to time to ensure you don’t forget a service is running when you are testing functionality or just playing with services to ensure they don’t keep running!

One last consideration when creating users – Account Settings “Password Policy”

This will change how automatic passwords are generated, as they will be based off the criteria of this policy, which mine is not the strongest on Earth but it works for me:

Its in kind of an odd spot in my mind, I’d think this would be its own category, however here it be – This both drives the automatically generated initial login passwords along with the password allowed to be changed by the user upon login so lock this down!

Back to creating a non-Root user, you start with simply “Add User” to get here

You will click on “Users” in the left side-bar then “Add User” as shown here:

From here it will guide you through the process

Note you can add multiple users at once if you need to add a group of Developers with equal access, and you can restrict access purely to API / CLI / SDK which is great for programmers that don’t need a GUI to work with, also note the “Autogenerated” and “Required Reset” passwords will use your Password Strength settings.

During this process you can create a Group on the fly, but it is better to be mindful and create groups based on reviewing the detailed descriptions of Policies:

The next page “Tags” is optional and I might use it to define a user with values like name / email or name / job role on a Team, and once completed you will get a success screen:

You will be presented with a unique AWS sign-in for non-Root users that they will need, along with a Key Pair used for Authentication via CLI access which I will demo now, as I didn’t intend that to turn into a full blown user setup guide but its important to use an account that has ONLY the access you need and log in with Root only to grant permissions as needed to Groups or individual users!

The URL for downloading the CLI client and demo setup in Windows

To download the client for different Operating Systems use the following link:

https://docs.aws.amazon.com/cli/latest/userguide/install-cliv2.html

This will lead to the documentation / download links for Amazon CLI that allows you to run on most Operating Systems, I decided to test it on my Windows 10 machine first, and below is the setup of the “testuser” then demonstrating logging in with my cli-user:

The “aws configure –profile testuser” was used here to allow me to setup that user without my saved keys being used be default, I first use the shorter Access Key then I use the Secret Key which should never be shared as this will be unique to the user.

Notice that the session is kicked off each time using “aws configure” and it connects right to your environment, as long as there are resource that you have access to via the CLI, whereas my test user is not assigned to any resources so it won’t remember the input (because it doesn’t need to until it has resources to access) so when I type “aws configure” it defaulted directly to my “cli-loopedback” user with the keys / region / output format already input for me (which I will be changing after this demo for security sake).

I gave myself to an S3 Container that is empty, but ran “aws s3 ls” just to demo that it shows my loopedbackbucket S3 Bucket Name, but there is nothing in it to list.

And that concludes the need to secure a non-Root acct immediately and CLI use!

While I was going through it myself and had some free time I wanted to post this first glimpse of how to secure your “Free Account” by using IAM, or some malicious code embedded in a webpage might make your account not so free if using Root account!

Also I’d learn to use the CLI as well, like with GIT and Visual Studio Code, there is no better way to really fully understand how things work when you do them both in a raw shell command line way along with the more convenient GUI point and click way.

Now to get rid of that testuser and change out my cli-user keys, until next time! 🙂