GCP service account key age audit failed: API error permission denied on project

TL;DR

Give the audit identity key read access project by project and report denials as their own finding, because a blanket failure hides which projects were actually audited. Use an identity with the service account key viewer capability at the folder level where policy allows, enumerate projects first, then read keys per project while logging successes and denials separately. Projects that deny access become an explicit unaudited list for the review, which is honest evidence, instead of a failed job with no results at all.

GCP service account key age audit failed: API error permission denied on project

Use this when

• The key age audit errors out on the first project it cannot read.
• Results exist for some projects but the report claims full coverage.
• New projects added to the folder are missing from key results.

Not for this skill when

• The audit reads keys fine but rotation is blocked. Follow the key rotation process instead.
• A project is intentionally isolated by a perimeter. Record it as a scoped exclusion with owner approval.

Steps

1. List the projects in the audit scope from the resource manager or asset inventory and save the list as the coverage baseline for this run. Verify: the baseline project count is recorded before collection starts.
2. Identify the audit identity and check its roles at the folder and on one failing project, noting where the service account read capability is missing. Verify: the missing grant level is identified for the failing project.
3. Grant the audit identity the least role that reads service accounts and their keys at the folder level if policy allows, otherwise script per project grants for the baseline list. Verify: the identity can read service accounts on a previously failing test project.
4. Change the audit to continue past a denied project, logging the project, the error and a coverage flag, instead of aborting the whole run. Verify: a test run with one denied project still returns results for the others.
5. Run the full audit and reconcile the projects read plus projects denied against the baseline count so coverage is provable. Verify: read plus denied equals the baseline with no silent gaps.
6. Work the denied list with project owners, either gaining the grant or documenting an approved exclusion for each, and rerun for those projects once resolved. Verify: every denied project is resolved or carries an approved exclusion.
7. File the key age findings and the coverage reconciliation together, so the review shows both the old keys found and the exact scope that was checked. Verify: the evidence contains findings and coverage in one place.

Why it happens

Key audits fail at fleet scale because project level grants drift: projects created outside the standard folder setup, or hardened by their owners, do not inherit the audit identity access. A job that aborts on the first denial produces nothing, while a job that silently skips produces a false clean bill. Splitting results into read and denied, and reconciling both against a project baseline, converts a fragile script into an audit with provable coverage, which is what reviewers and auditors actually need.

Variants and edge cases

service account key audit incomplete coverage projects

The coverage phrasing. Reconcile counts before debating individual key ages; unaudited projects are the bigger finding.

iam serviceAccounts list permission denied in audit

The permission phrasing using the API wording. The audit identity needs the read at the level of each project it inspects.

old service account keys report missing new projects

The drift phrasing. New projects join the scope list automatically only if enumeration is dynamic; refresh the baseline every run.

Edge cases to check before closing the review cycle:

• Key age can be read from asset inventory in some setups without per project calls. Compare approaches if grants are politically hard.
• User managed keys on service accounts used by vendors need owner outreach before any grant or rotation move.
• A denied project under a perimeter may need the audit run from inside the perimeter. Note the network requirement early.

Compatibility: Google Cloud IAM service accounts and keys, Cloud Asset Inventory, folder and project level role grants for audit identities.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_Ex-P6etW5liGlG9RW-64hA