Week 2: Securing Access to Cloud Resources: An IAM Deep Dive
A deep dive into AWS Identity and Access Management (IAM), how identity-based policies and resource-based policies interact, and how to use S3 bucket policies to control access at the resource level, based on hands-on lab work.
Series: AWS Cloud Security (4 articles)
- 2Week 2: Securing Access to Cloud Resources: An IAM Deep Dive This article
This week, I got to understand how Identity and Access Management (IAM), identity-based policies (attached to users/roles) and resource-based policies (attached to the resource itself, like an S3 bucket) actually interact at evaluation time. In this article, I’ll be explaining the various concepts learned.
IAM fundamentals
In this section, i learnt about AWS identity and Access Management (IAM). IAM is a web service mostly used by AWS services to help secure control access to AWS resources. It is used to Control who is authenticated (signed in) and who has permissions to use resources.
IAM is used to grant users, groups and application access to console and APIs. IAM also supports multi-factor authentication (MFA), this adds extra security to resources. authentication code is usually delivered to configured hardware device or a software based MFA device, such as Google's Authenticator application.
During Authenticaton, the identity of the requester is established, IAM calls them "Principals". After Authentication, the Principal permissions are checked to determine what they are allowed to do.
I also learnt about the IAM users, group and roles. In clear terms, they are defined as follows:
- An IAM user is an entity that you create in AWS to represent a person or application that interacts with AWS account services and resources. In new AWS accounts, the root user account is usually the first IAM user account.
- An IAM group is a collection of IAM users. Groups are usually used to grant same permissions to multiple users.
- An IAM role is similar to an IAM user, when a person or application assumes a role, they are provided with temporary security credentials for the role session. whereby, an IAM user is provided a permanent credential until the user is removed by the root user.
- An IAM policy is a document that explicitly lists permissions. The policy can be attached to an IAM user, an IAM group, an IAM role.
A security best practice is to attach IAM policies to IAM groups, and then assign IAM users to these IAM groups.
I learnt there are two primary types of credentials used for authentication and they include:
- Authentication through the console: This usually requires you to use your username and password.
- Programmatic Authentication through the AWS CLI, SDKs and APIs: This requires you to make use of access key, the access key is the combination of Access Key ID and a secret Key.
AWS currently supports six types of policies:
- Identity-based policies: These policies are attached to IAM identities and grant permissions to the identity.
- Resource-based policies: These are attached to resources and grant permissions to the principal specified in the policy.
- Permissions boundaries: These define the maximum permissions that the identity-based policies can grant to an entity.
- AWS Organizations service control policy (SCP): This defines the maximum permissions for account members of an organization or organizational unit (OU). It is used to limit the permissions of identity-based or resource-based policies.
- Access control lists (ACLs): You can use an ACL to control which principals in other accounts can access the resource to which the ACL is attached. You cannot use an ACL to grant permissions to entities that reside within the same account. ACLs are the only policy type that doesn't use the JSON document format.
- Session policies: These are used with the AWS CLI or AWS API to create a temporary session for a role or federated user. You can use session policies to limit the permissions that a role or a user's identity-based policies grant to a session. Session policies limit permissions but cannot grant them. IAM policies can be managed or Inline:
Managed policies are attached to users, group and roles while Inline policies are embedded in a principal entity.
I also learnt about the Amazon Cognito which is a service that provides authentication, authorization, and user management (sign-up, sign-in, and access control) for mobile and web applications.
How to use S3 bucket policies to control access at the resource level (lab work)
I worked through an AWS Skill Builder lab on S3 resource-based policies, and it clarified how identity-based policies and resource-based policies interact.
The setup: My IAM user (devuser) had a group policy granting read access to a few services but no S3 object-level permissions. I could create a bucket, but not upload to or read from any existing one.
The twist: After assuming a role called BucketAccessRole, its own policy only granted access to bucket1. Yet I could also upload to bucket2 which its policy said nothing about. The answer wasn't in the role's policy at all; it was in bucket2's own bucket policy, which explicitly trusted BucketAccessRole and granted the PutObject Permission. AWS unions permissions from both sides access can come from the identity, the resource, or both, as long as nothing explicitly denies it.
The challenge: Uploading to bucket3 failed completely under BucketAccessRole, its bucket policy didn't trust that role at all. It trusted a different role, OtherBucketAccessRole. Switching to that role fixed it instantly, no permissions were missing, I just wasn't authenticated as the right principal for that resource.
Takeaway: AWS evaluates identity-based and resource-based policies together. Debugging "Access Denied" in S3 often isn't "check the user's policy" , it's checking whether the bucket trusts you as a principal, separate from what your own role grants.
Series: AWS Cloud Security (4 articles)
- 2Week 2: Securing Access to Cloud Resources: An IAM Deep Dive This article
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article