Understanding AWS IAM and its Fundamentals

Β·

9 min read

Understanding AWS IAM and its Fundamentals

Introduction to AWS IAM:

  • IAM controls who is authenticated (signed in) and authorized (has permissions) to use resources.

  • The AWS account root user is a single sign-in identity that has complete access to all AWS services and resources in the account.

  • With IAM, Organizations can centrally manage users, security credentials such as access keys, and permissions that control which AWS resources users can access.

  • Without IAM, Organizations with multiple users must either create multiple user accounts, each with its billing and subscriptions to AWS products or share an account with a single security credential. Without IAM, you also don't have control over the tasks that the users can do.

AWS IAM Components:

IAM service is used to manage and control security permissions.

  1. Users - These are the objects within IAM identifying different users.

  2. Groups - These are the objects that contain multiple users.

  3. Roles - These are objects that different identities can adopt to assume a new set of permissions.

  4. Access Control Mechanism - This is a mechanism that governs how a resource is accessed.

  5. Policies - These are the JSON policies that define what resources can and can't be accessed. There are 3 types of policies available -

    • AWS-Managed Policies - created and managed by AWS

    • Customer-Managed Policies - created and managed by ourselves and are stored in our own AWS account, and we can change them as needed. They are recommended for use cases where the existing AWS Managed Policies don’t meet the needs of your environment.

    • Inline policy - These policies are embedded within the user, group, or role to which it is applied and have a strict relationship between the entity and the policy.

  6. Identity Providers and Federations - This allows IAM to integrate with external identity systems.

  7. Permissions Boundary - An advanced IAM feature that allows you to limit the number of permissions that an entity (user or role) can have. By setting this up, you can prevent users or roles from exceeding certain permissions, even if they are assigned additional policies or permissions directly. This feature is useful when you want to restrict the actions that a user or role can perform, providing an extra layer of control and reducing the risk of unintended privilege escalation.

  8. IAM Access Analyzer - This analyzes resource policies to help administrators and security teams ensure their policies provide only required access.

IAM Role and its Types:

IAM Roles in AWS is a way to grant permissions to entities, such as AWS services, applications, or users, without the need for long-term credentials like access keys. IAM roles play a crucial role in enhancing security and managing access in AWS environments.

Currently, there are 4 different types of Roles: -

  1. AWS Service Role - This Role would be used by other services that would assume the role to perform specific functions based on a set of permissions associated with it.

    Examples - Amazon EC2, AWS Directory Service, AWS Lambda etc. Once you have selected your service role, you would then need to attach a policy with the required permissions and set a role name to complete its creation.

  2. AWS Service-Linked Role - Specific Roles that are associated with certain AWS services. They are pre-defined by AWS, and the permissions can't be altered in any way, as they are set to perform a specific function. Example - Amazon Lex - bots and Amazon Lex - channels. Once you have selected your service-linked role, you simply need to assign it a name and complete the creation. Remember, these roles do not allow you to modify the permissions assigned.

  3. AWS cross-account access - This Role type offers 2 options:-

    a) Providing access between AWS accounts that you own.

    b) Providing access between an account that you own and a 3rd party AWS account. This access is managed by policies that establish trusting and trusted accounts that explicitly allow a trusted principal to access specific Resources. Many services use roles to allow cross-account access to resources.

    At a high level, these roles are configured as follows:

    Trusting account - which has the resources that need to be accessed.

    Trusted account - which contains users that need to access the resources in the 'trusting account'.

    A role is created in the Trusting account. A Trust is established with the Role by the AWS account number of the Trusted account. Permissions are applied to the Role via policies. The users in the Trusted account have a policy attached.

     { 
         "version": "2012-10-17",
         "Statement": { 
             "Effect": "Allow", 
             "Action": "sts:AssumeRole", 
             "Resource": "arn:aws:iam::TRUSTING-ACCOUNT-ID:role/NAME-OF-ROLE"
          } 
     }
    
  4. A role for Identity Provider access - It offers 3 different options.

    a) Grant access to web identity providers - which creates trust for users using Amazon Cognito, Amazon, Facebook, Google or another provider.

    b) Grant web SSO to SAML providers - which allows access for users coming from a SAML Provider.

    c) Grant API access to SAML Providers - which allows access from SAML providers via AWS CLI, SDKs or API calls. For this option, a trust relationship is set up between the external identity providers to allow access to your AWS account's resources, using their existing Identity provider login information.

IAM Policies breakdown:

Let's take the below policy as an example which allows the AWS root account to perform actions such as listing and getting objects within the specified S3 bucket (my-bucket) from IP addresses within the range of 10.10.0.0/16.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "MySID",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::<account-id>:root"
      },
      "Action": [
        "s3:List*",
        "s3:Get*"
      ],
      "Resource": "arn:aws:s3:::my-bucket/*",
      "Condition": {
        "IpAddress": {
          "aws:SourceIp": ["10.10.0.0/16"]
        }
      }
    }
  ]
}

