Ticker

6/recent/ticker-posts

AWS IAM

bySatish Kumar February 07, 2025

 


IAM policy structure:



A Principal is a person or application that can make a request for an action or operation on an AWS resource.
  • AWS account and Root user
    •   "Principal": { "AWS": "95859940303" }
    •   "Principal": { "AWS": "arn:aws:iam::95859940303:root" }
  • IAM roles
    •   "Principal": { "AWS": "arn:aws:iam::95859940303:role/name_of_the_role" }
  • IAM Role Sessions
    •   "Principal": { "AWS": "arn:aws:iam::95859940303:role/assumed_role/name_of_the_role/name_of_the_session_role" }
    •   "Principal": { "Federated": "cognito-identity.amazonaws.com" }
    •   "Principal": { "Federated": "arn:aws:iam::95859940303:saml-provider/provider-name" }
  • IAM user
    •   "Principal": { "AWS": "arn:aws:iam::95859940303:user/user-name" }
  • Federated User Sessions
    •   "Principal": { "AWS": "arn:aws:iam::95859940303:federated-user/user-name" }
  • AWS Services
  •   "Principal": { 
          "service": [
               "ecs.amazonaws.com"
           ]
      }
  • All Principals
    •   "Principal": "*"
    •   "Principal": { "AWS": "*" }


There are two types of policy:

  1. Identity-based policy
  2. Resource-based policy

Identity-based policy:

Identity-based policies are JSON permissions policy documents that control what actions an identity can perform, on which resources, and under what conditions
it can be apply to user, group, roles


There are few ways you can attach identity based policy to users, groups or roles
  • Inline Policy: iP have one to one relationship with UGR you can't use them across the identity if you delete the identity it get deleted along with it.
  • Managed policy: It can be either aws managed policy or customer managed policy and as the name suggest aws managed policy is created by aws and customer managed policies are create and managed by you. You can attach a managed policy to multiple identity or entities

Resource-based policy:

  • Resource based policy apply to aws services usch as s3, or dynamo db
  • Resource-based policies are JSON policy documents that you attach to a resource such as an Amazon S3 bucket
  • Resource-based policies grant the specified principal permisslon to perform specific actions on the resource
  • A trust policy is also an example of a resource-based policy
  • Whereas a permissions policy is an Identity-based policy
  • Resource-based policies are inline only, not managed.
  • You can tell a resourcebased policy when it has a principal element defined
  • The following example shows a statement that allows Amazon S3 to invoke a function named my-function for a bucket named my-bucket in account 123456789012.




IAM access Control

There are two types of access control in IAM
  1. RBAC - Role based access control
  2. ABAC - Attribute based access control


RBAC - Role based access control

  • In Role-Based Access Control we might have multiple groups and those groups are created as containers to hold users who have a specific job role.
  • And then we place our users into those groups.
  • and then We then take permissions policies and apply the permissions policies to the group.
  • So the users inherit the permissions that are assigned to the group and the groups are organized by job role


ABAC - Attribute based access control

  • Attribute-Based Access Control is where we're using tags to define access to our resources.
  • I have seen organization leveraging both of them RBAC  & ABAC
  • When you have lots of users and you need to authorize lots of AWS specific resources, It can become hectic for an Administrator to manage it properly.
  • In RBAC what you would do is you will assign users to a group or department or team that will do specific Job and accordingly you would have to create IAM permission sets. Alternative is to use ABAC you tag the users and resources along with that you just need to create an IAM permission to see if they match so then they can access it. Every time when you create resource just tag them, you don't need to edit any IAM policies.





Permission boundary:



Privilege escalation can be one of the reason you may want to apply permission boundary.
let's say a user Alice has IAM full access and he might do some bad things with the resources like
he can create a user assign adminastrator policy to it and can logged it with the user and do the bad things, To prevent this situtation i.e privilege escalation you might want to use permission boundary.
The following policy will enforce the following:
  • IAM principals can't alter the permissions boundary to allow their own permissions to access restricted services
  • IAM principals must attach the permissions boundary to any IAM principals they create
  • IAM admins can't create IAM principals with more privileges than they already have
  • The IAM principals created by IAM admins can't create IAM principals with more permissions than IAM admins




Types of Policy

  • Identity-based policies - attached to users, groups, or roles
  • Resource-based policies- attached to a resource; define permissions for a principal accessing the resource
  • IAM permissions boundaries- set the maximum permissions an identity-based policy can grant an IAM entity
  • AWS Organizations service control policies (SCP) – specify the maximum permissions for an organization or OU 
  • Session policies - used with AssumeRole* API actions






IAM policy evaluation logic:




Determination Rules:

  • By default, all requests are implicitly denied (though the root user has full access)
  • An explicit allow in an identity-based or resource-based policy overrides this default
  • If a permission boundary, Organizations, SCP or session policy is present an explicit allow is used to limit actions. Anything not explicitly allowed is an implicit deny and may override the decision.
  • An explicit deny in any policy overrides any allows
  • Until you have policy attached you can't use Resource based policy


IAM Access Analyzer

AWS IAM Access Analyzer helps you identify the resources in your organization and accounts that are shared with an external entity



Access Analyzer analyzes the following resource types:



IAM Security Tools

  • IAM Credentials Report (account level):
    • This report(.csv file) shows all users in your account and the status of their different credentials for rotation purpose however alternative of this is to use AWS config rule(access-keys-rotated) with SSM automation to rotate the credential


  • IAM Access Advisor (user level)(renamed to last access):
    • Access Advisor shows the permissions a user has for different services and the last time they used those services. This information helps you update your granular policies.


