AWS IAM Policies & Roles

Policies are stored in AWS as JSON documents with several policy elements.

When creating a policy, it is required to have each of the following elements inside a policy statement.

Element	Description	Required	Example
Effect	Specifies whether the statement results in an allow or an explicit deny	✔	“Effect”: “Deny”
Action	Describes the specific actions that will be allowed or denied	✔	“Action”: “iam:CreateUser”
Resource	Specifies the object or objects that the statement covers	✔	“Resource”: “arn:aws:iam::account-ID-without-hyphens:user/Bob”

Let’s look at an example

• The Version element defines the version of the policy language. To use all the available policy features, include “Version”: “2012-10-17” before the “Statement” element in all your policies.

Putting all this information together, you have a policy that allows the IAM user to change their own IAM password (iam:ChangePassword) and get information about their own user (iam:GetUser). It only permits them to access their own credentials because the resource restricts access with the variable substitution ${aws:username}.

IAM Roles

Maintaining roles is easier than maintaining users. When you assume a role, IAM dynamically provides temporary credentials that expire after a defined period of time, between 15 minutes and 36 hours. Users on the other hand, whether using username and password or access keys, have long-term credentials. User access keys only expire when the admin rotates these keys. User login credentials only expire if you have applied a password policy that forces passwords rotation.

AWS services use Roles to get temporary credentials for APIs calls to other AWS services

Follow the Principle of Least Privilege:
Least privilege is a standard security principle that advises you to grant only the necessary permissions to do a particular job and nothing more. To implement least privilege for access control, start with the minimum set of permissions in an IAM policy and then grant additional permissions as necessary for a user, group, or role.

USING AN IDENTITY PROVIDER

You can use IAM roles to provide permissions to identities that are federated from your Identity Provider (IdP). For example, you have an employee, Max, that has access to multiple AWS accounts. Instead of creating and managing multiple IAM users named Max in each of those AWS accounts, you can manage Max in your company’s IdP. If Max moves within the company or leaves the company, Max can be updated in the IdP, rather than in every AWS account you have.

AWS IAM IDENTITY CENTER

If you have an organization that spans many employees and multiple AWS accounts, you may want your employees to sign in with a single credential.AWS IAM Identity Center is an IdP that lets your users sign in to a user portal with a single set of credentials. It then provides them access to all their assigned accounts and applications in one central location.AWS IAM Identity Center is similar to IAM, in that it offers a directory where you can create users, organize them in groups, and set permissions across those groups, and grant access to AWS resources. However, AWS IAM Identity Center has some advantages over IAM. For example, if you’re using a third-party IdP, you can sync your users and groups to AWS IAM Identity Center.This removes the burden of having to re-create users that already exist elsewhere, and it enables you to manage those users from your IdP. More importantly, AWS IAM Identity Center separates the duties between your IdP and AWS, ensuring that your cloud access management is not inside or dependent on your IdP.