Identity Access Management (IAM) is the most widely used AWS service. Amazon Web Services (AWS) offers high level data protection when compared to an on-premises environment, at a lower cost. It enables secure control access to AWS resources and services for the customers. Customers can create and manage AWS users as well as groups, and provides necessary permissions to allow or deny access to AWS resources. In a simple term IAM provides an infrastructure necessary to control authentication and authorization for its customers account.
Resource policies allow customers to granularly control who is able to access a specific resource and how they are able to use it across the entire cloud environment. With one click in the IAM console, customers can enable IAM Access Analyzer across their account to continuously analyze permissions granted using policies associated with their Amazon S3 buckets, AWS KMS keys, Amazon SQS queues, AWS IAM roles, and AWS Lambda functions.
IAM Access Analyzer continuously monitors policies for changes, meaning AWS customers no longer need to rely on intermittent manual checks in order to catch issues as policies are added or updated. Using IAM Access Analyzer, they can proactively address any resource policies that violate their security and governance best practices around resource sharing and protect their resources from unintended access. IAM Access Analyzer delivers comprehensive, detailed findings through the AWS IAM, Amazon S3, and AWS Security Hub consoles and also through its APIs. Findings can also be exported as a report for auditing purposes. IAM Access Analyzer findings provide definitive answers of who has public and cross-account access to AWS resources from outside an account.
AWS Identity Access Management Capabilities
AWS Identity and Access Management (IAM) enables customers to securely control access to AWS services and resources for their users.
Using IAM, customers can create and manage AWS users and groups, and use permissions to allow and deny their access to AWS resources.
IAM makes it easy to provide multiple users secure access to AWS resources.
Attribute-based access control (ABAC) is an authorization strategy that defines permissions based on attributes. In AWS, these attributes are called tags. Tags can be attached to IAM principals (users or roles) and to AWS resources. You can create a single ABAC policy or small set of policies for your IAM principals. These ABAC policies can be designed to allow operations when the principal’s tag matches the resource tag. ABAC is helpful in environments that are growing rapidly and helps with situations where policy management becomes cumbersome.
For example, you can create three roles with the
access-projecttag key. Set the tag value of the first role to
Heart, the second to
Sun, and the third to
Lightning. You can then use a single policy that allows access when the role and the resource are tagged with the same value for
access-project. For a detailed tutorial that demonstrates how to use ABAC in AWS, see IAM Tutorial: Define permissions to access AWS resources based on tags.
Multi Factor Authentication :-Customers can add two-factor authentication to their account and to individual customers (users) for extra security.
With MFA customers or their users must provide not only a password or access key to work with user account, but also a code from a specially configured device.
By using the Multi-factor authentication customers can easily add the two-factor authentication not only for their account but also for the individual users for more security.
AWS Identity and Access Management (IAM) lets customers manage several types of long-term security credentials for IAM users using the following
- Passwords:- Used to sign in to secure AWS pages, such as the AWS Management Console and the AWS Discussion Forums.
- Access keys:- Used to make programmatic calls to AWS from the AWS APIs, AWS CLI, AWS SDKs, or AWS Tools for Windows PowerShell.
- Amazon CloudFront key pairs:- Used for CloudFront to create signed URLs.
- SSH public keys:- Used to authenticate to AWS CodeCommit repositories.
- X.509 certificates:- Used to make secure SOAP-protocol requests to some AWS services.
Manage federated users and their permissions :- Customers can enable identity federation to allow existing identities (users, groups, and roles) in their enterprise to access the AWS Management Console, call AWS APIs, and access resources, without the need to create an IAM user for each identity.
- Access and Federation :– User can grant other people permission to administer and use resources in your AWS account without having to share your password or access key.
AWS offers multiple options for federating customers identities in AWS. One of them being AWS Identity and Access Management (IAM) which enable users to sign in to their AWS accounts with their existing given credentials.
Manage IAM users:- AWS clients can grant other people permission to administer and use resources in their AWS account without having to share their password or access key. They can also create users in IAM, assign them individual security credentials (such as access keys, passwords, and multi-factor authentication devices), or request temporary security credentials to provide users access to AWS services and resources. You can manage permissions in order to control which operations a user can perform. IAM users can be:
- Privileged administrators who need console access to manage your AWS resources.
- End users who need access to content in AWS.
- Systems that need privileges to programmatically access your data in AWS.
Securing Application Access:- AWS Identity and Access Management (IAM) helps customers control access and permissions to thier AWS services and resources, including compute instances and storage buckets. they also can use IAM features to securely give applications that run on EC2 instances the credentials that they need in order to access other AWS resources, like
- S3 buckets and RDS
- DynamoDB databases.
The AWS Security Token Service (STS):- IAM roles allow customers to delegate access to users or services that normally don’t have access to their organization’s AWS resources. IAM users or AWS services can assume a role to obtain temporary security credentials that can be used to make AWS API calls. In other word AWS customers don’t have to share long-term credentials or define permissions for each entity that requires access to a resource. Using the AWS Security Token Service (STS), that is a web service that enables customers to request temporary, limited-privilege credentials for IAM users or for users that they authenticate (federated users).
Customers do not have to distribute or embed long-term AWS security credentials with an application.
- Customers can provide access to their AWS resources to users without having to define an AWS identity for them.
- The temporary security credentials have a limited lifetime.
- After temporary security credentials expire, they cannot be reused.
- AWS STS are features of customers AWS account offered at no additional charge. However customers will bare that are charged they access other AWS services using your IAM users or AWS STS temporary security credentials.
Granular Permissions:- Granular permission enables customers to grant the permissions for different according to their resources. Customers can give the whole access to AWS services, while limiting the other users to read-only access along with the administrator EC2 instances in order to access the process of billing information. These services include;
Amazon Elastic Compute Cloud (Amazon EC2), Amazon Simple Storage Service (Amazon S3), Amazon DynamoDB, Amazon Redshift.
For other users, customers can allow
- Read-only access to just some S3 buckets,
- Permission to administer just some EC2 instances, or
- Access to customer billing information but nothing else.
- IAM also enables customers to add specific conditions such as time of day to control how a user can use AWS,
- Their originating IP address, whether they are using SSL, or
- Whether customers have authenticated with a multi-factor authentication device.
An entity in AWS that can perform actions and access resources. A principal can be an AWS account root user, an IAM user, or a role. You can grant permissions to access a resource in one of two ways:
Principalelement in a policy to specify the principal that is allowed or denied access to a resource. AWS customers cannot use the
Principalelement in an IAM identity-based policy. They can use it in the trust policies for IAM roles and in resource-based policies. Resource-based policies are policies that they embed directly in an IAM resource. For example, they can embed policies in an Amazon S3 bucket or an AWS KMS customer master key (CMK).
AWS customers can specify any of the following principals in a policy:
- AWS account and root user
- IAM users
- Federated users (using web identity or SAML federation)
- IAM roles
- Assumed-role sessions
- AWS services
- Anonymous users (not recommended)
Principalelement in these ways:
- In IAM roles, use the
Principalelement in the role’s trust policy to specify who can assume the role. For cross-account access, the customer must specify the 12-digit identifier of the trusted account.
- In resource-based policies, use the
Principalelement to specify the accounts or users who are allowed to access the resource.
A Request is a process where a principal send to AWS in order to use the AWS Management Console, the AWS API, or the AWS CLI. The request includes:
- Actions or operations – The actions or operations that the principal wants to perform.
- Resources – The AWS resource object upon which the actions or operations are performed.
- Principal – The person or application that used an entity (user or role) to send the request. Information about the principal includes the policies that are associated with the entity that the principal used to sign in.
- Environment data – Information about the IP address, user agent, SSL enabled status, or the time of day.
- Resource data – Data related to the resource that is being requested. This can include information such as a DynamoDB table name or a tag on an Amazon EC2 instance.
AWS gathers the Request information into a request context, which is used to evaluate and authorize the request.
Authorization is a process of specifying exactly what actions a principal can and cannot perform in AWS resources. This will be possible after IAM has authenticated the principal, then IAM must manage the access of that principal to protect the client AWS infrastructure. Authorization is handled in IAM by defining specific privileges in policies and associating those policies with principals.
- Effect:– Allow or Deny.
- Service:– Most AWS Cloud services support granting access through IAM, including IAM itself.
- Resource:– The resource value specifies the specific AWS infrastructure for which this permission applies.
- Action:– Action value specifies the subset of actions within a service that the permission allows or denies.
- Condition:–The condition value optionally defines one or more additional restrictions that limit the actions allowed by the permission.
After AWS approves the operations of customers’ request, they can be performed on the related resources within their account. A resource is an object that exists within a service. the resources 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.
A principal must be authenticated (signed in to AWS) using their credentials to send a request to AWS.
To authenticate from the console as a root user, customers need to sign in with their email address and password.
- IAM provide customers their account ID or alias, and then their users name and password.
- Principal can be authenticated three ways :
- By using User name and Password
- By using access key, that’s a combination of an access key ID (20 characters) and an access secret key (40 characters).
- Access Key/Session Token—When a process operates under an assumed role, the temporary security token provides an access key for authentication.
After the request has been authenticated and authorized, AWS approves the actions or operations in customers’ request. Operations are defined by a service, and include things that the customer can do to a resource, such as viewing, creating, editing, and deleting that resource. IAM supports approximately 40 actions for a user resource, including the following actions:
To allow a principal to perform an operation, you must include the necessary actions in a policy that applies to the principal or the affected resource
Operations (Actions) are defined by a service that include things such as viewing, creating, editing, and deleting that resource by customers. In order to get granted in these Operations, Principals (Root user,IAM user, and Role) request need to pass Authentication and Authorization.
An IAM user is an entity that customers create in AWS. The IAM user represents the person or service who uses the IAM user to interact with AWS. A primary use for IAM users is to give people the ability to sign in to the AWS Management Console for interactive tasks and to make programmatic requests to AWS services using the API or CLI. A user in AWS consists of a name, a password to sign into the AWS Management Console, and up to two access keys that can be used with the API or CLI. IAM user accounts are user accounts which customers can create for individual services offered by AWS.
Root Users can create IAM, and assign them individual security credentials such as words, access keys, passwords, and multi-factor authentication devices, or request temporary security credentials to provide users access to AWS services and resources.
- IAM user represents the person or service who uses the IAM user to interact with AWS.
- A primary use for IAM users is to give people the ability to sign in to the AWS Management Console for interactive tasks and to make programmatic requests to AWS services using the API or CLI.
- Root users can create IAM users, attach group level policies or user level policies and share these IAM accounts with other entities.
- Group level and user level policies restrict and authorize individual IAM users to AWS services under Root user account.
- IAM users are individuals who have been granted access to an AWS account. Each IAM user has three main components:
- A user-name.
- A password.
- Permissions to access various resources.
- Customers have persistent identities set up through the IAM service to represent individual people or applications.
The description of power user access given by AWS is “Provides full access to AWS services and resources, but does not allow management of Users and groups.” The power to manage user is the highest privilege operation in AWS thus it is provided to the administrative access policy only.
- Power users are just below the Root user and have all the privileges the Root user has with the exception of the ability to manage the IAM users.
Roles and Temporary Security Tokens
AWS IAM role is same as the user in which AWS identity with certain permission policies to determine specific identity that can or cannot be done with AWS. One can also use similar roles to delegate certain access to the users, applications or else services to have access to AWS resources.
- Roles are used to grant specific privileges to specific entities for a set duration of time. These entities can be authenticated by AWS.
- AWS provides these entities with a temporary security token from the AWS Security Token Service (STS), which lifespan run between 5 min to 36 hours.
- Customers can create roles in IAM and manage permissions to control which operations can be performed by the entity.
- Customers can also define which entity is allowed to assume the role. In addition, they can use service-linked roles to delegate permissions to AWS services that create and manage AWS resources on your behalf.
- Granting permissions to users from other AWS accounts, whether you control those accounts or not known as Cross-Account Access
- IAM users can temporarily assume a role to take on permissions for a specific task.
- Temporary credentials are primarily used with IAM roles and automatically expire.
- A role can be assigned to a federated user who signs in using an external identity provider.
- IAM roles can be used for granting applications running on EC2 instances permissions to AWS API requests using instance profiles.
- Only one role can be assigned to an EC2 instance at a time.
- Using IAM roles for Amazon EC2 removes the need to store AWS credentials in a configuration
- IAM Role Delegation has two policies:
- Permissions policy – grants the user of the role the required permissions on a resource.
- Trust policy – specifies the trusted accounts that are allowed to assume the role.
An IAM role is very similar to a user, in that it is an identity with permission policies that determine what the identity can and cannot do in AWS. However, a role does not have any credentials (password or access keys) associated with it. Instead of being uniquely associated with one person, a role is intended to be assumable by anyone who needs it. An IAM user can assume a role to temporarily take on different permissions for a specific task. A role can be assigned to a federated user who signs in by using an external identity provider instead of IAM. AWS uses details passed by the identity provider to determine which role is mapped to the federated user.
An IAM group is a collection of IAM users. Groups let Root users specify permissions for multiple users, which can make it easier to manage the permissions for those users. Customers can use groups to specify permissions for a collection of users, which can make those permissions easier to manage for those users. Any user in that group automatically has the permissions that are assigned to the group.
- A group is not an identity and cannot be identified as a principal in an IAM policy.
- Groups are collections of users and have policies attached to them.(admin, developers, human resources…)
- A group can contain many users, and a user can belong to multiple groups.
- Groups can’t be nested; they can contain only users, not other groups.
- Use the principal of least privilege when assigning permissions.
- Customers cannot nest groups (groups within groups).
The “identity” aspect of AWS Identity and Access Management (IAM) helps customers with the question “Who is that user?”, often referred to as authentication. Instead of sharing their root user credentials with others, they can create individual IAM users within their account that correspond to users in their organization. IAM users are not separate accounts; they are users within customers’ accounts. Each user can have its own password for access to the AWS Management Console.
Using the following elements, IAM provides the infrastructure necessary to control authentication and authorization for customers’ accounts. They are Principal, Request, Authentication, Authorization, Actions (Operations), and Resource.
A principal is a an IAM entity or application that is allowed to interact with AWS resources, or that can make a request for an action or operation on an AWS resource. The principal is authenticated as the AWS account root user. A principal can be permanent or temporary, and it can represent a human or an application. The administrative IAM user is the first principle, which can allow the user for the particular services in order to assume a role.
- There are three types of principals: root users, IAM users, and roles/temporary security tokens.
The username and password customers used to create an AWS account for the first time is called root user account. This account contains one important right that no other account created under IAM will have – the right to delete the entire AWS account including all storage, all EC2 instances, containers and everything else for that matter.
- The account root user credentials are the email address used to create an account and a password. The root account has full administrative permissions and it cannot be restricted.
- It’s AWS recommendation that customers not to use the root user for their everyday tasks.
- Best practice for root accounts:
- Don’t use the root user credentials.
- Don’t share the root user credentials.
- Create an IAM user and assign administrative permissions as required.
- Enable MFA
Amazon Cognito provides authentication, authorization, and user management for customers web and mobile apps. AWS customers users can sign in directly with a user name and password, or through a third party such as Facebook, Amazon, Google or Apple.
The two main components of Amazon Cognito are user pools and identity pools. User pools are user directories that provide sign-up and sign-in options for your app users. Identity pools enable customers to grant their users access to other AWS services. AWS customers can use identity pools and user pools separately or together.
A user pool is a user directory in Amazon Cognito. With a user pool, Aws clients users can sign in to their web or mobile app through Amazon Cognito, or federate through a third-party identity provider (IdP). Whether their users sign in directly or through a third party, all members of the user pool have a directory profile that they can access through an SDK.
User pools provide:
- Sign-up and sign-in services.
- A built-in, customizable web UI to sign in users.
- Social sign-in with Facebook, Google, Login with Amazon, and Sign in with Apple, and through SAML and OIDC identity providers from clients user pool.
- User directory management and user profiles.
- Security features such as multi-factor authentication (MFA), checks for compromised credentials, account takeover protection, and phone and email verification.
- Customized workflows and user migration through AWS Lambda triggers.
With an identity pool, AWS client users can obtain temporary AWS credentials to access AWS services, such as Amazon S3 and DynamoDB. Identity pools support anonymous guest users, as well as the following identity providers that they can use to authenticate users for identity pools:
- Amazon Cognito user pools
- Social sign-in with Facebook, Google, Login with Amazon, and Sign in with Apple
- OpenID Connect (OIDC) providers
- SAML identity providers
- Developer authenticated identities
To save user profile information, AWS customers identity pool needs to be integrated with a user pool.
The two main components of Amazon Cognito are user pools and identity pools. User pools are user directories that provide sign-up and sign-in options for customers web and mobile app users. Identity pools provide AWS credentials to grant their users access to other AWS services.
A user pool is a user directory in Amazon Cognito. Customers app users can sign in either directly through a user pool, or federate through a third-party identity provider (IdP). The user pool manages the overhead of handling the tokens that are returned from social sign-in through Facebook, Google, Amazon, and Apple, and from OpenID Connect (OIDC) and SAML IdPs. Whether your users sign in directly or through a third party, all members of the user pool have a directory profile that you can access through an SDK.
With an identity pool, your users can obtain temporary AWS credentials to access AWS services, such as Amazon S3 and DynamoDB. Identity pools support anonymous guest users, as well as federation through third-party IdPs.
AWS Fargate is a technology that AWS customers can use with Amazon ECS to run containers without having to manage servers or clusters of Amazon EC2 instances. With Fargate, they no longer have to provision, configure, or scale clusters of virtual machines to run containers. This removes the need to choose server types, decide when to scale their clusters, or optimize cluster packing.
When customers run their Amazon ECS tasks and services with the Fargate launch type or a Fargate capacity provider, the package they application in containers, specify the CPU and memory requirements, define networking and IAM policies, and launch the application. Each Fargate task has its own isolation boundary and does not share the underlying kernel, CPU resources, memory resources, or elastic network interface with another task.
Benefits of Amazon Fargate
- With Fargate, customer can focus on building and operating your applications whether they are running it with ECS or EKS. They only interact with and pay for your containers, and avoid the operational overhead of scaling, patching, securing, and managing servers. Fargate ensures that the infrastructure customers containers run on is always up-to-date with the required patches.
- Fargate launches and scales the compute to closely match the resource requirements customers specify for the container. With Fargate, there is no over-provisioning and paying for additional servers. Customers can also get Spot and Compute Savings Plan pricing options with Fargate just like with Amazon EC2 instances. Compared to On-Demand prices, Fargate Spot provides up to 70% discount for interrupt-tolerant applications, and Compute Savings Plan offers up to 50% discount on committed spend for persistent workloads.
- Individual ECS tasks or EKS pods each run in their own dedicated kernel runtime environment and do not share CPU, memory, storage, or network resources with other tasks and pods. This ensures workload isolation and improved security for each task or pod.
- With Fargate, customers get out-of-box observability through built-in integrations with other AWS services including Amazon CloudWatch Container Insights. Fargate allows them to gather metrics and logs for monitoring their applications through an extensive selection of third party tools with open interfaces.
Lock away the AWS root user access keys:- The access key for customers AWS account root user gives full access to all their resources for all AWS services, including customers’ billing information. Its important not to share AWS account root user password or access keys with anyone
Use groups to assign permissions to IAM users:- Instead of defining permissions for individual IAM users, it’s usually more convenient to create groups that relate to job functions (administrators, developers, accounting, etc.). Next, define the relevant permissions for each group. Finally, assign IAM users to those groups. All the users in an IAM group inherit the permissions assigned to the group. That way, you can make changes for everyone in a group in just one place. As people move around in AWS clients company, they can simply change what IAM group their IAM user belongs to.
Use Access Levels to Review IAM Permissions:- To improve the security of customers AWS account, theyshould regularly review and monitor each of their IAM policies. Make sure that the policies grant the least privilege that is needed to perform only the necessary actions.
- When AWS customers review a policy, they can view the policy summary that includes a summary of the access level for each service within that policy. AWS categorizes each service action into one of five(List, Read, Write, Permissions management, or Tagging) access levels based on what each action does.
Use Roles to Delegate Permissions:- Don’t share security credentials between accounts to allow users from another AWS account to access resources in your AWS account. Instead, use IAM roles. Customers can define a role that specifies what permissions the IAM users in the other account are allowed. They can also designate which AWS accounts have the IAM users that are allowed to assume the role.
Rotate Credentials Regularly:- It is important to change the root passwords and access keys regularly, and make sure that all IAM users in the account do as well. That way, if a password or access key is compromised without Principal knowledge, they can limit how long the credentials can be used to access their resources. They can apply a password policy to their account to require all their IAM users to rotate their passwords. Customers can also choose how often they must do so.
Monitor Activity the AWS Account:- By using logging features in AWS customers can determine the actions users have taken in their account and the resources that were used. The log files show the time and date of actions, the source IP for an action, which actions failed due to inadequate permissions, and more.
Create individual IAM users:- Its important not to use AWS account root user credentials to access AWS. Instead, create individual users for anyone who needs access to the AWS account.
Grant Least Privilege:- When creating IAM policies, it is important to follow the standard security advice of granting least privilege, or granting only the permissions required to perform a task. Determine what users (and roles) need to do and then craft policies that allow them to perform only those tasks.
- Start with a minimum set of permissions and grant additional permissions as necessary. Doing so is more
secure than starting with permissions that are too lenient and then trying to tighten them later.
Configure a Strong Password Policy for the Users:- When letting the users to change their own passwords, they should be required to create strong passwords and that they rotate their passwords periodically. On the Account Settings page of the IAM console, they can create a password policy for their account. Customers can use the password policy to define password requirements, such as minimum length, whether it requires non-alphabetic characters, how frequently it must be rotated, and so on.
Enable MFA for privileged users:- For extra security, we recommend that customers to require multi-factor authentication (MFA) for all users in their account. With MFA, users have a device that generates a response to an authentication challenge. Both the user’s credentials and the device-generated response are required to complete the sign-in process. If a user’s password or access keys are compromised, customers account resources are still secure because of the additional authentication requirement.
Do Not Share Access Keys:- Access keys provide programmatic access to AWS. Do not embed access keys within unencrypted code or share these security credentials between users in your AWS account. For applications that need access to AWS, configure the program to retrieve temporary security credentials using an IAM role. To allow customers users for individual programmatic access, create an IAM user with personal access keys.
Remove Unnecessary Credentials :- Remove IAM user credentials (passwords and access keys) that are not needed. Passwords and access keys that have not been used recently might be good candidates for removal. Customers can find unused passwords or access keys using the console, using the CLI or API, or by downloading the credentials report.