AWS - Identity and Access Management a Deep Dive

Identity and Access Management (IAM) is a one of the powerful access and authorization tool. secure by default, used to provide access to user, resource, AWS service and users from other enterprises. Also provides granule permission to user, resource or application


When you create a new user in IAM, by default this user has no permission assigned for any AWS resource. You have to explicitly grant permissions to users for AWS resources and assign them unique credentials. You don't have a need for sharing credentials as you can create separate identities (user accounts) and multiple types of credentials for all use cases.


IAM features


AWS account shared access - Other users from AWS can access your AWS account without sharing the credential


Granular permission - User A with EC2 read-only access and 9am -5 pm permission. User B access can given only to billing resource, user C only to particular bucket


Account Federation - In some situation, you'll have a requirement to allow access to users or resources, such as applications outside of your organization, to interact with your AWS services. To facilitate such requirements, IAM provides a feature called Identity Federation. It allows you to provide temporary access to those having their credentials stored outside of your AWS account such as Microsoft Active Directory, Google, and so on.


Temporary credentials - Sometimes, you may have situation to provide access users, application from outside organization to access limited time and this can be achieved through temporary credentials


User can access AWS in the following ways:


  • AWS Management Console

  • AWS command line tools

  • AWS software development kit/ API

IAM authentication in AWS includes the following identities:

  • Users

  • Groups

  • Roles

  • Temporary security credentials

  • Account root user

IAM user


You create an IAM user in AWS as an entity to allow people to sign into the AWS Management Console or to make requests to AWS services from your programs using CLI or API. An IAM user can be a person, an application, or an AWS service that interacts with other AWS services in one way or another. When you create a user in IAM, you provide it with a name and a password that is required to sign into the AWS Management Console. Additionally, you can also provision up to two access keys for an IAM user consisting of the access key ID and a secret access key, that are needed to make requests to AWS from CLI or API.


by default IAM users have no permissions, so you need to give this brand new user permissions either by assigning them directly or by adding them to a group that has all the necessary permissions, the latter being recommended by AWS and a much preferred way to manage your users and their permissions. Alternatively, you can also clone permissions of an existing IAM user to copy policies and add users to the same groups as the existing IAM users




Every IAM user has an Amazon Resource Name (ARN), this name is unique for every resource across AWS


Every IAM user has a unique identifier for the user that's not visible in the AWS Management Console. You can get this ID only when you create a user in the IAM programmatically through API or AWS command line tools such as AWS CLI.


IAM groups


A collection of IAM users is known as an IAM group. Groups allow you to manage permissions for more than one users by placing them according to their job functions, departments, or by their access requirements.


IAM Role


A role is not necessarily associated with one person, application, or a service, instead, it is assumable by any resource that needs it. Moreover, credentials for roles are managed by AWS.

Roles are a very versatile feature of IAM, it can be used for a variety of use cases such as delegating access to services, applications or users that might not need access to your AWS resources regularly or they are outside of your organization and need to access your AWS resources




AWS Service 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.


Another AWS account - Access another AWS account, Allows entities in other accounts to perform actions in this account.


Web Identity - Allows users federated by the specified external web identity or OpenID Connect (OIDC) provider to assume this role to perform actions in your account.


SAML-2.0 federation - Allows users that are federated with SAML 2.0 to assume this role to perform actions in your account.


AWS Security Token Service (STS) to create temporary security credentials for users to access your AWS resources. Temporary credentials are useful in scenarios that involve identity federation, delegation, cross-account access, and IAM roles


Temporary security credentials are short lived. You can configure them to be valid from a minimum of 15 minutes to a maximum of 36 hour in case of configuring custom identity broker; the default value is 1 hour.


User can request temporary security credentials whenever required even before they expire as long as the user has permission to request


AWS Security Token Service


AWS STS is a web service that enables you to request temporary, limited privilege credentials for IAM users or for users that you authenticate (federated users) to use. Essentially, temporary security credentials are generated by AWS STS


AWS STS is a global service with a single endpoint at https://sts.amazonaws.

com, this endpoint points to the US-East-1 (Northern Virginia) region

You can use STS in other regions as well that support this service


When you activate a region for an account, you enable the STS endpoints in that region to issue temporary credentials for users and roles in that account when a request is made to an endpoint in the region.


IAM Authorization


It is made up of the following two components:

  • Permissions

  • Policy


Permissions let you take actions on AWS resources. It allows your users (AWS identities) to perform tasks in AWS. When you create a new user (except for the root user), it has no permission to take any action in AWS. You grant permissions to the user by attaching a policy to that user. So, for example, you can give permission to a user to access certain S3 buckets or to launch an EC2 instance.


You can assign permissions in couple of ways:


