AccuKnox CWPP & KubeArmor Now Runs on GKE Autopilot

GKE Autopilot is Google’s fully managed Kubernetes mode. You hand off node provisioning, scaling, and infrastructure management to Google. Less overhead, more focus on your workloads. Most teams adopt it for exactly that reason because it eliminates the undifferentiated heavy lifting so engineers can stay focused on application logic, not cluster infrastructure.

But if you run security tooling that needs deep kernel access, Autopilot has been a hard blocker. Until now.

What KubeArmor Actually Does

KubeArmor is AccuKnox’s open source runtime security engine. It sits at the kernel level and uses LSM hooks and eBPF to enforce security policies directly on your workloads. That means blocking malicious process execution, restricting unauthorized file access, and catching abnormal network behavior before it does damage.

To do that, it runs as a DaemonSet (one pod per node). It needs two things: most managed clusters are reluctant to grant privileged container access and direct visibility into host-level resources like /proc and /sys. These are not optional design choices. They are the mechanism by which KubeArmor observes and controls workload behavior at the system call level. 

GKE Autopilot is designed to block both. This is the architecture- level conflict that kept runtime enforcement off Autopilot entirely.

Why Autopilot Blocked KubeArmor Completely

When teams tried to deploy AccuKnox CWPP on Autopilot, the control-plane components came up successfully. The AccuKnox dashboard loaded, dashboards populated, and visibility features appeared to work. The KubeArmor DaemonSet never did. Autopilot’s security constraints rejected it at admission for three reasons:

• Privileged containers are blocked outright, and KubeArmor needs privileged access to talk to the kernel
• Host-level paths like /proc and /sys are off-limits, both of which KubeArmor uses for node-level workload observation
• DaemonSet capabilities are restricted enough to prevent the node-level distribution KubeArmor depends on

So teams running POCs on Autopilot could show the AccuKnox platform, pull up dashboards, and demo visibility features. But actual enforcement, blocking shell execution, restricting file access, validating runtime policies, none of that worked. The enforcement engine simply was not there.

The only real option was migrating to a Standard GKE cluster. For teams already running production Autopilot environments shared across multiple dev teams, that conversation went nowhere fast. Migrating a shared production cluster demands operational alignment across teams.

How Google’s Partner Workload Program Made This Possible

Google built the Autopilot Workload Allowlist program for exactly this scenario. Privileged third-party workloads that have a legitimate, reviewed reason for elevated access can apply to be listed as an official GKE Partner Workload. Google reviews the workload specification, and once approved, the allowlist gets merged into the official GKE partner repository.

AccuKnox went through that process for KubeArmor. The PR has been reviewed, approved, and merged. This is not a workaround or an unofficial configuration. It is Google’s sanctioned path for privileged security workloads on Autopilot. 

AccuKnox now maintains a versioned allowlist for every stable KubeArmor release. Cluster admins sync it to their Autopilot cluster using a single AllowlistSynchronizer YAML manifest. Once the allowlist is active, KubeArmor installs cleanly via Helm, and the DaemonSet comes up on every node. No cluster migration. No moving to Standard. Your Autopilot environment stays exactly as it is, fully managed and fully enforced. 

What Security Teams Can Actually Do Now

With KubeArmor running on Autopilot, the full AccuKnox CWPP enforcement stack is available. Here is what that looks like in practice:

• Runtime policy enforcement – Write policies that block specific process execution, file access, or network activity at the kernel level. Violations return a permission denied error and fire alerts on the platform immediately. You define what normal looks like for each workload, and KubeArmor enforces it, with no agent polling and no delayed detection.
• Audit mode for gradual rollout – Before blocking anything in production, run policies in observe-only mode. You see exactly what would have been blocked without touching workload behavior. Start there, validate the policy scope, and enforce when ready. This matters because enforcement without prior visibility introduces false confidence, and audit mode removes that risk. 
• Workload behavior visibility – Map egress and ingress connections per workload in a graphical view. Catch unexpected external communication or east-west movement before it turns into an incident. This is particularly useful in multi-tenant Autopilot environments where workload boundaries are not always obvious from network logs alone.
• Violation logs and alerting – Every policy hit is recorded with source process, target resource, policy name, action taken, and timestamp. All of it is queryable from the AccuKnox platform under All Alerts. No custom log pipelines required because the platform surfaces it directly. 
• Unified platform coverage – Onboard your Autopilot cluster and get consolidated visibility acrossCSPM,KSPM,CWPP, andASPM from one control plane. If you are already running AccuKnox on Standard GKE or other cloud environments, Autopilot clusters integrate cleanly alongside them.

How to Get Started

You need three things before you begin:

1. A GKE Autopilot cluster with cluster-admin access
2. Helm CLI v3.9 or later
3. Permissions to create AllowlistSynchronizer resources

From there, apply the allowlist sync YAML, install KubeArmor via Helm with –set environment.name=autopilot, confirm pods are running, and onboard your cluster to the AccuKnox platform.

The full step-by-step guide is at help.accuknox.com/getting-started/gke-autopilot.

If your team has been stuck waiting on Autopilot support to run a proper runtime security POC, that blocker is gone. KubeArmor runs. Enforcement is live. Your cluster stays fully managed.