Here's a breakdown of the policy:

Version - This is a policy language version.

Statement - The main element of the policy, which includes 5 elements stated below, which will identify the level of access granted or denied and to which Resource:-

Sid - This is a unique Identifier with the statement array and as you will add more permissions, you will have multiple Sids within the Statement.

Effect - This element can either be set to grant or restrict access for the previously defined action by the value of "allow" or "deny". The access to your resources is denied by default.

Principals - This is the entity that can request an action or operation on an AWS resource.

There are several types of principals in IAM:

  • AWS account: An AWS account is the root entity in AWS IAM. Principals can also be an AWS account, which can assume a role in other accounts.

      arn:aws:iam::<account-id>:root
    
  • IAM user: An IAM user is an entity that is created within an AWS account. It is represented by an AWS User ARN, which is a unique identifier that includes the account ID and the user name. IAM users can be granted permission to perform actions on AWS resources.

      arn:aws:iam::<account-id>:user/my-user
    
  • IAM role: An IAM role is an entity that is created within an AWS account. It is represented by an AWS Role ARN, which is a unique identifier that includes the account ID and the role name. IAM roles can be assumed by IAM users, federated users, and AWS services.

      arn:aws:iam::<account-id>:role/my-role
    
  • Federated user: A federated user is an entity that is created outside of AWS and is authenticated using an external identity provider such as Facebook, google etc. It is represented by a federated user ID, which is a unique identifier that is issued by the external identity provider. Federated users can be granted permission to perform actions on AWS resources.

      arn:aws:sts::<account-id>:federated-user/my-external-id
    
  • AWS service: An AWS service is a built-in entity that represents an AWS service. It is represented by an AWS service principal, which is a unique identifier that includes the service name. AWS services can perform actions on AWS resources on behalf of their users.

      arn:aws:iam::<account-id>:service/service-name
    

Action - This is the action that will either be allowed or denied, depending on the value entered for the "Effect" Element. Actions are API calls for different services. As a result, different Actions are used for each service. Action is prefixed with the associated AWS service. For Example - action to list and get S3 buckets.

"Action": ["s3:List*", "s3:Get*"]

Resource - This element specifies the actual resource you wish the "Action" and "Effect" to be applied to. AWS uses ARNs to specify resources.

"Resource": "arn:aws:s3:::my-bucket/*"

Condition- This is the option Element that allows you to control when the permission will be effective based on the set criteria. The Element is itself made up of the condition and a key-value pair and all elements of the condition must be met for the permission to be effective.

Here, This condition restricts the policy to only apply when the request originates from an IP address within the range of 10.10.0.0/16.

"Condition": { "IpAddress": { "aws:sourceIp": "10.10.0.0/16" } }

Here, the IP address is the condition itself, which the key-value pair will be effective against. AWS sourceIP is the key and IP address is the value of the key. This above statement is saying that if the source IP address of the user who is using the policy is within the 10.10.0.0/16 network range, then allow the permissions to be used.

AWS IAM Authentication Methods:

  1. Console: The AWS Management Console is a web-based interface that you can use to manage your AWS resources. To authenticate to the console, you need to sign in with your AWS account credentials.

  2. CLIs: The AWS Command Line Interface (CLI) is a tool that you can use to manage your AWS resources from the command line. To authenticate to the CLI, you need to configure it with your AWS account credentials (access and secret access keys).

  3. API SDKs: The AWS API SDKs are libraries that you can use to access AWS resources from your code. To authenticate to the API SDKs, you need to configure them with your AWS account credentials. For Python, we use boto3 and for accessing resources using Nodejs we have AWS SDK for JavaScript, similarly available for the other programming languages as well but these 2 are most common.

Conclusion:

On a closing note, AWS IAM is a critical component of the AWS cloud platform, providing a comprehensive set of tools and features for managing access to AWS resources. It enables organizations to secure their cloud environments by granting users and applications the appropriate permissions to perform specific actions on specific resources. By leveraging IAM, organizations can enforce granular access controls, enhance security, and ensure compliance with regulatory requirements.

Reference Links:

Please refer to this for more details - https://digitalcloud.training/aws-iam/

Access management for AWS Resources - https://docs.aws.amazon.com/IAM/latest/UserGuide/access.html

IAM Policies and Permissions - https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html

Thank you so much for reading my blog! 😊 I hope you found it helpful and informative. If you did, please πŸ‘ give it a like and πŸ’Œ subscribe to my newsletter for more of this type of content. πŸ’Œ

I'm always looking for ways to improve my blog, so please feel free to leave me a comment or suggestion. πŸ’¬

Thanks again for your support!

Connect with me -

LinkedIn - https://www.linkedin.com/in/rachitmishra1997/

Twitter - https://twitter.com/racs1997

#aws #awscommunity #cloudcomputing #cloud

Did you find this article valuable?

Support Cloud & Devops with Rachit by becoming a sponsor. Any amount is appreciated!

Β