Phase1 Cloud Iac

IAM Roles & Service Accounts

Introduction

IAM Users are for humans. IAM Roles are for services and applications. When your CI/CD pipeline runs, when your EC2 instance needs to read from S3, when your Lambda function needs to write to DynamoDB — none of these should use long-lived access keys. They should assume roles.

Why This Matters

Access keys are like passwords that never expire. If they leak (in a git commit, in logs, anywhere), attackers can use them until you notice and rotate them. Roles are different: they provide temporary credentials that automatically expire and rotate. When an EC2 instance assumes a role, it gets credentials that last minutes to hours, not forever. In MLOps specifically: - Training jobs need to read data from S3 and write models back - Inference services need to load models and maybe access feature stores - CI/CD needs to deploy containers and update services All of these should use roles, not access keys. Understanding roles is what separates "it works on my laptop" from "it works in production securely."

Tasks

Read about the difference between IAM Users and IAM Roles in AWS docs

Hint: Focus on: who/what can assume a role, and how credentials work

Create an IAM Role called 'S3ReadOnlyRole' with S3 read permissions

Look at the role's Trust Policy — understand who can assume this role

Modify the trust policy to allow EC2 instances to assume the role

Launch a small EC2 instance with this role attached (t2.micro, free tier)

SSH into the instance and run 'aws s3 ls' — observe it works without configuring credentials

Try to create a bucket from the instance — observe permission denied

Terminate the EC2 instance (cleanup)

Examine where the temporary credentials come from (instance metadata service)

Hint: curl http://169.254.169.254/latest/meta-data/iam/security-credentials/

Check Understanding

AI Assistant

test

Looks like you're testing the connection! That's working great. To jump back into our IAM roles lesson, let's build on what you already know about IAM users: You learned that IAM users have permanent, long-lived credentials (passwords, access keys) that don't expire unless you manually rotate or delete them. Quick warm-up question to connect this to MLOps: If you were running a distributed PyTorch training job on a fleet of EC2 instances, what's the biggest security risk of attaching an IAM user's permanent access key directly to those instances?

test

All good on the connection front! If that "test" was just a quick check, we're all set to keep going with IAM roles. If you meant to answer the warm-up question about the risks of permanent access keys on EC2 for PyTorch training jobs, feel free to share your thoughts—we can walk through those risks together before diving into how IAM roles solve exactly this problem. Either way, let me know what you'd like to focus on next!

test

Connection's working perfectly! 😊 If you're just testing the chat, we're all set to pick up right where we left off with IAM roles for MLOps. If you had a question about the earlier warm-up (risks of permanent access keys on EC2 training instances) or want to jump straight into creating your first IAM role for, say, a SageMaker training job, just let me know—I'm ready to walk through it step by step with you.

No worries at all! Just to recap where we left off in the IAM roles lesson: We were talking about the big security risk of using *permanent IAM user access keys* on EC2 instances running distributed PyTorch training jobs, before diving into how IAM roles fix that problem with temporary, auto-rotated credentials. If you're ready to dive in, we can either: 1. First walk through the risks of those permanent keys together (to build the case for why roles exist), or 2. Jump straight into hands-on: creating your first IAM role for an MLOps service like SageMaker, modifying its trust policy, and seeing how it auto-provisions credentials to the training job. What sounds more useful to you right now?

In one sentence: what is a trust policy?

A trust policy is a JSON policy attached exclusively to an IAM role that defines exactly which AWS principals (such as IAM users, EC2 instances, SageMaker training jobs, or other AWS services) are permitted to assume (temporarily adopt the permissions of) that role, serving as the gatekeeper that controls which identities are allowed to use the role at all.

explain Try to create a bucket from the instance — observe permission denied

explain the bucket permission denied task

explain: Try to create a bucket from the instance — observe permission denied

This is a foundational hands-on task to demonstrate the exact problem IAM roles solve for AWS services like EC2, and it works like this: 1. First, you launch a test EC2 instance (this could represent a PyTorch training node, a deployment host, or any MLOps compute resource) *without attaching an IAM role to it*. 2. You SSH into the instance, then run an AWS CLI command to create a new S3 bucket (e.g. `aws s3 mb s3://my-mlops-test-bucket-unique-id`). 3. You will see an `AccessDenied` error from S3. --- ### Why you get this error (building on what you already know about IAM users/policies): You already know IAM users need valid credentials (access key/secret key) and attached permissions policies to call AWS APIs like S3. EC2 instances have no built-in IAM user credentials by default, so when the instance tries to call the S3 CreateBucket API, it has no way to prove its identity to AWS, and S3 rejects the request as unauthenticated. If you *did* attach an IAM role to the instance but forgot to add `s3:CreateBucket` to the role's permissions policy, you'd also get an AccessDenied error: the instance can authenticate as the role, but S3 sees the role has no permission to create buckets, so it blocks the request. --- ### What this task teaches: This is the exact problem IAM roles are built to fix, without the security risks of the old workaround (hardcoding an IAM user's permanent access key/secret key onto the instance, which is long-lived, easy to steal if the instance is compromised, and requires manual rotation). - The fix for this task is to create an IAM role with two key parts: 1. A trust policy that explicitly allows the EC2 service to assume (use) the role (the concept you asked about earlier!) 2. A permissions policy that grants the `s3:CreateBucket` (and any other needed S3) actions - When you attach this role to the EC2 instance, the instance automatically fetches temporary, auto-rotated credentials via the EC2 Instance Metadata Service (IMDS) with no manual configuration. Running the same `aws s3 mb` command will now work, and the credentials will expire automatically after a few hours, with no manual rotation needed. For MLOps context: If this EC2 instance was running a training job that saves model checkpoints to S3, you'd grant the role only the exact S3 permissions it needs (e.g. `s3:PutObject` for your specific checkpoint bucket, not full S3 admin access) to follow the principle of least privilege.

"Read about the difference between IAM Users and IAM Roles in AWS docs" give me some useful links

Here are official, targeted AWS docs links tailored to your IAM roles + MLOps learning path, with notes on what to focus on for each: 1. **[Official IAM Users vs IAM Roles Comparison](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_compare.html)** This is the exact page you’re looking for: it breaks down core differences (long-lived permanent credentials for users vs auto-expiring temporary credentials for roles), use cases for each, and security benefits of roles. Focus on the comparison table and the "When to use IAM roles" section to connect directly to what you’re learning about service access and risk reduction for MLOps workloads. 2. **[IAM Roles for Amazon EC2](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-ec2.html)** This ties directly to your hands-on task of trying to create an S3 bucket from an EC2 instance. It explains instance profiles, the EC2 Instance Metadata Service (IMDS) that auto-provisions temporary credentials to instances, and how to configure roles for EC2-based MLOps workloads like PyTorch training nodes. 3. **[SageMaker Execution Roles (MLOps-specific)](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-roles.html)** Since you’re learning IAM roles for MLOps, this page explains how roles are used for common SageMaker workloads (training jobs, processing jobs, model endpoints) — exactly the real-world use case you’ll encounter when building ML pipelines. 4. **[Temporary Security Credentials Overview](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html)** This deep-dives into the core security benefit of roles: how temporary credentials work, auto-rotation, expiration, and why they eliminate the risk of leaked permanent credentials that comes with hardcoding IAM user access keys to services. If you want to dive deeper into the trust policy concept you asked about earlier, the first link has a full dedicated section on how trust policies gate access to roles.