Ctrlk
Book a Demo
For the complete documentation index, see llms.txt. This page is also available as Markdown.

Kubernetes

Overview

Connect Kubernetes to Nullify to audit your clusters for misconfiguration. Nullify evaluates a dedicated Kubernetes ruleset — workload, RBAC, network, and cluster-configuration checks — as part of its Cloud Audits (CSPM) capability, then correlates findings with the accounts and code that own those clusters.

Key Benefits

  • Cluster misconfiguration detection — Catch insecure workloads, over-broad RBAC, missing network policy, and weak cluster controls before they are exploited.

  • Managed and on-prem coverage — Works for cloud-managed clusters (EKS, GKE, and AKS via your Azure account) and self-hosted / on-prem clusters.

  • Refreshes as data lands — Findings reconcile each time a cluster's inventory arrives. The in-cluster collector uploads on a schedule (daily by default, configurable), and Nullify re-audits each time new inventory lands.

  • Read-only — The collector reads cluster metadata through the Kubernetes API and uploads it for analysis. Nullify does not modify your cluster.

What It Scans

Nullify ships a dedicated Kubernetes ruleset (alongside the AWS, GCP, and Azure rulesets) that runs against the collected cluster inventory. Checks span:

  • Workloads — privileged containers, host namespace sharing (host PID / IPC / network), privilege escalation, dangerous capabilities, hostPath volumes, image pinning, and pull-policy hygiene.

  • RBAC — cluster-admin bindings, wildcard and escalation verbs, anonymous and default-service-account bindings, and stale or over-broad role grants.

  • Network & admission — missing default-deny network policies, overly permissive ingress, and admission/webhook configuration weaknesses.

  • Cluster configuration — etcd encryption, control-plane settings, and config-map hygiene (sensitive data, embedded credentials).

Each detection becomes a CSPM finding that is AI-triaged for false-positive likelihood and priority, the same as any AWS, GCP, or Azure cloud finding. See Cloud Audits for the cross-provider view.

How It Works

Nullify supports two scanning paths depending on cluster type:

  1. Managed clusters (EKS, GKE) — Scanned platform-side using the underlying cloud account's credentials. Configure these alongside the cluster's cloud account (AWS, GCP). For AKS, connect your Azure account — contact your Nullify representative for setup.

  2. On-prem / self-hosted clusters — Scanned by the in-cluster Nullify Kubernetes collector, which walks the cluster API and uploads a cluster-inventory envelope to Nullify's secured upload area. An ingestor then validates the upload and stores it for scanning.

In both cases, a completed scan emits an event that drives the CSPM reconcile: new misconfigurations are stored and triaged, fixed ones are resolved, and reintroduced ones re-open — so cluster posture stays current without a fixed schedule.

Collector Setup (On-Prem / Self-Hosted)

The Nullify Kubernetes collector ships in the nullify-cloud-connector Helm chart and runs inside your cluster. At a high level:

  1. Deploy the collector into the target cluster via Helm. It runs on a schedule, authenticates to the Kubernetes API in-cluster (read-only), and collects cluster resources — nodes, namespaces, pods, services, deployments, RBAC, and related objects.

  2. Grant upload access. The collector uploads its inventory envelope to Nullify's secured S3 upload area. Encryption in transit is enforced; the collector supports a KMS key for upload encryption.

  3. Whitelist the account(s). Nullify must allow the uploading AWS account(s) to write to the bucket (and use the KMS key). See Whitelisting Collector Accounts below.

The collector is read-only. It reads cluster metadata through the Kubernetes API and never writes to your cluster.

Cluster registration is managed through the admin API. A site administrator declares each cluster (name, type, and — for managed clusters — the cloud account ID and region) and optionally the Nullify role ARN used to reach the cluster.

Whitelisting Collector Accounts

Collector uploads land in a Nullify-managed bucket whose access policy is allowlisted per AWS account. The platform normally reconciles this allowlist automatically when cloud settings are saved, but a dedicated endpoint exists to (re)apply it on demand — useful during onboarding or if the bucket/KMS policy drifts:

Behaviour:

  • accountIds (optional) — The AWS account IDs allowed to upload collector data. If omitted, Nullify falls back to every account stored on the tenant's AWS cloud settings.

  • The handler reconciles both the upload bucket policy and, when configured, the KMS key policy, and reports which were updated.

  • Sending an empty request when no AWS accounts are configured is rejected as a bad request (an empty reconcile would strip the allowlist rather than extend it).

This endpoint requires config-write permission.

Whitelisting only grants upload access — it does not register a cluster or start a scan. Declare the cluster through cloud settings, then deploy the collector.

Support

Findings flow asynchronously into Jira, Slack, and the Nullify dashboards so remediation stays aligned with cluster and cloud owners.

PreviousConfigurationNextBuildkite

Last updated