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
MediumAddress
SecurityCompliance Standards
- CIS GKE
Triage and Remediation
- Remediation
Remediation
Manual Steps
Manual Steps
-
Identify which registries and service accounts your GKE nodes use
- On any machine with
gcloudaccess, 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.
- On any machine with
-
Review Artifact Registry (AR) IAM for node / puller service accounts
- On any machine with
gcloudaccess, 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 withroles/artifactregistry.readerbefore removal to avoid breaking image pulls.
- On any machine with
-
Review GCR (GCS bucket) IAM for explicitly granted accounts
- On any machine with
gsutilaccess, for each GCR bucket (commonlygs://artifacts.<project_id>.appspot.comor regional equivalents): - Inspect the output for entries granting your node or image-puller service accounts any of:
roles/storage.adminroles/storage.objectAdminroles/storage.objectCreatorroles/storage.legacyBucketOwnerroles/storage.legacyBucketWriterroles/storage.legacyObjectOwner
- Ensure those accounts instead have only
roles/storage.objectViewer(or are covered by a narrower custom read-only role, if used).
- On any machine with
-
Review project-level IAM that may grant indirect write/admin access to registries
- On any machine with
gcloudaccess, 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.
- On any machine with
-
Decide and apply least-privilege changes in console/CLI/IaC
- For AR: for each affected service account, add
roles/artifactregistry.readerat the repository (or minimally scoping level) and then remove any broader AR roles. - For GCR buckets: for each affected service account, add
objectViewerusinggsutil iam ch, then delete the excessive role entries (storage.admin,storage.objectAdmin, etc.) usinggsutil 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.
- For AR: for each affected service account, add
-
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.
- Re-run the project-level audit to confirm no node or image-puller service accounts hold the listed storage write/admin roles:
Using kubectl
Using kubectl
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.Automation
Automation

