IAM-Least Privilege Principle

April 20, 2026

Use least privilege principle to secure your CI/CD pipeline

IAM Permissions && Access Control
Prompt–The Over-Permissioned Pipeline Disaster-Real Security Risk:

Developer sets up CodeBuild,gets “Access Denied” errors	Frustrated,they attackAdministratorAccess policy to fix it quickly	Pipeline works!Problems solved…or is it?
CodeBuild now has full access to delete databases,modify IAM,access all s3 bucket	Attacker compromises the build through malicious code in dependencies	Now attacker has admin access to your entire AWS account

The Principle of Least Privilege - Only What’s needed,Nothing More.

Least Privilege = Grant minimum permissions required to do the job

CodeBuild needs to read one S3 bucket?Grant exactly that,not all S3 buckets
CodeDeploy nedds to update EC2 instances?Grant only deployment permission

Dont’t grant

Full S3 access
EC2 admin
IAM modification

Think: What’s the smallest set of permissions for this to work?

Benefits: Limits blast radius if compromised

Building Secure IAM Policies for Pipeline Services

IAM Policy = JSON document with permissions
Structure: Effect( Allow/Deny ),Action(what),Resource(where)
Example secure policy for .tf document


resource "aws_iam_policy" "codebuild_policy" {
  name        = "CodeBuildMinimalPolicy"
  description = "SRE 级最小权限策略"

  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Effect   = "Allow"
        Action   = ["s3:GetObject"]
        Resource = "arn:aws:s3:::my-app-source/*"
      },
      {
        Effect   = "Allow"
        Action   = [
          "logs:CreateLogGroup",
          "logs:CreateLogStream",
          "logs:PutLogEvents"
        ]
        Resource = "arn:aws:logs:us-east-1:123456789:log-group:/aws/codebuild/*"
      }
    ]
  })
}

Common IAM Security Mistatakes in CI/CD - Avoid These:

Mistake 1: Using * wildcard for everything(full access)

Mistake 2: Attaching AWS managed PowerUserAccess or AdministratorAccess

Mistake 3: Hardcoding AWS access keys in code or environment variables

Mistake 4: Using the same IAM role for dev,staging,and production

Mistake 5: Never reviewing ro rotating credentials 

Mistake 6: Granting iam.* permissions(ability to create admin users)

Mistake 7: Not using MFA for human users accessing pipelines

# Each mistake creates a path for attackers!!!

Identity Federation(身份联邦): 拒绝 IAM User，拥抱OIDC。让 GITHub Actions 通过短期的临时 Token 直接与 AWS 握手，实现No-Key CI/CD。
Infrastructure as Code（Iac）Guardrails：所有的IAM Policy必须经过 Terraform 编写，并在 CI 阶段通过 Checkov / Terrascan 自动扫描。如果检测到 Effect：Allow，Action：*，流水线自动阻断并报错
Boundary & Guardrail（权限边界）：利用AWS Organization的Service Control Policies（SCPs），在账号级别全局禁止删除核心资源（如核心RDS、S3审计日志），无论你IAM怎么写都逃不出这个紧箍咒。

Auditing and Monitoring IAM Activity - Catch Suspicious Behavior

AWS CloudTrail logs every IAM action

Who assumed which role?When?From where?
Set up alerts for suspicious activities
IAM policy modifications
Unusual assume role attempts
Access from unexpected IP addresses
Actions performed outside business hours

Best Practices

Review CloudTrail logs regularly
Use AWS IAM Access Analyzer to find overly permissive policies
principle: Trust but verify - even your own pipeline

Bash Scripting Documetry Docker