Skip to main content

More Info:

Grant the clusters service account only read access to container image repositories, not write or admin. Read-only access limits the blast radius if node credentials are compromised.

Risk Level

Medium

Address

Security

Compliance Standards

  • CIS GKE

Triage and Remediation

Remediation

Manual Steps

  1. Identify which registries and service accounts your GKE nodes use
    • On any machine with gcloud access, list your node service accounts and note which ones pull images (often the default compute SA):
      If you use Workload Identity or custom node pools, also list any additional service accounts used to pull images.
  2. Review Artifact Registry (AR) IAM for node / puller service accounts
    • On any machine with gcloud access, for each Artifact Registry repository that stores images used by the cluster:
    • Confirm that any member matching your node or image-puller service accounts has at most roles/artifactregistry.reader.
    • If you find broader roles (for example, roles/artifactregistry.writer, roles/artifactregistry.admin, roles/owner, roles/editor), plan to replace them with roles/artifactregistry.reader before removal to avoid breaking image pulls.
  3. Review GCR (GCS bucket) IAM for explicitly granted accounts
    • On any machine with gsutil access, for each GCR bucket (commonly gs://artifacts.<project_id>.appspot.com or regional equivalents):
    • Inspect the output for entries granting your node or image-puller service accounts any of:
      • roles/storage.admin
      • roles/storage.objectAdmin
      • roles/storage.objectCreator
      • roles/storage.legacyBucketOwner
      • roles/storage.legacyBucketWriter
      • roles/storage.legacyObjectOwner
    • Ensure those accounts instead have only roles/storage.objectViewer (or are covered by a narrower custom read-only role, if used).
  4. Review project-level IAM that may grant indirect write/admin access to registries
    • On any machine with gcloud access, run:
    • Check whether any node or image-puller service accounts (or groups containing them) appear in the output. If so, they inherit write/admin rights to GCR buckets and must be removed or replaced with read-only roles at project level.
  5. Decide and apply least-privilege changes in console/CLI/IaC
    • For AR: for each affected service account, add roles/artifactregistry.reader at the repository (or minimally scoping level) and then remove any broader AR roles.
    • For GCR buckets: for each affected service account, add objectViewer using gsutil iam ch, then delete the excessive role entries (storage.admin, storage.objectAdmin, etc.) using gsutil iam ch -d.
    • For project-level IAM: update IAM bindings (via console or by editing your IAM policy / Terraform / other IaC) so that node/image-puller service accounts no longer have storage admin/write roles, while ensuring other workloads that legitimately push images retain required permissions.
  6. Verify the remediation and cluster functionality
    • Re-run the project-level audit to confirm no node or image-puller service accounts hold the listed storage write/admin roles:
    • Optionally, re-check AR and GCR bucket IAM as in steps 2–3, then deploy a test pod in the cluster that pulls an image from each registry to ensure image pulls still succeed with read-only access.
kubectl cannot be used to change container image repository IAM or project-level IAM; this finding is remediated in the Google Cloud console / gcloud CLI / IaC that manages Artifact Registry, GCR, and project IAM. Refer to the Manual Steps section for the exact gcloud and gsutil commands to adjust roles to read-only access.