> For the complete documentation index, see [llms.txt](https://docs.nullify.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.nullify.ai/connectors/kubernetes.md).

# 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](/capabilities/cloud-audits.md) (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](/capabilities/cloud-audits.md) 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](/connectors/aws.md), [GCP](/connectors/gcp.md)). 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](#whitelisting-collector-accounts) below.

{% hint style="info" %}
The collector is read-only. It reads cluster metadata through the Kubernetes API and never writes to your cluster.
{% endhint %}

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:

```http
POST /admin/integrations/cloud/k8s/whitelist
```

```json
{
  "accountIds": ["123456789012"]
}
```

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. If no KMS key ARN is configured, the response reports `"kmsSkipped": true` with `kmsPolicyUpdated: false` and no `kmsError`.
* 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.

{% hint style="warning" %}
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.
{% endhint %}

## Support

* Implementation assistance: <support@nullify.ai>
* Feature requests: [GitHub issue tracker](https://github.com/nullify-platform/feature-requests)

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