IAM and Least Privilege

IAM is where Terraform most often grants too much, because a broad policy makes the AccessDenied go away and a tight one takes thought. Managing roles, policies, and instance profiles as code cuts both ways: the same config that enforces least privilege across an estate can, with a single "*", hand out admin on every account at once.

The core skill is building policy documents correctly. A policy is JSON, but you should never type that JSON as a string — one stray quote or a botched interpolation produces an invalid document AWS rejects at apply, or worse, a valid document that grants something you didn't mean. Build it with the aws_iam_policy_document data source or jsonencode, and the structure is checked for you.

Roles, Policies, and Instance Profiles

Three resources do the work. An aws_iam_role is an identity something can assume; an aws_iam_policy is a permission document; an aws_iam_role_policy_attachment binds the two. For an EC2 instance there's a fourth piece — an aws_iam_instance_profile, the wrapper that lets a launch template hand a role to an instance. Miss the instance profile and the role exists but never reaches the instance.

Building Policy Documents

The aws_iam_policy_document data source builds the JSON from HCL blocks, so the document is syntactically valid by construction and references resolve to real ARNs. Each statement names the actions and the specific resources they apply to. The example below grants read access to one bucket and nothing else — note the resources are concrete ARNs, not "*".

data "aws_iam_policy_document" "app_s3_read" {
  statement {
    sid     = "ReadAppBucket"
    actions = ["s3:GetObject", "s3:ListBucket"]
    resources = [
      aws_s3_bucket.app.arn,
      "${aws_s3_bucket.app.arn}/*",
    ]
  }
}

resource "aws_iam_policy" "app_s3_read" {
  name   = "app-s3-read"
  policy = data.aws_iam_policy_document.app_s3_read.json
}

ListBucket applies to the bucket ARN itself while GetObject applies to the objects under it (/*) — two different resource shapes the document gets right. If you prefer, jsonencode on an HCL object produces the same valid JSON; what matters is that the structure is generated, never hand-concatenated.

Least Privilege in Practice

Least privilege is the discipline of scoping every statement to specific actions and specific resource ARNs instead of reaching for "*". The difference is concrete: Action = "s3:*" on Resource = "*" lets a compromised web instance read, overwrite, and delete every bucket in the account; the scoped version above lets it read exactly one. Treat every "*" in a committed policy as a finding that has to be justified in review, not a default.

Assume-Role Trust Policies

A role has two policies pulling in opposite directions: the permission policy says what the role can do, and the trust policy (assume_role_policy) says who is allowed to become it. Forget the trust policy and you get AccessDenied when the service tries to assume the role — the permissions are irrelevant if nothing can assume it. The trust document is built the same way, with a principals block naming the EC2 service or, for cross-account access, a specific account or role ARN.

data "aws_iam_policy_document" "ec2_assume" {
  statement {
    actions = ["sts:AssumeRole"]
    principals {
      type        = "Service"
      identifiers = ["ec2.amazonaws.com"]
    }
  }
}

resource "aws_iam_role" "web" {
  name               = "web-instance-role"
  assume_role_policy = data.aws_iam_policy_document.ec2_assume.json
}

resource "aws_iam_role_policy_attachment" "web_s3" {
  role       = aws_iam_role.web.name
  policy_arn = aws_iam_policy.app_s3_read.arn
}

resource "aws_iam_instance_profile" "web" {
  name = "web-instance-profile"
  role = aws_iam_role.web.name
}

The instance profile is what the launch template's iam_instance_profile in the previous topic pointed at — this is the resource that closes that loop. Because the attachment references the role by name and the policy by ARN, Terraform orders them correctly: role, then policy, then attachment, then profile.

Managed vs Inline Policies

AWS-managed policies are convenient and a frequent trap: attaching AmazonS3FullAccess to grant one bucket's worth of reads hands out the whole service. Customer-managed policies like the one above are the right default for anything sensitive — they say exactly what's granted and they live in your code and review. Reach for an AWS-managed policy only when its scope genuinely matches the need; otherwise write the narrow one.