Full-Stack Observability on GKE Autopilot: What Google Locks Down, and How to See Through It Anyway
GKE Autopilot's security model blocks privileged containers, host namespaces, and direct node access by default - which is precisely what most observability and security agents depend on to enrich application telemetry with infrastructure context. For platform teams moving from GKE Standard to Autopilot, this creates a quiet but serious gap: the monitoring stack that worked yesterday may silently lose depth today, and closing that gap usually means building and maintaining a custom privileged-workload allowlist by hand.
In this session, groundcover — a newly approved official partner on Google's GKE Autopilot program — walks through exactly what Autopilot restricts and why, what breaks in your logs, traces, and infra metrics once you're on Autopilot, and how to get full-stack, kernel-level visibility back without reopening the security boundaries Autopilot was built to enforce. We'll deploy groundcover's eBPF sensor live on a real Autopilot cluster to show what "native" partner-level access actually looks like in practice, including how a bring-your-own-cloud architecture keeps that data inside your own environment for teams operating under strict compliance requirements.
What you'll learn:
- What GKE Autopilot's security model restricts, and the reasoning behind each guardrail
- The specific observability and security gaps teams hit after migrating from Standard to Autopilot
- How official Autopilot partner status differs from a self-managed allowlist workaround — and why that distinction matters for maintenance overhead and audit posture
- A live install and walkthrough of full-stack, zero-instrumentation observability running natively on Autopilot
Who should attend: Platform, infrastructure, and SRE leaders operating or evaluating GKE Autopilot — particularly teams in regulated industries where data residency and compliance shape tooling decisions.
.svg)
