IAM

• IAM is universal service and it does not apply to a single region; it is cross-region
• The root account is the account created for the first time and it has full access (also called as God mode 🧚 )
• New users have no permissions when created
• Access key id and secret access key are required for programmatic access to AWS. They can’t be used to login to the console.
• Use MFA in the root account. We can use the Google Auth app for this 📱
• IAM is concerned with the raw AWS resources, not access to running web applications.

Tip

Setting up a cross-account IAM role is currently the only method that will allow IAM users to access cross-account S3 buckets both programmatically and via the AWS console.

IAM Root User 🌴

When you first create an Amazon Web Services (AWS) account, you begin with a single sign-in identity that has complete access to all AWS services and resources in the account.

This identity is called the AWS account root user and is accessed by signing in with the email address and password that you used to create the account.

How to secure AWS Root Account

You can do the following:

Implement MFA

Delete the Access Keys ❌

IAM User 👨‍🦱

An IAM user is an identity that you create in AWS. It represents the person or application that interacts with AWS services and resources. It consists of a name and credentials.

By default, when you create a new IAM user in AWS, it has no permissions associated with it. To allow the IAM user to perform specific actions in AWS, such as launching an Amazon EC2 instance or creating an Amazon S3 bucket, you must grant the IAM user the necessary permissions.

IAM Policy 🧑‍💼

An IAM policy is a document that allows or denies permissions to AWS services and resources.

Policy Types

There are four types of policies in IAM:-

• Identity-based
• Resource-based
• Organization SCPs
• Permission boundaries

You can provide console access and programmatic access via IAM. Programmatic access includes API and CLI access.

Remember

• IAM is not the managed service for handling MFA Delete setup on S3 buckets
• Users, groups, roles, permissions, and similar constructs are part of IAM
• Organizations and organizational units are part of AWS Organizations, a different facility.
• User policies are not part of IAM but permissions are.
• IAM policies are written in JSON.
• IAM policies can be attached to users, groups, and roles in the case of identity-based policies, and AWS services and components via resource-based policies.
• Restoring revoked permissions for a user and changing the support options need the root user access.
• IAM changes apply immediately to all users across the system; there is no lag, and no need to log out and back in.
• Power-user access is a predefined policy that allows access to all AWS services with the exception of group or user management within IAM

Warning

• AWS strongly recommends you delete your root user access keys and create IAM users for everyday use.
• IAM root user account is needed for very privileged access; in this case, that’s creating a CloudFront key pair, which essentially provides signed access to applications and is a very trusted action.
• AWS firmly believes that root account access should be highly limited, but also not confined to a single user. Having a very small group of engineers (ideally AWS certified) is the best approach to reducing root account level access as much as possible.

• You will always need to provide non-root sign-in URLs for new users.
• New users have no access to AWS services. They are “bare” or “empty” or “naked” users, as they can merely login to the AWS console (if a URL is provided). They cannot make any changes to AWS services or even view services.
• AWS usernames have to be unique across the AWS account in which that user exists 🔑
• If you have an external Active Directory, you’d want to federate those users into AWS. This allows you to use the existing user base, not re-create each individual user.

Identity-based 🆔

Resource-based ⛺️

Organization SCPs 🏢

SCP's are used by AWS organizations and attached to AWS accounts or organizational units, OUs, to define the maximum permissions allowed for the members of the associated account or OU. So in a way they act in a similar fashion to that of permission boundaries, but at the account level and affect all members of those accounts.

Example

let's say a user within an AWS account had full access to S3, RDS and EC2 via an identity-based policy. If the SCP associated with that AWS account denied access to the S3 service, then that user would only be able to access RDS and EC2 despite having full access to S3. The SCP would serve to prevent service from being used within the AWS account and so have the overriding precedence and determine the maximum level of permissions allowed.

So to be clear, an SCP does not grant access, they add a guide route to define what is allowed. You'll still need to configure your identity-based or resource-based policies to identities, granting permission to carry out actions within your accounts. If you want to use service control policies to help you manage your security at an account level, then you need to ensure that you deploy AWS organizations using the enable all feature setting.

Within IAM, you have the ability to view any SCPs that are applicable to your AWS account, the policy statement itself, it's ARN, the number of entities it affects and you can also review access activity to learn when a principal within the organization last accessed a service. However, if you wanted to update or edit the SCP, then you'd have to do that from within the AWS organization service itself. The SCP can't be edited from within IAM.

Permission boundaries 🧱

These policies can be associated with a role or user, but they don't actually grant permissions themselves, instead they define the maximum level of permissions that can be granted to an entity. Organization service control policies, SCPs. These are very similar to permission boundaries in the fact that they do not grant permissions.

They define a boundary of maximum permissions. However, these service control policies are associated with an AWS account or organizational unit, an OU, when working with AWS organizations and govern the maximum permissions to the members of those accounts.

IAM Group 👨‍👩‍👦‍👦

An IAM group is a collection of IAM users. When you assign an IAM policy to a group, all users in the group are granted permissions specified by the policy.

IAM Role 🎫

An IAM role is an identity that you can assume to gain temporary access to permissions.

Best Practice

IAM roles are ideal for situations in which access to services or resources needs to be granted temporarily, instead of long-term.

On-Behalf of Role 🧢

Many AWS services require that you use roles to allow the service to access resources in other services on your behalf. A role that a service assumes to perform actions on your behalf is called a service role.

When a role serves a specialized purpose for a service, it is categorized as a service role for EC2 instances (for example), or a service-linked role.

Identity Federation 🪪

IDP: The user credentials and other identifying information are stored and managed by an Identity Provider (IdP) centralized system. IdP is a trusted system that provides access to other websites and applications.

SP: In the context of SSO, a service provider is responsible for providing services to the end user. However, service providers do not authenticate users themselves. Instead, they rely on an identity provider (IdP) to verify the user’s identity and manage specific attributes related to the user. Put simply, service providers request authentication decisions from the IdP, which holds the account information and unique attributes related to the user for the given service.

Web identity federation and SAML difference?

Whereas web identity federation is generally used for large, wide scale of access from unknown users, SAML 2.0 is generally used to authenticate your employees using existing directory services that you might already be using.

SAML, which stands for Security Assertion Markup Language, is a standard that's used to exchange authentication and authorization identities between different security domains, which uses security tokens containing assertions to pass information about a user between a SAML Identity Provider and a SAML consumer.

Federated access example

---

Was this page helpful?

Yes No