Least privilege for Terraform service accounts - Step-by-Step Execution

Process Flow - Least privilege for Terraform service accounts

Create Service Account

↓

Assign Minimal Roles

↓

Use Service Account in Terraform

↓

Terraform Executes with Limited Permissions

↓

Verify No Excess Permissions

↓

Adjust Roles if Needed

↓

End

This flow shows creating a service account, giving it only the permissions it needs, using it in Terraform, and verifying it cannot do more than necessary.

Execution Sample

Terraform

resource "google_service_account" "tf_sa" {
  account_id   = "terraform-sa"
  display_name = "Terraform Service Account"
}

resource "google_project_iam_member" "tf_sa_storage" {
  project = var.project_id
  role    = "roles/storage.objectViewer"
  member  = "serviceAccount:${google_service_account.tf_sa.email}"
}

This Terraform code creates a service account and assigns it the minimal role to view storage objects.

Process Table

Step	Action	Resource Affected	Permissions Assigned	Result
1	Create service account	google_service_account.tf_sa	None initially	Service account created with ID terraform-sa
2	Assign IAM role	google_project_iam_member.tf_sa_storage	roles/storage.objectViewer	Service account can view storage objects only
3	Use service account in Terraform	Terraform execution	Limited to assigned roles	Terraform can read storage objects but cannot modify or delete
4	Attempt unauthorized action	Terraform execution	No extra permissions	Action denied due to lack of permissions
5	Verify permissions	IAM policy	Only assigned roles present	Least privilege enforced
6	Adjust roles if needed	IAM policy	Add or remove roles	Permissions updated to minimum required
7	End	-	-	Terraform runs with least privilege service account

💡 Terraform service account has only the minimal permissions assigned, enforcing least privilege.

Status Tracker

Variable	Start	After Step 1	After Step 2	After Step 6	Final
service_account	None	Created with ID terraform-sa	Exists with roles/storage.objectViewer	Roles adjusted if needed	Exists with minimal required roles
permissions	None	None	roles/storage.objectViewer	Updated if needed	Minimal permissions enforced

Key Moments - 3 Insights

Why do we assign only specific roles instead of full admin rights?

Assigning only specific roles limits what Terraform can do, preventing accidental or malicious changes. See execution_table step 2 and 4 where only storage.objectViewer is assigned and unauthorized actions are denied.

What happens if Terraform tries to perform an action not allowed by the service account?

Terraform will get an error and the action will be denied, as shown in execution_table step 4. This protects resources from unintended changes.

How do we update permissions if Terraform needs more access later?

We adjust the IAM roles assigned to the service account, as shown in execution_table step 6, adding only the minimum extra permissions needed.

Visual Quiz - 3 Questions

Look at the execution_table, what permission is assigned to the service account at step 2?

A roles/editor

B roles/storage.objectViewer

C roles/owner

D No permissions assigned

💡 Hint

Check the 'Permissions Assigned' column in execution_table row for step 2.

At which step does Terraform get denied when trying an unauthorized action?

A Step 3

B Step 5

C Step 4

D Step 6

💡 Hint

Look for the step mentioning 'Action denied' in the 'Result' column.

If we add roles/editor to the service account, which step would reflect this change?

A Step 6

B Step 2

C Step 4

D Step 7

💡 Hint

Check the step about adjusting roles in the execution_table.

Concept Snapshot

Least privilege means giving Terraform service accounts only the permissions they need.
Create a service account.
Assign minimal IAM roles (e.g., storage.objectViewer).
Use this account in Terraform runs.
Verify unauthorized actions are denied.
Adjust roles only when necessary.

Full Transcript

This lesson shows how to apply least privilege to Terraform service accounts. First, create a service account. Then assign it only the minimal roles it needs, such as storage.objectViewer. Use this account in Terraform executions. If Terraform tries to do something outside its permissions, it will be denied. You can adjust the roles later if Terraform needs more access. This approach protects your cloud resources by limiting what Terraform can do.

Practice

1. What does the principle of least privilege mean for Terraform service accounts?

easy

A. Give only the permissions Terraform needs to do its job

B. Give Terraform full admin access to all cloud resources

C. Allow Terraform to access resources only during business hours

D. Share Terraform service account credentials with all team members

Solution

1. Step 1: Understand least privilege concept

   Least privilege means giving only the minimum permissions needed to perform a task.

2. Step 2: Apply to Terraform service accounts

   Terraform service accounts should have only the permissions required to manage infrastructure, nothing more.

3. Final Answer:

   Give only the permissions Terraform needs to do its job -> Option A

4. Quick Check:

   Least privilege = minimal needed permissions [OK]

Hint: Least privilege means minimal permissions only [OK]

