Securing AWS ML Resources: IAM Roles, Policies, and Groups

This study guide covers the foundational components of AWS Identity and Access Management (IAM) as applied to Machine Learning workloads. It details how to manage identities, define permissions through policies, and utilize purpose-built tools like SageMaker Role Manager to enforce the Principle of Least Privilege.

Learning Objectives

• Differentiate between IAM Users, Groups, and Roles.
• Explain the components of an IAM JSON policy (Effect, Action, Resource, Condition).
• Identify who or what can assume an IAM Role using AWS Security Token Service (STS).
• Apply the Principle of Least Privilege to ML personas using SageMaker Role Manager.
• Compare identity-based policies with resource-based policies (e.g., S3 Bucket Policies).

Key Terms & Glossary

• Principal: An entity (user or role) that is allowed to make a request for an action or operation on an AWS resource.
• IAM Role: An identity with specific permissions that is intended to be assumed by anyone/anything that needs it (not uniquely associated with one person).
• STS (Security Token Service): A web service that enables you to request temporary, limited-privilege credentials for users.
• IAM Group: A collection of IAM users. Permissions granted to a group are inherited by all users within that group.
• Implicit Deny: The default state where all requests are denied unless an explicit "Allow" policy exists.

The "Big Idea"

In the context of Machine Learning, security is a Shared Responsibility. While AWS secures the underlying infrastructure, you are responsible for "Security IN the Cloud." IAM is the gatekeeper. By effectively using Roles and Groups, you ensure that Data Scientists can experiment, MLOps engineers can deploy, and automated pipelines can execute—all without ever granting more access than is strictly necessary. This prevents accidental data leaks or unauthorized resource consumption.

Formula / Concept Box

Anatomy of a Policy Statement

All IAM policies are JSON documents containing one or more statements with these four primary elements:

Hierarchical Outline

1. Identity Management
   • IAM Users: Long-term credentials for individuals.
   • IAM Groups: Permission inheritance (e.g., "ML-Trainers" group) for easier management.
   • IAM Roles: Use STS for temporary credentials; used by services (Lambda, SageMaker) or cross-account users.
2. Authorization Mechanics
   • Identity-based Policies: Attached to users/roles/groups.
   • Resource-based Policies: Attached to resources (e.g., S3 Bucket Policies).
   • Evaluation Logic: Explicit Deny > Explicit Allow > Default Deny.
3. ML-Specific Access Tools
   • SageMaker Role Manager: Predefined Personas (Data Scientist, MLOps, Compute).
   • SageMaker ML Activities: Bundled permissions for specific tasks (e.g., data preparation).
4. Security Best Practices
   • Principle of Least Privilege: Grant only the minimum access required.
   • MFA: Require multi-factor authentication for sensitive actions.
   • Auditing: Use CloudTrail to monitor who assumed which role.

Visual Anchors

IAM Authorization Flow

This flowchart illustrates how AWS evaluates a request from a principal.

The Principle of Least Privilege

This TikZ diagram represents the intersection of total available permissions versus those granted to a specific ML persona.

\begin{tikzpicture} \draw[thick, fill=gray!20] (0,0) circle (2.5cm) node[below=1.8cm] {Total AWS Permissions}; \draw[thick, fill=blue!30, opacity=0.7] (0.5,0.5) circle (1.2cm); \node at (0.5,0.8) {\textbf{Required Access}}; \node[scale=0.8] at (0.5,0.3) {(e.g., SageMaker Training)}; \draw[<-, thick] (1.5,1.2) -- (3,2) node[right] {\textbf{Least Privilege Goal}}; \end{tikzpicture}

Definition-Example Pairs

• IAM Group (Definition): A container for users to simplify permission management.
  • Example: Creating a DataScience-Team group with AmazonSageMakerFullAccess so new hires automatically get the tools they need by being added to the group.
• Trust Policy (Definition): A document attached to an IAM Role that defines which principals are allowed to assume that role.
  • Example: A SageMaker Execution Role has a trust policy allowing the service sagemaker.amazonaws.com to assume it.
• Resource-based Policy (Definition): A policy attached directly to a resource, defining who can access it.
  • Example: An S3 Bucket Policy that allows a specific SageMaker Role from a different account to read training data.

Worked Examples

Scenario: Configuring a Training Job

Problem: A Data Scientist needs to run a SageMaker training job that reads data from S3 and writes a model artifact back to S3. They currently have no permissions.

Solution Steps:

1. Create an IAM Role: Create a role specifically for SageMaker execution (e.g., SageMaker-Execution-Role).
2. Attach Identity Policy: Attach a JSON policy to this role that allows s3:GetObject on the data bucket and s3:PutObject on the artifact bucket.
3. Configure Trust Relationship: Ensure the role's Trust Policy allows the sagemaker.amazonaws.com service principal to assume the role.
4. Pass the Role: When the Data Scientist calls CreateTrainingJob, they provide the ARN of this role.

[!TIP] Use SageMaker Role Manager to generate this role based on the "Data Scientist" persona to save time and reduce manual JSON errors.

Checkpoint Questions

1. Can an IAM Group be listed as a "Principal" in a resource-based policy? Why or why not?
2. What AWS service is used to generate temporary credentials when an IAM Role is assumed?
3. If a user has an "Allow" in their identity policy but the S3 bucket they are accessing has an "Explicit Deny" for that user, is the request allowed or denied?
4. What is the main benefit of using SageMaker Role Manager over manually creating IAM roles?

▶Click to see answers

1. No. Groups are used for permission management, not authentication. Only individual users or roles (Principals) can be authenticated.
2. AWS STS (Security Token Service).
3. Denied. An explicit deny always overrides an explicit allow.
4. It provides predefined personas and ML activities, ensuring best-practice permissions are applied automatically without requiring deep IAM expertise.

Muddy Points & Cross-Refs

• Role vs. User: Remember: Users are for people (long-term); Roles are for applications, services, or temporary access (short-term).
• Identity-based vs. Resource-based: Identity policies are "What can I do?" while Resource-based policies are "Who can do things to me?"
• Cross-Reference: For auditing these permissions, see the study guide for AWS CloudTrail and IAM Access Analyzer.

Comparison Tables

IAM Entities Comparison