Scope inspiration:**

gcp_info_accounts_secrets.sh, gcp_iam_roles_granted_too_widely.sh, gcp_iam_roles_granted_to_identity.sh, gcp_secret_get.sh.

This series follows the repo’s GCP inventory flow so every step builds a repeatable, audit-friendly picture of your environment. Part 3 focuses on the access layer: who can act in the project and where sensitive material is stored.

---

What this script does (walkthrough)

The IAM and Secrets step combines account enumeration with targeted IAM checks and Secrets Manager visibility.

1. List service accounts to establish machine identity coverage.
2. Scan IAM grants for the broadest exposure patterns (roles granted to

   allAuthenticatedUsers

   and

   allUsers

   ).
3. List Secrets Manager secrets when the API is enabled, giving you a high-level map of secret assets.
4. Optionally retrieve the latest secret value with

   gcp_secret_get.sh

   when you need to validate access paths.

---

Operational caveats and gotchas

• gcp_info_accounts_secrets.sh

  will skip Secrets Manager if the API isn’t enabled, so plan to enable it or accept a partial inventory.
• The IAM exposure scan is intentionally narrow — it calls out roles granted to broad groups so you can triage risky access quickly.

• gcp_secret_get.sh

  fetches the latest enabled secret version; if you need historical versions, you’ll want to adjust the

  gcloud secrets versions

  filter.

---

Example command usage

# IAM + secrets inventory for the active project
gcp/gcp_info_accounts_secrets.sh

# Explicitly scan for overly broad IAM grants
# (the script checks allAuthenticatedUsers and allUsers)
gcp/gcp_iam_roles_granted_too_widely.sh

# Retrieve the most recent enabled version of a secret
gcp/gcp_secret_get.sh my-secret-name