How to Set Up AWS IAM: Elements, Features, & Components

Amazon Web Services (AWS) offers IT infrastructure services (IaaS-Infrastructure as a Service) to businesses in the form of web services commonly known as cloud computing. AWS provides a highly reliable, scalable, low-cost infrastructure platform in the cloud that powers hundreds of thousands of businesses. AWS IAM is a web service that helps you securely control access to Amazon resources.

To understand how to set up IAM in AWS one needs to understand what AWS IAM offers as a service and how this can be mapped to different levels and implemented. The access to the AWS services must be secure so the users need to be authenticated. After signing in, depending on the user’s authorization level in the organization a user is allowed to access the resources.

• What is IAM in AWS
• Set Identities 
• Set Authentication
• Set Authorization
• Allowed Access
• Monitoring of Resources

What is IAM in AWS?

IAM is one of the most important services of AWS and has two primary roles:

1.  Identity – authenticate users and groups
2. Access Management – authorize users and groups to AWS services

IAM manages access in AWS by creating policies and attaching them to IAM identities (users/ groups/roles/application) to access IAM resources. A policy is an object in AWS that, when associated with an identity or resource, defines its permissions. AWS evaluates these policies when an IAM identity (user/group or role or application) makes a request for action, operation, or resources. Permissions in the policies determine whether the request is allowed or denied.

1. Identity in AWS

We are going to now look into how we go about setting up the identities (users /groups /roles /application), set the authentication mechanisms (IAM internal or external) then set their authorization depending on the role or permission to perform actions/operations or access resources.

What are Identities in AWS?

Identities in AWS are created in AWS through IAM. These can be users, groups, role, or applications. In an organization there can be one or more AWS accounts created. This is a policy decision and the administrator along with the architect decides on this for e.g., each department can be a different AWS Account and the users could be users within the AWS account.

Best Practices

The following are the best practices to be followed by the user accounts.

• All IAM user configured needs to be given the Sign-in URL for the account.
• Establish a principle of least privilege.
• Enable MFA: For extra security, it is advisable to enable multi-factor authentication (MFA) for all users. Change passwords or access keys at regular intervals.
• Do not use Root user account on a regular basis. Create an admin account and use this account to do administrative tasks.
• Root user account to be used only for billing and the account credentials username and password should have restricted access to saved securely.

How to Get to the Access Management Controls

AWS users or applications can access IAM through different methods.

• Management Console – This is a browser based Graphical User Interface to access different AWS services. To access user accounts through management console username and password along with the AWS Root login URL is required.
• Command Line Interface (CLI) Tools – AWS Command-line tools are used to perform IAM and AWS tasks. The tasks can be performed as commands on the CLI or PowerShell or alternatively as scripts that can be executed from the command line. This is a much quicker, powerful, and easier way of executing tasks.
• Software Development Kit (SDK) – AWS provides programmatic access to IAM from the different libraries provided in the software development kit.
• Application Programming Interface (API) –APIs can access IAM programmatically using IAM HTTPS API’s.

To access IAM through CLI / API, the user requires access keys. Access keys have two parts Access Key ID and Secret Access Key to authenticate requests. This must be enabled for the user in the IAM for them to access the account.

Root User

When you first create an Amazon account, you begin with a single sign-in identity that has complete access to all Amazon services and resources in the account. This identity is called the Amazon account root user and is accessed by signing in with the email address and password that you used to create the account.

The root user is the superuser in IAM and has all the privileges. The password for the root user must be stored very securely. It is advisable to have two-factor authentication for the root user account.

Multi Factor Authentication (MFA)

Multifactor authentication can be enabled for IAM.  This is a method to implement two-factor authentications for AWS users. This Authenticator could be Google authenticator or any other software-based authenticator application or a hardware device. This acts as another level of security and should be enabled for root user accounts.

The users can be part of IAM, or they can be part of another directory service that does the job of user authentication.

How to Configure IAM Users

AWS Identity and Access Management (IAM) user is an entity that you create in AWS to represent the person that uses it to interact with AWS. A user in AWS consists of a name and credentials.

1. Set Login Credentials

Each IAM user that is created will have a username and password. Administrators have the option to enable MFA for all users.

Password policy: The password can be auto generated, or you could enforce the default password policy for the account password policy.

