Kubernetes

Kubernetes support is a control-plane integration for dynamic source resolution, not a full in-cluster deployment package.

Neuwerk can use Kubernetes as a source of dynamic identities for policy. It does not currently define a full in-cluster deployment pattern, Helm chart, or operator.

Operationally, Neuwerk is meant to run adjacent to the cluster as dedicated network infrastructure, not inside the cluster as another workload.

What Kubernetes Support Means

Kubernetes support in the current product means:

  • storing a Kubernetes API integration in the control plane
  • referencing that integration from policy source groups
  • resolving pod IPs or node InternalIPs from the Kubernetes API
  • feeding those resolved IPs into dynamic source sets used by policy evaluation

This is a control-plane integration. The dataplane does not query Kubernetes directly.

What It Does Not Mean

These items are not defined by the current product docs or runtime:

  • a prescribed Deployment or DaemonSet layout
  • bundled RBAC manifests
  • a bundled Helm chart
  • required CNI guidance
  • a fixed Service or Ingress pattern

Compatibility depends on the gateway seeing source IPs that can still be resolved back to pod IPs. Overlay designs that hide or rewrite the original pod source IP before traffic reaches the gateway are not currently supported.

How The Integration Works

You create a named integration with:

  • API server URL
  • CA certificate PEM
  • service-account token

Policy source groups can then reference that integration with either:

  • a pod selector
  • a node selector

The control plane continuously resolves and refreshes those selectors over time.

Operational Behavior

Kubernetes-backed sources are not baked into policy once and left alone. The control plane:

  1. watches the active policy
  2. identifies referenced Kubernetes selectors
  3. lists matching objects
  4. watches for changes
  5. updates the dynamic source IP set used by policy evaluation

If resolution becomes stale for long enough, the dynamic set is cleared rather than trusted forever.

Failure Model

When Kubernetes-backed sources fail, the symptoms usually look like source-membership problems:

  • a source group no longer matches the traffic you expected
  • policy seems correct, but the dynamic IP set is stale or empty

Start troubleshooting with:

  • the integration record
  • the active policy’s selector definitions
  • /ready
  • /api/v1/stats

Use This Feature For

  • policy that follows pods or nodes without manual IP maintenance
  • separating source identity management from packet matching
  • Kubernetes-adjacent gateway deployments where pod source IPs remain visible to the Neuwerk

Do not treat this page as a complete guide for running the Neuwerk itself inside Kubernetes. That deployment story is still a documentation gap.

If you want a task-oriented example, use Use Kubernetes-Backed Sources.