IAM for ML Workloads Advanced
ML workloads require access to compute, storage, container registries, and ML services. Implementing least-privilege IAM policies for these cross-service workflows is challenging but essential. This lesson provides practical IAM patterns for common ML scenarios on AWS.
Key IAM Roles for ML
| Role | Used By | Key Permissions |
|---|---|---|
| SageMaker Execution | Training jobs, endpoints | S3 read/write, ECR pull, CloudWatch write |
| EC2 Training Instance | Self-managed training | S3 read, ECR pull, EFA access |
| Data Scientist | Human users | SageMaker full, S3 scoped, notebook access |
| ML Pipeline | Step Functions/Airflow | SageMaker create/describe, S3, Lambda invoke |
Least-Privilege SageMaker Execution Role
JSON
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": ["s3:GetObject", "s3:PutObject", "s3:ListBucket"],
"Resource": [
"arn:aws:s3:::ml-data-lake-*",
"arn:aws:s3:::ml-artifacts-*"
]
},
{
"Effect": "Allow",
"Action": ["ecr:GetDownloadUrlForLayer", "ecr:BatchGetImage"],
"Resource": "arn:aws:ecr:*:*:repository/ml-*"
},
{
"Effect": "Allow",
"Action": ["logs:CreateLogStream", "logs:PutLogEvents"],
"Resource": "arn:aws:logs:*:*:log-group:/aws/sagemaker/*"
}
]
}
Permission Boundaries
Use permission boundaries to cap the maximum permissions that ML roles can have, even if a data scientist creates their own roles:
- Prevent launching instances larger than allowed (cost control)
- Restrict regions to approved locations only
- Block access to sensitive S3 buckets outside the ML domain
- Prevent IAM escalation by limiting role creation permissions
Security Principle: Never attach the AmazonSageMakerFullAccess managed policy to production roles. It grants far more access than needed. Always create custom policies scoped to specific resources.
Ready for Best Practices?
The final lesson covers AWS Well-Architected ML practices and operational excellence.
Next: Best Practices →
Lilly Tech Systems