AVD-GCP-0011: False positive for role assignments to service account or group

[manuelbernhardt]

IDs

AVD-GCP-0011

Description

The following role assignment (non-authorative, as doing otherwise would interfere with other IAM bindings) is detected as one that gives users access to service account impersonation:

resource "google_project_iam_member" "github_wif_permissions" {
 for_each = toset([
   "artifactregistry.writer",
   "secretmanager.secretAccessor",
   "secretmanager.viewer",
   "run.admin",
   "iam.serviceAccountUser",
   "cloudsql.client",
   "compute.viewer"
 ])

 project = var.gcp_project_id
 role    = "roles/${each.value}"
 member  = "serviceAccount:${google_service_account.github_wif.email}"
}

resource "google_service_account" "github_wif" {
 account_id   = "github-wif-${var.environment}"
 display_name = "GitHub Actions WIF Service Account (${var.environment})"
 description  = "Service account for GitHub Actions using Workload Identity Federation"
}

However, the assignment is itself done for a serviceAccount: (see the member), not a user.

The same issue happens when assigning a group: rather than a user:.

Reproduction Steps

1. Scan the configuration given in the example

Target

Filesystem

Scanner

Misconfiguration

Target OS

No response

Debug Output

AVD-GCP-0011 (MEDIUM): Service account access is granted to a user at project level.
═════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════
Users with service account access at project level can impersonate any service account. Instead, they should be given access to particular service accounts as required.


See https://avd.aquasec.com/misconfig/avd-gcp-0011
─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
 modules/iam/github.tf:84
   via modules/iam/github.tf:72-86 (google_project_iam_member.github_wif_permissions["iam.serviceAccountUser"])
    via staging/iam.tf:1-80 (module.iam)
─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
  72   resource "google_project_iam_member" "github_wif_permissions" {
  ..
  84 [   role    = "roles/${each.value}"
  ..
  86   }
─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────

Version

Version: 0.66.0
Vulnerability DB:
  Version: 2
  UpdatedAt: 2025-09-09 12:33:28.251478274 +0000 UTC
  NextUpdate: 2025-09-10 12:33:28.251477873 +0000 UTC
  DownloadedAt: 2025-09-09 13:27:25.048837 +0000 UTC
Check Bundle:
  Digest: sha256:a471e90b7c7335e914ec9075b74cf8f65e4c91e6cecfa7e39c587382808d2684
  DownloadedAt: 2025-09-11 13:16:51.753758 +0000 UTC

Checklist

• Read the documentation regarding wrong detection
• Ran Trivy with -f json that shows data sources and confirmed that the security advisory in data sources was correct

[nikpivkin]

Hi @manuelbernhardt !

Yes, in this case the role is assigned to a service account rather than a human user, but the underlying risk is the same: the assigned service account can impersonate any service account in the project.

The same principle applies when assigning the role to a group instead of a user: — any member of that group (or any service account within it) would inherit the ability to impersonate all service accounts at the project level.

The key point is that project-level iam.serviceAccountUser grants overly broad impersonation rights, regardless of whether the member is a user, service account, or group.

We should improve the messages for certain checks related to service account access to avoid causing confusion.

[nikpivkin]

I opened a PR aquasecurity/trivy-checks#480