GCP ACE: Security Posture, Compliance, and Preventative Controls in GKE
Earlier articles covered individual security mechanisms — RBAC, Workload Identity, mTLS, AuthorizationPolicy. This one covers the layer that watches across all of that continuously and tells you where you’re actually exposed: the GKE security posture dashboard.
The security posture dashboard
The dashboard gives “opinionated, actionable recommendations” to improve a cluster’s or fleet’s security — not just raw scan output, but a prioritized list of what to fix first. It’s organized into three views:
| Tab | What it shows |
|---|---|
| Dashboard | High-level charts and scan-result summaries |
| Concerns | A filterable list of specific issues, each with affected resources and, where available, a recommended fix |
| Settings | Per-cluster or fleet-level toggles for which posture features are enabled |
Every concern carries a severity rating — Critical, High, Medium, or Low — based on the CVSS qualitative scale. Critical means act immediately; Low means act eventually, not urgently. This is the detail worth remembering for the exam: severity isn’t a vague label, it maps to an actual industry scoring standard, and it’s what should drive your triage order, not the order concerns happen to appear in.
Enabling it
# The dashboard is backed by the Container Security API
gcloud services enable containersecurity.googleapis.com --project=PROJECT_ID
Then, in the Cloud Console’s Security Posture page → Settings, enroll each eligible cluster in the features you want. Results can take up to 30 minutes to appear after enabling — a detail worth knowing so you don’t assume it’s broken if the dashboard is empty right after turning it on.
For fleets specifically: configure features at the fleet level via the gcloud CLI, and clusters that register during creation inherit that fleet configuration automatically. Clusters already registered before a fleet-level change do not retroactively inherit it — the same “fleet defaults apply going forward, not retroactively” pattern already seen with Cloud Service Mesh fleet defaults earlier in this series.
Kubernetes security posture — configuration checks
This category scans your actual Kubernetes object configurations (Pod specs among them) for risky settings — think overly permissive container privileges, missing resource limits, or other configuration anti-patterns covered throughout this series. Two details worth memorizing:
- Enabled by default on new clusters running GKE 1.27 or later.
- It doesn’t disrupt running workloads — this is passive scanning and reporting, not an admission-time blocker like Policy Controller (from the earlier config-at-scale article). If you need to actually block a bad configuration rather than just get told about it, that’s Policy Controller’s job, not this one.
Workload vulnerability scanning — now removed, know what replaced it
Older exam material (and some still-indexed Google documentation) describes a “workload vulnerability scanning” feature built into the posture dashboard: in-cluster scanning of running container images for known CVEs, in two tiers (Standard = container OS packages only; Advanced Vulnerability Insights = OS packages and language packages like Go, Maven, JavaScript, Python).
That feature no longer exists. Both tiers have been fully shut down, not just scheduled for shutdown:
| Tier | Status |
|---|---|
| Standard (container OS scanning) | Shut down July 31, 2025 |
| Advanced Vulnerability Insights | Stopped producing results June 16, 2026 |
The console toggle to enable or disable this scanning has been removed, and historical results can no longer be viewed. If you see an exam question (or older study material) describing this as something you configure in the posture dashboard today, that’s testing a mechanism that has already been retired — recognize it as history, not as something to go set up.
What replaced it — this is what’s actually current:
- Artifact Analysis — automatic or on-demand vulnerability scanning for images stored in Artifact Registry. This is the direct, registry-level successor for “scan my images for CVEs.”
- Security Command Center — two relevant capabilities: Artifact Registry vulnerability assessment (scans images in the registry) and Vulnerability Assessment for Google Cloud (Preview), which covers GKE Standard nodes and container images running on both Autopilot and Standard clusters, including images that didn’t come from Artifact Registry.
Worth knowing for completeness, even if it’s not the focus here: the same posture-dashboard deprecation wave removed three other features that were never covered elsewhere in this series — GKE threat detection (Preview, removed March 31, 2025 → replaced by Security Command Center’s Event Threat Detection), the supply-chain/Binary Authorization check inside the posture dashboard (Preview, removed March 31, 2025 → set up Binary Authorization directly, covered in the CI/CD article earlier in this module, plus a continuous image-freshness validation check still in Preview), and the GKE Compliance dashboard (Preview, removed June 30, 2025 → Security Command Center Premium/Enterprise compliance management). None of these had a GKE-built-in replacement — in every case, the replacement lives in Security Command Center or a tool you configure directly instead of through the posture dashboard.
Node security
Node-level hardening is largely about defaults you get automatically rather than things you configure by hand:
- Container-Optimized OS (
cos_containerd, GKE’s default node image) ships a minimal attack surface by design — fewer installed packages means fewer things to exploit. - Shielded GKE nodes verify node integrity at boot (secure boot, a measured boot sequence, and integrity monitoring), protecting against rootkits and boot-level compromise.
- Automatic node upgrades and security patches mean the node OS itself doesn’t accumulate unpatched vulnerabilities the way a hand-managed VM fleet might.
On Autopilot specifically (from the GKE deployment article earlier in this series), many of these node-security defaults are simply non-negotiable — you don’t get to turn hardening off, which is part of what “fully managed nodes” means in practice.
How this connects to the rest of the series
The security posture dashboard doesn’t replace any of the mechanisms covered elsewhere in this series — it’s the layer that tells you whether you’ve actually used them correctly:
- RBAC and Workload Identity (earlier article) limit who can do what — a posture concern might flag an overly broad RoleBinding.
- Policy Controller (config-at-scale article) enforces configuration rules at admission time — the security posture dashboard reports on configuration risk whether or not Policy Controller is blocking it.
- mTLS/AuthorizationPolicy (service mesh security article) secure traffic — vulnerability scanning is a completely separate concern: a perfectly encrypted connection to a container running a package with a known critical CVE is still a real exposure.
Exam Takeaways
- The security posture dashboard has three views: Dashboard (summary), Concerns (actionable, per-issue), Settings (feature toggles).
- Severity ratings (Critical/High/Medium/Low) are based on the CVSS qualitative scale — this is the basis for triage priority.
- Kubernetes security posture (config checks) is enabled by default on GKE 1.27+ clusters and is non-disruptive — it reports, it doesn’t block (Policy Controller blocks).
- Workload vulnerability scanning is retired, not just deprecated: the Standard tier shut down July 31, 2025; Advanced Vulnerability Insights stopped producing results June 16, 2026. There’s no toggle for it anymore. Know the replacement names: Artifact Analysis (registry-level scanning) and Security Command Center (Artifact Registry vulnerability assessment; Vulnerability Assessment for Google Cloud for node/image coverage).
- Three other posture-dashboard features were removed in the same wave — GKE threat detection, the supply-chain/Binary Authorization preview check, and the GKE Compliance dashboard — all replaced by Security Command Center or a directly configured tool, not a GKE-native successor.
- Fleet-level security posture settings apply to clusters registered after the setting is configured — not retroactively to existing members, the same pattern as other fleet-default features in this module.
- Node security (Container-Optimized OS, Shielded GKE nodes, automatic patching) is largely automatic, and on Autopilot specifically, non-optional.