Securing Artifact Repositories: IAM and AWS CodeArtifact

This guide covers the critical security configurations required to protect artifact repositories, including AWS CodeArtifact, Amazon ECR, and Amazon S3, focusing on the AWS Certified DevOps Engineer Professional exam requirements.

Learning Objectives

After studying this guide, you should be able to:

• Configure IAM policies for granular access to AWS CodeArtifact domains and repositories.
• Implement resource-based policies for Amazon ECR and S3 to enable cross-account artifact sharing.
• Automate the retrieval of authorization tokens for build tools like AWS CodeBuild.
• Apply the principle of least privilege to machine identities (IAM Roles) within CI/CD pipelines.

Key Terms & Glossary

• Domain (CodeArtifact): A container for repositories that allows for organizational-level management of packages and unified security policies.
• Upstream Repository: A repository in CodeArtifact that provides packages to another repository (the downstream repository).
• Authorization Token: A temporary credential (valid up to 12 hours) required by package managers (npm, pip, maven) to authenticate with CodeArtifact.
• Resource-Based Policy: A policy attached directly to a resource (like an S3 bucket or ECR repo) defining who can access it.
• Service-Linked Role: A unique type of IAM role that is linked directly to an AWS service to perform actions on your behalf.

The "Big Idea"

In a modern DevOps pipeline, the Artifact Repository is the "Single Source of Truth" for software dependencies and build outputs. If these repositories are compromised, an attacker can inject malicious code into the entire software supply chain. Securing these repositories involves a dual-layered approach: Identity-based security (Who is the user/service?) and Resource-based security (What is the repository allowed to do?). Coordination between IAM roles and repository-level policies ensures that only authorized build agents can publish or consume specific versions of software.

Formula / Concept Box

Hierarchical Outline

1. AWS CodeArtifact Security Architecture
   • Domain-Level Security: Centralized control for multiple repositories.
   • Repository-Level Security: Fine-grained access for specific teams/projects.
   • The Token Mechanism: Using sts:GetServiceBearerToken and codeartifact:GetAuthorizationToken.
2. IAM for Build Tools (CodeBuild & Lambda)
   • Service Roles: Providing the build environment with permissions to pull dependencies.
   • VPC Considerations: Accessing repositories from private subnets via VPC Endpoints.
3. Amazon ECR Permissions
   • Public vs. Private Repositories: Scoping permissions for global vs. internal use.
   • Lifecycle Policies: Automating the cleanup of old/insecure images to reduce attack surface.
4. Cross-Account Access Patterns
   • The Centralized Artifact Account: Managing a "Golden Image" or "Golden Package" account.
   • Trust Relationships: How to allow Account B (Production) to pull from Account A (Dev/Tools).

Visual Anchors

CodeArtifact Authentication Flow

IAM Role and Resource Interaction

Definition-Example Pairs

• Principle of Least Privilege: Granting only the specific permissions required to perform a task.
  • Example: A CodeBuild project used only for testing should have codeartifact:ReadFromRepository but NOT codeartifact:PublishPackage.
• Domain Policy: A resource-based policy applied to a CodeArtifact domain to manage access for all repositories within it.
  • Example: Applying a domain policy that allows an entire AWS Organization to read packages while restricting write access to the CI account.
• Implicit Deny: If a policy doesn't explicitly allow an action, it is forbidden.
  • Example: Even if an IAM user has AdministratorAccess, they cannot access an S3 bucket if a Service Control Policy (SCP) explicitly denies S3 access.

Worked Examples

Example 1: Configuring CodeBuild to access CodeArtifact

Scenario: You need to allow a CodeBuild project in Account A to fetch npm packages from a CodeArtifact repository in the same account.

Step 1: Update the CodeBuild IAM Role Attach the following policy to the service role used by CodeBuild:

Step 2: Update buildspec.yml In the pre_build phase, login to CodeArtifact:

Checkpoint Questions

1. How long is a CodeArtifact authorization token valid by default, and what is the maximum duration?
2. In a cross-account scenario, do you need to update the IAM policy of the requester, the Resource Policy of the repository, or both?
3. Which AWS service is required to generate the underlying bearer token for CodeArtifact authentication?
4. Why is sts:GetServiceBearerToken necessary in an IAM policy for CodeArtifact access?

▶Click to view answers

1. Default is 12 hours. The duration can be configured between 15 minutes and 12 hours.
2. Both. IAM identity policies must allow the action, and the resource-based policy must trust the external account.
3. AWS STS (Security Token Service).
4. CodeArtifact uses this specific STS action to exchange IAM credentials for a domain-scoped bearer token used by package managers.

Muddy Points & Cross-Refs

• Token vs. Role: Students often confuse the IAM Role with the Auth Token. The Role allows you to ask for the Token. The Token is what the package manager (npm/pip) actually uses.
• VPC Endpoints: If your build is running in a private VPC, ensure you have an Interface VPC Endpoint for CodeArtifact (and one for S3 if using S3) otherwise the get-authorization-token call will timeout.
• Cross-Account: Remember that for cross-account ECR access, the ECR policy must explicitly list the Principal of the other account.

Comparison Tables