• Minimum password length is 8 characters.
• Include a minimum of three of the following mix of character types: uppercase, lowercase, numbers, and ! @ # $ % ^ & * ( ) _ + – = [ ] { } | ‘

Require Password Reset

• User must create a new password at next sign-in
• Users automatically get the IAMUserChangePassword policy to allow them to change their own password.

2. Access Keys

Access keys are long-term credentials for an IAM user or the Amazon account root user. You can use access keys to sign programmatic requests to the Amazon CLI or Amazon API (directly or using the Amazon SDK).

• Access keys consist of two parts: an access key ID and a secret access key.
• Like a username and password, you must use both the access key ID and secret access key together to authenticate your requests.
• Manage your access keys as securely as you do your username and password.

3. Configure Groups

IAM groups are groups of users. Groups help in the administration of users. Normally users are members of multiple groups. Groups have certain permission or policy assigned to them. Administrator creates a user as he joins an organization. They would then add them to be a member of multiple groups and his permissions would be based on the groups he belongs to. Groups in AWS cannot be nested.

4. Configure Role

IAM roles can be assigned to any trusted entity. They can be users in the same or different account or an application or a service like EC2, Lambda. Roles make sure that a user or a service has a certain set of permissions, so it is used to delegate access without having to share the secret access key.

5. Configure Applications

Applications are allowed programmatic access into AWS. They use the access keys to get authenticated and access the AWS services.

2. Set Authentication

Authentication in AWS is done by internal or external service. The internal service is handled by IAM Identity Provider is typically for a small business and external identity provider is used by larger organization or large-scale implementations.

Internal Identity Provider

IAM is the internal identity provider service for AWS. This might be sufficient for an organization which is smaller in size in terms of employees or is not conducting business online.

External Identity Provider

However, if you have an existing identity provider you would like to use like directory service in the corporate environment or, you are using a web application which use a web identity you can use them. To use such an External Identity Provider, you create an IAM identity provider entity and establish a trust relationship between your AWS account and the Identity Provider IAM supports Identity Providers that are compatible with OpenID Connect (OIDC) or SAML 2.0 (Security Assertion Markup Language 2.0).

1. Web Identity Provider – IAM OIDC identity providers are entities in IAM that describe an external identity provider (IdP) service that supports OpenID Connect (OIDC) standard, such as Google or Salesforce. You use an IAM OIDC identity provider when you want to establish trust between an OIDC-compatible Identity Provider and your AWS account. This is useful when creating a mobile app or web application that requires access to AWS resources, but you do not want to create custom sign-in code or manage your own user identities.

You can create and manage an IAM OIDC identity provider using the AWS Management Console, the AWS Command Line Interface, the Tools for Windows PowerShell, or the IAM API.

2. Enterprise Identity Federation – IAM SAML 2.0 identity provider is an entity in IAM that describes an external identity provider (IdP) service that supports the SAML 2.0 standard. You use an IAM identity provider when you want to establish trust between a SAML-compatible IdP such as Active Directory Federation Services and AWS, so that users once signed on to your enterprise active directory can access AWS resources. IAM SAML identity providers are used as principals in an IAM trust policy.

3. Set Authorization

Authorization is set up in various levels in AWS and are called Policies. Policies can be overlapping. Managers, depending on their organization, need to decide to implement the policy in various levels for easier administration.

Service Control Policy (SCP)

AWS Organizations is an account management service that enables you to consolidate multiple AWS accounts into an organization that you create and centrally manage. As an administrator you can create multiple levels of Organization Units within the Organization to map it with your current setup.

AWS Organization and Organization Units helps you in account management. AWS Organizations also enable you to meet the security and compliance of your business by setting up guard rails.

These are called Service Control Policies (SCP). Service Control Policies are like IAM Permissions policies — it limits permissions to Organization Units e.g., departments or profit center. SCP limits permissions for entities in member accounts who are part of the Organization Unit. Only Service Control Policy can restrict permission to the root user account of an Organization Unit.

IAM Policy

IAM Policy is an identity policy assumed by the user, group, or role. It can be further categorized as:

A. Managed Policy

AWS Managed Policy: This is AWS Managed Policy and is built in AWS. You can add up to ten managed policies to user, group, or role.

Customer Policy – Customer Policy is defined by the customer, and it will be in your AWS Account. This policy is created in AWS, and it is assigned a set of permissions. You can attach a customer policy to multiple entities like user, group, or role.