Common Mistakes:

• Giving Terraform full admin rights unnecessarily
• Sharing credentials widely
• Setting time-based access without need

2. Which Terraform configuration snippet correctly assigns least privilege to a service account for managing only compute instances?

easy

A. resource "google_project_iam_member" "compute_admin" {
project = var.project_id
role = "roles/compute.admin"
member = "serviceAccount:${var.service_account_email}"
}

B. resource "google_project_iam_member" "storage_admin" {
project = var.project_id
role = "roles/storage.admin"
member = "serviceAccount:${var.service_account_email}"
}

C. resource "google_project_iam_member" "viewer" {
project = var.project_id
role = "roles/viewer"
member = "serviceAccount:${var.service_account_email}"
}

D. resource "google_project_iam_member" "editor" {
project = var.project_id
role = "roles/editor"
member = "serviceAccount:${var.service_account_email}"
}

Solution

1. Step 1: Identify the role for compute instance management

   The role "roles/compute.admin" allows managing compute instances specifically.

2. Step 2: Match the role to the service account in Terraform

   The snippet assigns "roles/compute.admin" to the service account, limiting permissions to compute resources only.

3. Final Answer:

   The snippet assigning roles/compute.admin to the service account -> Option A

4. Quick Check:

   Assign specific roles, not broad ones [OK]

Hint: Match role to exact resource type needed [OK]

Common Mistakes:

• Using broad roles like editor or admin unnecessarily
• Assigning unrelated roles like storage.admin
• Using viewer role which is read-only

3. Given this Terraform IAM binding snippet, what is the effective permission scope for the service account?

resource "google_project_iam_member" "sa_role" {
  project = "my-project"
  role    = "roles/storage.objectViewer"
  member  = "serviceAccount:[e-mail]"
}

medium

A. Full access to all storage buckets and objects

B. No access to storage resources

C. Write access to storage buckets

D. Read-only access to storage objects only

Solution

1. Step 1: Understand the role assigned

   The role "roles/storage.objectViewer" grants read-only access to storage objects.

2. Step 2: Determine permission scope

   This role does not allow writing or bucket management, only viewing objects.

3. Final Answer:

   Read-only access to storage objects only -> Option D

4. Quick Check:

   roles/storage.objectViewer = read-only object access [OK]

Hint: Check role name keywords: viewer means read-only [OK]

Common Mistakes:

• Confusing viewer with admin or editor roles
• Assuming bucket write permissions
• Thinking full storage access is granted

4. You wrote this Terraform code to assign a role to a service account but get an error:

resource "google_project_iam_member" "sa_role" {
  project = var.project_id
  role    = "roles/compute.viewer"
  member  = "serviceAccount:${var.service_account_email}"
  member  = "serviceAccount:[e-mail]"
}

What is the problem?

medium

A. Role 'roles/compute.viewer' does not exist

B. Duplicate 'member' keys cause a syntax error

C. Service account email format is invalid

D. Project ID variable is missing

Solution

1. Step 1: Check Terraform resource syntax

   Terraform resource blocks cannot have duplicate keys; 'member' is repeated twice here.

2. Step 2: Understand correct way to assign multiple members

   To assign multiple members, use 'google_project_iam_binding' or multiple resources, not duplicate keys.

3. Final Answer:

   Duplicate 'member' keys cause a syntax error -> Option B

4. Quick Check:

   Duplicate keys in resource block = syntax error [OK]

Hint: No duplicate keys in Terraform blocks [OK]

Common Mistakes:

• Using duplicate keys instead of lists or multiple resources
• Assuming role name is invalid without checking
• Ignoring variable definitions

5. You want to create a Terraform service account with least privilege to manage only network resources in a Google Cloud project. Which approach is best?

hard

A. Assign the role 'roles/owner' to the service account temporarily

B. Assign the role 'roles/editor' to the service account for all resources

C. Assign the role 'roles/compute.networkAdmin' to the service account only

D. Assign no roles and rely on default permissions

Solution

1. Step 1: Identify the role for network management

   The role 'roles/compute.networkAdmin' grants permissions to manage network resources only.

2. Step 2: Apply least privilege principle

   Assigning only this role limits the service account to network tasks, avoiding broad permissions.

3. Step 3: Avoid broad or no permissions

   Roles like 'editor' or 'owner' are too broad; no roles means no access.

4. Final Answer:

   Assign the role 'roles/compute.networkAdmin' to the service account only -> Option C

5. Quick Check:

   Least privilege = specific role only [OK]

Hint: Pick the narrowest role matching needed tasks [OK]

Common Mistakes:

• Using broad roles like editor or owner
• Not assigning any role and expecting access
• Assigning multiple unrelated roles