SCPs:

SCPs don't affect users or roles in the management account. They affect only the member accounts in your organization.






What is service linked role?

A service-linked role is a unique type of IAM role that is linked directly to an AWS service. Service-linked roles are predefined by the service and include all the permissions that the service requires to call other AWS services on your behalf. ref


Service role vs Service-Linked-Role:
https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html


Confuse deputy Problem in IAM:

AWS IAM Identity Center(Formerly known as AWS SSO):

  • AWS recommends to use AWS IAM Identity Center
  •  If you have use cases that require access keys, you can support those use cases with users in AWS IAM Identity Center. People who sign-in through the AWS access portal can obtain access keys with short-term credentials to your AWS resources. For centralized access management, we recommend that you use AWS IAM Identity Center (IAM Identity Center) to manage access to your accounts and permissions within those accounts. IAM Identity Center is automatically configured with an Identity Center directory as your default identity source where you can add people and groups, and assign their level of access to your AWS resources.
  • The main difference between these two types of users(IAM users and IAM Identity Center users) is that users in IAM Identity Center automatically assume an IAM role when they sign-in to AWS before they access the management console or AWS resources. IAM roles grant temporary credentials each time the user signs-in to AWS. For IAM users to sign in using an IAM role they must have permission to assume and switch roles and they must explicitly choose to switch to the role they want to assume after accessing the AWS account.
  • SAML 2.0 authenticate identities from external Idp
  • When a user sign in to AWS portal using their corporate identities such as Okta, Azure AD, OneLogin, SAML 2.0 does not provide a way to query the Idp to learn about users and groups
  • You must create users and groups in the external Idp
  • There is a automated way of provisioning of user identities from an external Idp to IAM Identity Center
  • SCIM (System for cross-domain Identity Management)
  • Must be supported by the external Idp


IAM Policy examples:

First Example:
This policy lets the user or role do all actions on all AWS services except EC2 operations. Using NotAction is risky unless you have a clear and specific reason because it can accidentally give unwanted permissions.

2nd Example:
This policy denies users or roles access to all services except EC2 if MFA is not present.

3rd Example:


  • (LEFT one)This policy blocks access to all services except IAM, Route 53, and AWS Support when requests are made from any region other than us-east-2.
  • (Right one)This policy prevents users or roles from accessing any service except S3 operations when requests come from regions other than us-east-2.
  • When using a global AWS service e.g. IAM, CloudFront, Route53, Support the AWS Region is always us-east-1
4th Example:
Allowed Pricipals:
  • IAM role arn
  • IAM user
  • AWS root user
  • AWS STS federated user session
5th Example:
SourceArn is used when we service to service request are made.

6th Example:
  • Above policy denies S3 GET requests unless the call is made through Athena
  • Few services only use calledVia
    • Athena, Cloudformation, dynamoDB, KMS
7th Example:
Denies access if the source IP does not belong to the specified ranges.

8th Example:
Restrict access from Private IP addresses through a VPC endpoint

9th Example:
10th Example:
Grant access only if the user authenticated with MFA within the last 300 seconds

11the Example:
IAM role denies all permissions (forces users to reauthenticae) if the token is too old.
To revoke IAM role Temp credentials, attach the AWSRevokeOlderSessions policy.


Compromised AWS Credentials:

  • With the help of GuardDuty Identify the affected IAM user
  • Rotate the exposed AWS Credentials
  • There is way to invalidate temporary credentials by attaching an explicit Deny policy to the affected IAM user with an STS data condition (check above one)
  • You can also check cloudTrail logs for unauthorized activity
  • Review your AWS resources (If there are any deleted unauthorized resources)
  • Verify your AWS account information


Compromised IAM role:

  • In addition to above check and Revoke access for the the identity to the linked AD if any


Compromised Account

  • Rotate and delete exposed AWS access keys
  • Rotate and delete any unauthorized IAM user credentials (rotate existing IAM user's password)
  • Rotate and delete all EC2 key pairs
  • Check CloudTrail logs for other unauthorized activity
  • Review your AWS resources (e.g delete unauthorized activity)
  • Verify your AWS account information



iam:Pasrole Action ensures that only approved users can configure an AWS service with an IAM role that grants permission, btw it is not an API call. read more here


Few important AWS STS API call:

  • AssumeRole(within your or cross account access)
  • AssumeRoleWithSAML (It returns credentials for users logged with SAML)
  • AssumeRoleWithWebIdentity(It is deprecating, AWS recommends to use cognito)
  • GetSessionToken

Important Notes:

  • Some AWS CLI commands have a --dry-run option to test API calls without actually running them.
  • aws:ResourceTag (Tags that exist on AWS Resources), Addition to that you might see following service specific Tag
  • ec2:ResourceTag (Service specific Tag)
  • aws:PrincipalTag (Tags that exist on the IAM user or IAM role making the request)

There are 2 versions of STS

STS Version 1
  • It is by default enabled for enabled region however you can enable to support all regions and It is available as a global single endpoint
  • https://sts.amazonaws.com
STS Version 2
  • Since Version 1 token does not work for new AWS region. It is available as regional endpoint.
  • https://sts.me-south-1.amazonaws.com
  • It is faster, reduced latency, you can increase session token validity.


SCP example:

Example 1:

Restrict EC2 Instance Types in your account


Example 2:
Deny access to AWS based on the requested AWS Region

Reference:



Reactions

Post a Comment

0 Comments