B. Inline Policy

Inline Policy is embedded with an IAM identity like user, group, or role. This is used last when you have a one-to-one policy required for a specific identity. When you delete the identity as the policy is embedded with the identity the policy also gets deleted.

IAM permissions boundaries

A permissions boundary is an advanced feature in which you set the maximum permissions that an identity-based policy can grant to an IAM entity. When you set a permissions boundary for an entity, the entity can perform only the actions that are allowed by both its identity-based policies and its permissions boundaries.

Resource-based policies that specify the user or role as the principal are not limited by the permissions boundary. An explicit denial in any of these policies overrides the allow.

Resource-Based Policy

Resource-based policies are attached to a resource. For example, you can attach resource-based policies to Amazon S3 buckets, Amazon SQS queues, and AWS Key Management Service encryption keys.

With resource-based policies, you can specify who has access to the resource and what actions they can perform on it. To learn whether principals in accounts outside of your zone of trust (trusted organization or account) have access to assume your roles.

Access control lists (ACLs)

Access control lists (ACLs) are service policies that allow you to control which principals in another account can access a resource. ACLs cannot be used to control access for a principal within the same account. ACLs are like resource-based policies, although they are the only policy type that does not use the JSON policy document format.

Amazon S3, AWS WAF, and Amazon VPC are examples of services that support ACLs. To learn more about ACLs, see Access Control List (ACL) Overview in the Amazon Simple Storage Service Developer Guide.

Session policies

Session policies are advanced policies that you pass in a parameter when you programmatically create a temporary session for a role or federated user. The permissions for a session are the intersection of the identity-based policies for the IAM entity (user or role) used to create the session and the session policies. Permissions can also come from a resource-based policy. An explicit denial in any of these policies overrides the allow.

Amazon Resource Name (ARN)

A resource-based policy can specify the Amazon Resource Name (ARN) of the user or role as a principal. In that case, the permissions from the resource-based policy are added to the role or user’s identity-based policy before the session is created.

The session policy limits the total permissions granted by the resource-based policy and the identity-based policy. The resulting session’s permissions are the intersection of the session policies and the resource-based policies plus the intersection of the session policies and identity-based policies.

4. Allowed Access

Once the request has been authenticated the authorized users are allowed access to perform actions or operations.

Actions or Operations

Operations are defined by a service and include things that you can do to a resource, such as viewing, creating, editing, and deleting that resource.

For example, IAM supports approximately 40 actions for a user resource, including the following actions like CreateUser / DeleteUser / GetUser /UpdateUser.

• Tip: To allow a user/group/role/application to perform an operation, you must include the necessary actions in a policy that applies to the principal or the affected resource.

Resources

After AWS approves the operations in your request, they can be performed on the related resources within your account. A resource is an object that exists within a service. Examples include an Amazon EC2 instance, an IAM user, and an Amazon S3 bucket. The service defines a set of actions that can be performed on each resource.

If you create a request to perform an unrelated action on a resource, that request is denied. For example, if you request to delete an IAM role but provide an IAM group resource, the request fails.

How to Monitor Resources: IAM Access Analyzer

IAM also offers IAM Access Analyzer which helps you identify the resources in your organization and accounts, such as Amazon S3 buckets or IAM roles, that are shared with an external entity. This lets you identify unintended access to your resources and data, which is a security risk. The AWS internal services can be monitored by using Cloud Watch and Cloud Trail.

Access Analyzer identifies resources that are shared with external principals by using logic-based reasoning to analyze the resource-based policies in your AWS environment. For each instance of a resource that is shared outside of your account, Access Analyzer generates a finding. Findings include information about the access and the external principal that it is granted to.

You can review findings to determine whether the access is intended and safe, or the access is unintended and a security risk. In addition to helping, you identify resources that are shared with an external entity, you can use Access Analyzer findings to preview how your policy affects public and cross-account access to your resource before deploying resource permissions.

AWS IAM Glossary

Below are some common AWS IAM terms and acronyms.

Making Seamless Transitions

AWS Identity can be internal to AWS users or external like federated users. AWS Access can be done using security policies in different levels. It is best to implement AWS IAM by understanding your organization’s user and service requirements and security considerations. It is equally important to recognize the current infrastructure and choose the appropriate implementation methodology to make sure the transition to the cloud is seamless.

Source

Amazon Users Guide