IAM stands for “identity and access management,” and it’s the primary gatekeeper to any AWS account. IAM provides authentication and authorization for users and service accounts. It serves as a basis for governance of your account and protects it against unauthorized access.
Throughout this course, we will frequently refer to MFA, or multi-factor authentication. It is a common authentication method that relies on an additional factor beyond a username and password. It is popular across online services that require a user account, and it provides a significant boost to security. AWS has extensive documentation on the MFA methods it supports, and you can choose between passkeys or TOTP-based apps such as Authy, Duo, or Google Authenticator. It is generally recommended not to use SMS for MFA because it is easy to spoof, and AWS stopped supporting it as an MFA method many years ago.
At the core of the IAM framework is the root user for the account. AWS root users correspond to UNIX root users: they can do anything and everything. There’s little guardrails while using the root account and huge potential for leaks, accidental resource creation or destruction, etc. For this reason, root users should never be used for anything other than setting up other users. In fact, it’s considered best practice to never log in as root after the initial setup.
<aside> ⚠️
This cannot be overstated: nobody should use root accounts on AWS except for initial account setup or emergencies. In addition, root users should have MFA enabled and no active access keys.
</aside>
https://www.youtube.com/watch?v=ubrE4xq9_9c
IAM users are very similar to UNIX users. Each needs to have a unique username and a password, and there are different options if you want to have users that only get limited access (for example, to the API only), managed by AWS Identity Center (a new AWS user management service), and whether they should change their password after first login (strongly recommended).
Users can be organized into groups, which can have different IAM policies (sets of permissions) attached to them. It’s an easy way to control access, and another nod to the UNIX-style of user management. While creating new users, you’re offered a choice to either create a new group, add to existing group, copy permissions from an existing user or attach IAM policies manually. IAM offers a lot of policies that are built-in and have pretty self-explanatory names, but you can also create them manually. We will cover more about policies in the next section.
<aside> ⚠️
We mentioned before that not every AWS resource or service is bound to a region. IAM resources are one such examples: IAM users, groups, roles and policies are global.
</aside>
Apart from accessing AWS via the management console, the most useful way to interact with AWS resources is via its APIs, and then a non-interactive way of authentication is better. That’s called an access key in AWS.
Access keys are long-lived credentials for programmatic access to AWS: an access key ID and secret access key that applications, scripts, or the AWS CLI use to sign API requests. Use them only when you truly need direct API access as an IAM user, such as for local development with the AWS CLI or for legacy tools that cannot assume an IAM role.
AWS access keys come in a pair of key ID, and secret ID. They have the following shape (just an example):
AKIAIOSFODNN7EXAMPLE
wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
If you must use access keys, treat them like passwords, store them in a secrets manager, and rotate them regularly: create a second key for the same IAM user, update your app or CLI to use the new key, verify everything works, and then deactivate and delete the old key. You can enforce rotation by setting a password policy and access key age limits in IAM and by using AWS Config rules or Security Hub controls to alert when keys are older than your allowed maximum age.
Access keys should only be used for direct programmatic interaction with AWS APIs, usually from your computer using the CLI. Long-running services should use IAM roles instead, which we will cover in the next section.
Security is inconvenience.
It’s in our nature to use computing services in ways that are convenient for us, so what happens a lot is that AWS users either use their root accounts (oof) or users with very broad, admin-like privileges.
It’s best practice with AWS IAM, or in fact any computing system, to use the principle of least privilege, namely to only grant permissions which are strictly necessary for a given user, group or service to operate correctly. Assigning more privileges than necessary is a disaster waiting to happen, and should be avoided at all cost.
Let’s practice what we’ve learned.
The HackYourFuture curriculum is licensed under CC BY-NC-SA 4.0 *https://hackyourfuture.net/*
Built with ❤️ by the HackYourFuture community · Thank you, contributors
Found a mistake or have a suggestion? Let us know in the feedback form.