Identity-based: These permissions are assigned to AWS identities such as users, groups, and roles. They can either be managed or inline (we'll talk about managed and inline in our Policies section).


Resource-based: These permissions are assigned to AWS resources such as Amazon S3, Amazon EC2. Resource-based permissions are used to define who has access to an AWS resource and what actions they can perform on it. Resource-based policies are inline only, not managed.


A policy that is attached to an identity in IAM is known as an identity-based policy. Identity-based policies can include AWS managed policies, customer managed policies, and inline policies. AWS managed policies are created and managed by AWS. You can use them, but you can't manage them. An inline policy is one that you create and embed directly to an IAM group, user, or role. Inline policies can't be reused on other identities or managed outside of the identity where it exists


As a best practice, use customer managed policies instead of inline policies. It's also best to use customer managed policies instead of AWS managed policies. AWS managed policies usually provide broad administrative or read-only permissions. For greatest security, grant least privilege, which is granting only the permissions required to perform specific job tasks.


When you create a policy, you can do with Visual editor or by JSON



Let us look into the components of Policy


Service - AWS service

Action - what action is to be performed, list, read, & write

Resource - applicable to all resources or specific resource

Condition - MFA, from which Source ip


The following is a sample policy used to allow all describe actions for all EC2 instances:


The Statement element contains an array of individual statements. Each individual statement is a JSON block enclosed in braces { }


Effect specifies if an action is allowed or denied; it has only two valid values, allow, and deny. by default, the value is deny, you have to explicitly allow it.


A Principal element is used to define the user. A user can be an IAM user, federated user, role using user, any AWS account, any AWS service, or any other AWS entity that is allowed or denied access to a resource and that can perform actions in your AWS account. You use the Principal element in the trust policies for IAM roles and in resource-based policies.


Passwords Policy


You can set up the password policy for your AWS account from IAM. Navigate to the IAM dashboard from the AWS console. Click on Account settings. As shown in the following figure, on the Password Policy page, you can setup requirements such as minimum password length, rotation period, and so on.


IAM best practices


To help secure your AWS resources, follow these recommendations for the AWS Identity and Access Management (IAM) service.

Lock away your AWS account root user access keys

  • Don`t create programmatic access keys for Root account

  • If you already have one delete it immediately, if you must have root api keys for your environment required, rotate often the keys and enable multifactor authentication for root user

Create individual IAM users Use user groups to assign permissions to IAM users

  • Create group for each functions and provide granular access

Grant least privilege

When you create IAM policies, follow the standard security advice of granting least privilege, or granting only the permissions required to perform a task.


Get started using permissions with AWS managed policies

  • The most secure way to grant least privilege is to write a custom policy with only the permissions needed by your team. You must create a process to allow your team to request more permissions when necessary.

  • Adding permissions to any IAM identities, AWS managed policies are used and AWS managed policies cover common use cases and are available in your AWS account.

  • AWS managed polices attached to any Identities

Validate your policies

  • Validate the polices that created before implementing

Use customer managed policies instead of inline policies

  • Recommended best practice is to use managed policies over inline polices. A key advantage of using these policies is that you can view all of your managed policies in one place in the console. You can also view this information with a single AWS CLI or AWS API operation. Inline policies are policies that exist only on an IAM identity (user, user group, or role). Managed policies are separate IAM resources that you can attach to multiple identities.

  • If you are using inline policies that can be converted to Managed policies

Use access levels to review IAM permissions

  • Policies should be reviewed regularly for any security breach and policies should have least privilege's required to perform particular task

Configure a strong password policy for your users Enable MFA Use roles for applications that run on Amazon EC2 instances

  • Applications that run on an Amazon EC2 instance need credentials in order to access other AWS services. To provide credentials to the application in a secure way, use IAM roles. A role is an entity that has its own set of permissions, but that isn't a user or user group. Roles also don't have their own permanent set of credentials the way IAM users do. In the case of Amazon EC2, IAM dynamically provides temporary credentials to the EC2 instance, and these credentials are automatically rotated

Use roles to delegate permissions Do not share access keys Rotate credentials regularly Remove unnecessary credentials Use policy conditions for extra security

  • Define the conditions under which your IAM policies allow access to a resource. For example, you can write conditions to specify a range of allowable IP addresses that a request must come from. You can also specify that a request is allowed only within a specified date range or time range. You can also set conditions that require the use of SSL or MFA (multi-factor authentication). For example, you can require that a user has authenticated with an MFA device in order to be allowed to terminate an Amazon EC2 instance.

Monitor activity in your AWS account


Conclusion


AWS IAM is the one of most secured services from AWS, you can control access multiple AWS accounts, delegate permission, access to outside organization.


Permission in a AWS is simply a Role Based Access Control, you can implement set of in built in policies and custom policies


Role is a special entity which provide access to any AWS service dynamically, other AWS accounts and Account from outside the organization

28 views0 comments

Gopi Narayanaswamy
 

Gopi