Haven+ as an Implementation and Evidence Layer for the CIS Kubernetes Benchmark

Version: 1.0

Date: 29 September 2026

Benchmark baseline: CIS Kubernetes Benchmark v2.0.1 (document dated 29 April 2026; Kubernetes v1.34 - v1.35; 131 recommendations)

Audience: platform engineers, security engineers, auditors, service managers, cloud/Kubernetes providers

Purpose. This guide explains how Haven+ can help implement and demonstrate alignment with CIS Kubernetes Benchmark requirements, which controls remain the responsibility of the underlying Haven/Kubernetes platform or managed Kubernetes provider, and what evidence should be retained for each requirement. It is an implementation and evidence guide, not a certificate of compliance.

Validation note. Version-specific statements in this guide - the benchmark version, section numbering, recommendation identifiers and profile levels, the Haven+ component inventory and tool capabilities - reflect the sources listed in section 13 as of the document date. CIS and the referenced projects revise numbering, content and defaults between releases. Re-validate every version-specific claim against the licensed/current CIS Kubernetes Benchmark and current vendor documentation before any formal assessment or audit.

Conventions used in this guide. "CIS x.y.z" always refers to a recommendation or section of the CIS benchmark. "Guide section N" (or "section N") refers to a section of this document. Guide section 6.n deliberately corresponds to CIS section 5.n.

Document control

Version	Date	Changes
1.0	29 September 2026	First public release.

1. Executive summary

Haven+ is a reference architecture and implementation that adds production platform services to a Haven Kubernetes environment. Its current reference implementation includes GitOps patterns and components for identity, secrets, policy management, TLS, service-to-service traffic, observability and backup. These capabilities can provide strong implementation mechanisms and audit evidence for a meaningful subset of CIS Kubernetes controls, especially the Kubernetes-policy and workload-facing controls in CIS section 5.

Haven+ does not by itself make a Kubernetes cluster CIS-compliant. CIS also covers the Kubernetes control plane, etcd, kubelet/node configuration, authentication methods, audit policy, RBAC, service accounts, pod security and network segmentation. In a managed Kubernetes service, many control-plane and node settings are controlled by the public-cloud provider and must be demonstrated through provider configuration, provider documentation/assurance, or a provider-specific CIS benchmark.

The central audit rule in this guide is:

A CIS requirement is only considered demonstrated when the organization can show (1) scope, (2) configuration or enforcement, (3) an objective test/result, (4) evidence with a timestamp/version, and (5) ownership of exceptions.

1.1 Responsibility layers

Layer	Typical owner	Examples	Primary evidence
Managed Kubernetes / IaaS	Public-cloud or Kubernetes provider	API server, etcd, scheduler, controller manager, node image, some kubelet settings	Provider configuration export, provider CIS guide, attestation, service configuration
Haven / Kubernetes baseline	Cluster/platform team	RBAC, namespaces, CNI, NetworkPolicy, Pod Security Admission	Git manifests, `kubectl` output, scanner output
Haven+ platform services	Platform team	OIDC integration, secrets, TLS, observability, service mesh, GitOps, backup, Kyverno admission policies	Git history, Helm/Kustomize manifests, component status, policy reports, dashboards/reports
Workloads	Application teams with platform guardrails	securityContext, service accounts, capabilities, host access, secrets usage	Deployment manifests, admission results, policy reports

2. Scope and benchmark selection

This guide uses CIS Kubernetes Benchmark v2.0.1. The benchmark document is dated 29 April 2026 and targets Kubernetes v1.34 - v1.35. Before an audit, record the exact Kubernetes version and the exact CIS benchmark/profile being assessed. For managed services, also assess the provider-specific benchmark where available (for example CIS AKS, EKS, or the provider's documented CIS responsibility mapping).

The benchmark contains 131 recommendations: section 1 (Control Plane Components) 60, section 2 (etcd) 7, section 3 (Control Plane Configuration) 5, section 4 (Worker Nodes) 25 and section 5 (Policies) 34. Of these, 64 are marked Automated and 67 Manual by CIS; all recommendations in sections 3 and 5 are Manual. Each recommendation belongs to a Level 1 or Level 2 profile (Master Node or Worker Node). Several recommendations that matter most to Haven+ are Level 2: CIS 3.2.2, 5.2.7, 5.2.9, 5.3.2, 5.4.1, 5.4.2, 5.5.1, 5.6.2, 5.6.3 and 5.6.4. Record which profile level is in scope; a Level 1-only assessment does not require these.

The mapping between CIS sections and guide sections used throughout this document is summarized in Appendix A.

According to cloud-native development and GitOps best practices, the baseline configuration of all clusters should be the same wherever the same security requirements apply. Define that baseline declaratively, version it in Git and promote/reuse the same policy and platform configuration across clusters. Environment-specific deviations must be explicit and reviewable. Compliance evidence should therefore demonstrate both (1) that the common baseline is defined and approved and (2) that each cluster is actually reconciled to that baseline. A single baseline definition can be reused as design evidence; runtime evidence should confirm that the intended baseline is active on the clusters in scope.

2.1 Status vocabulary

Use these statuses consistently across the entire evidence register:

PASS - requirement verified by objective evidence.
FAIL - requirement is applicable and not satisfied.
N/A - provider managed - setting is outside tenant control; provider responsibility and evidence are documented.
N/A - not applicable - requirement genuinely does not apply; rationale is documented.
PARTIAL - some but not all conditions are demonstrated; remediation/evidence gap remains.
MANUAL - human review is still pending, or automated evidence is insufficient to reach a verdict.

CIS "Manual" is not the same as guide status MANUAL. CIS labels a recommendation Manual when the benchmark provides no automated audit. Such a recommendation can still reach PASS or FAIL once a reviewer has evaluated the evidence. Record the CIS assessment status in its own field (section 3) and use guide status MANUAL only for reviews that are still open.

3. The evidence model: how to prove one CIS requirement

For every CIS ID create one evidence record with the following fields:

Field	What to record
CIS ID	Exact benchmark recommendation identifier
Requirement summary	Short paraphrase of what CIS requires
CIS profile and assessment status	Level 1 / Level 2, Master Node / Worker Node, Automated / Manual (as stated in the benchmark)
Applicability	Applicable / N/A - provider managed / N/A - not applicable
Responsible layer	Provider / Haven / Haven+ / Workload
Implementation	What technical control enforces the requirement
Test	Command, query, scanner or review procedure
Alerting	Where violations/findings are routed (developer PR/pipeline, platform-team alert, incident process); record "not applicable" where a control generates no actionable events
Expected result	Unambiguous pass condition
Evidence artifact	Immutable output, export, screenshot, policy report or Git reference
Integrity	Hash of each artifact (for example SHA-256) captured at collection time, plus storage location and access restrictions
Timestamp and versions	Cluster version, component version, date/time
Status	One value from the vocabulary in section 2.1
Owner	Person/team responsible for the control
Reviewed	Date and reviewer of the evidence record
Exception	Approved deviation, compensating control, expiry date

Evidence integrity. A screenshot or export on a shared drive is not immutable by itself. Record a hash (for example SHA-256) of every artifact at capture time and store artifacts in an access-controlled location with tamper-evident or WORM storage where available. The combination of hash, restricted storage and timestamp is what makes an artifact defensible in an audit.

Evidence records feed the condensed register in section 10 and the per-control statement template in Appendix C. The field names above are used identically in section 10 and Appendix C.

3.1 Example: RBAC authorization (CIS 1.2.6 - 1.2.8 and CIS 5.1.1)

Requirement: the Kubernetes API must not use AlwaysAllow, must include the Node authorizer and must use RBAC (CIS 1.2.6, 1.2.7, 1.2.8), and the cluster-admin role must only be used where required (CIS 5.1.1).

Implementation: enable RBAC at the cluster/provider layer; use Kubernetes Roles/ClusterRoles and bindings. Haven's own mandatory checks include that RBAC is enabled. Haven+ can strengthen the operating model by managing authorization configuration declaratively through GitOps.

Test: provider configuration plus kubectl auth can-i tests and review of role bindings.

Alerting: alert on changes to bindings that grant cluster-admin (for example, audit-log events routed to the observability stack) and on wildcard permissions detected by policy scanning.

Evidence artifact: provider cluster configuration export; kubectl get clusterrolebindings,rolebindings -A -o yaml; Git commit/PR that defines platform RBAC; dated access review. Store artifacts hashed (SHA-256) in the access-controlled evidence location.

Expected result: RBAC is enabled; unrestricted modes are not used; high privilege bindings are justified and reviewed.

3.2 Example: privileged workloads (CIS 5.2.1 and CIS 5.2.2)

Requirement: the cluster has at least one active policy control mechanism for namespaces with user workloads (CIS 5.2.1), and the admission of privileged containers is minimized (CIS 5.2.2).

Implementation: enforce admission rules with Kyverno (the Haven+ policy engine) and/or Pod Security Admission at restricted where feasible; define explicit exceptions. Haven+ GitOps stores namespace labels, Kyverno policies and workload manifests as code.

Test: inspect namespace Pod Security labels and Kyverno policy state; query live workloads for securityContext.privileged: true; run a policy/CIS scanner. A practical approach is to run Kubescape or Trivy/Trivy Operator against Kubernetes API objects and manifests, and use kube-bench where node/control-plane access is available. Run the same checks in CI against manifests before merge and periodically against the live cluster. Export machine-readable JSON/JUnit/SARIF where supported so results can be retained and processed automatically.

Alerting: fail or annotate the developer pull request for workload-owned violations; create a platform-team alert/ticket for cluster-wide or baseline violations. For continuous scanning, expose scanner/policy metrics or events to the observability pipeline and alert through Grafana/Alertmanager or the organization's incident system. Admission-policy denials should be visible to the developer immediately and also collected centrally for trend/exception monitoring.

Evidence artifact: namespace YAML, Kyverno policy YAML, denied deployment test, scanner report and exception register. Store artifacts hashed (SHA-256) in the access-controlled evidence location.

Expected result: privileged workloads are denied by default or demonstrably minimized, and every exception is approved and bounded.

4. Haven+ capabilities and their CIS value

As of the document date, the Haven+ Overview page lists these reference-implementation components: Alloy, cert-manager, CloudNativePG, ECK Operator, External DNS, External Secrets Operator, Grafana, Istio Gateway, Istio, Keycloak, Loki, Mimir, Pinniped, Sealed Secrets, Tempo and Velero, with FluxCD and ArgoCD reference implementations. The Overview also names policy management and secret management as capabilities. The Haven+ Components documentation additionally lists Kyverno and OpenBao (along with Headlamp, Garage, OpenCost, the NVIDIA GPU Operator and cluster resources). The Overview component list is therefore not exhaustive, and this guide relies on the Components documentation for Kyverno and OpenBao. Confirm the Kyverno policy set and configuration in the Haven+ documentation before relying on it. These components are useful control mechanisms, but their presence alone is not evidence of CIS compliance.

Haven+ capability	CIS/security contribution	What must still be configured/proved
GitOps (Flux/Argo CD patterns)	Reproducible security configuration, change traceability, drift correction	Protected repositories, PR review, reconciliation health, break-glass procedure
Kyverno	Admission-time validation, mutation, generation and image verification; policy reports. Primary Haven+ mechanism for CIS 5.2, 5.5.1 and 5.6	Policies in enforce mode for security-critical rules, webhook failure behavior, exceptions with owner and expiry, controller health, negative tests
Pinniped / Keycloak / external OIDC	Central user authentication (supports CIS 3.1.x)	Provider/API-server OIDC support, MFA/IdP policy, group-to-RBAC mapping, access review
External Secrets Operator	Centralized external secret retrieval (supports CIS 5.4.2)	Secure backend, workload identity, least-privilege secret policies, no plaintext secrets in Git
OpenBao	Open-source, Vault-compatible central secret backend; Haven+ can integrate it with External Secrets Operator and Kubernetes authentication	Production-grade HA, tenant policies, backup/recovery, audit logging and an external KMS/HSM/Transit unseal mechanism rather than the reference in-cluster static seal key
Sealed Secrets	Encrypted secrets can be stored declaratively	Controller key protection/rotation, repository rules, namespace/name scoping
cert-manager	Automated TLS certificate lifecycle	Trusted issuers, renewal monitoring, private-key handling, ingress policy
Istio	mTLS/service identity and traffic policy	Strict mode where required, AuthorizationPolicy, not a substitute for NetworkPolicy
Alloy + Loki/Mimir/Tempo/Grafana	Central logs, metrics and traces; operational evidence	Kubernetes audit logs source, retention, access controls, alerting, time sync
Velero	Backup/restore of Kubernetes resources and volumes	Schedules, protected object storage, encryption, restore tests, RPO/RTO evidence

5. CIS control families 1 - 4: responsibility and evidence

5.1 Control-plane node configuration files (CIS 1.1)

CIS 1.1 has 21 recommendations (1.1.1 - 1.1.21). They address ownership and restrictive permissions of the API server, controller manager, scheduler and etcd pod specification files, the etcd data directory, Container Network Interface files (1.1.9 and 1.1.10, Manual), the administrative credential file, scheduler.conf, controller-manager.conf and the Kubernetes PKI directory and files. On Kubernetes 1.29 and later the benchmark also refers to the super-admin.conf file. The runtime arguments/flags of the same components are separate recommendations, covered in guide sections 5.2 (API server, CIS 1.2), 5.3 (controller manager and scheduler, CIS 1.3 and 1.4) and 5.4 (etcd, CIS 2). See Appendix A for the full mapping.

In self-managed Kubernetes they are cluster-operator responsibilities. In managed Kubernetes, the customer usually cannot inspect or modify these files.

Haven+ contribution: none directly; these controls remain the responsibility of the Kubernetes/control-plane operator or managed-service provider.

Managed-service evidence pattern:

Record that the control plane is provider managed and not exposed to the tenant.
Identify the provider-specific CIS benchmark or security configuration guide.
Retain cluster SKU/version/configuration export showing the managed service in scope.
Retain provider assurance/documentation that maps responsibility for control-plane hardening.
Mark the generic Kubernetes item N/A - provider managed only when the benchmark/audit methodology permits it; otherwise use the provider-specific benchmark result.

Self-managed evidence pattern: collect file mode/ownership results directly from every control-plane node and retain the scanner output.

5.2 API server (CIS 1.2)

CIS 1.2 has 30 recommendations (1.2.1 - 1.2.30). The family covers secure authentication, authorization (1.2.6 - 1.2.8), admission control plugins (1.2.3, 1.2.9 - 1.2.14), profiling, audit-log arguments (1.2.16 - 1.2.19), request handling, service-account configuration, TLS and etcd client settings, encryption of Secrets at rest (1.2.27 encryption provider configuration, 1.2.28 encryption providers) and strong cryptographic ciphers (1.2.29).

Haven+ contribution: identity integration can be supported through Pinniped/Keycloak or an external identity provider; GitOps can manage RBAC and policy resources. Haven+ cannot override API-server flags that a managed provider owns.

You must configure at Haven/Kubernetes level:

RBAC roles and bindings using least privilege.
Group-based access instead of persistent individual admin bindings.
Admission controls/policies available to the tenant.
Controlled use of service accounts and tokens.
Periodic review of high-privilege access.

Note on CIS 1.2.3 (DenyServiceExternalIPs). This is an API-server admission plugin. Where the tenant cannot set it, an admission policy that blocks new use of Service.spec.externalIPs may be documented as an equivalent-outcome control, subject to assessor acceptance.

Evidence artifact: provider API-server/cluster settings, provider encryption-at-rest configuration (CIS 1.2.27 and 1.2.28), identity configuration, RBAC exports, kubectl auth can-i tests, admission-policy manifests, access review records.

5.3 Controller manager and scheduler (CIS 1.3 and 1.4)

CIS 1.3 (controller manager) has 7 recommendations and CIS 1.4 (scheduler) has 2. These controls concern component arguments and credentials. They are normally provider-owned on a managed Kubernetes service.

Haven+ contribution: none directly.

Evidence artifact: provider responsibility mapping or provider-specific CIS assessment. For self-managed clusters, retain component configuration/argument scans.

5.4 etcd (CIS 2)

CIS section 2 has 7 recommendations (2.1 - 2.7). CIS requires authenticated and encrypted client/peer communications, avoidance of insecure automatic TLS patterns and a unique certificate authority for etcd. Managed Kubernetes normally hides etcd from customers.

Haven+ contribution: none to etcd hardening.

Evidence artifact: provider documentation/attestation and provider-specific benchmark. For self-managed Kubernetes, retain etcd flags, certificate configuration and file permissions.

5.5 Control-plane configuration (CIS 3)

CIS section 3 has five recommendations, all Manual.

5.5.1 Authentication methods for users (CIS 3.1.1 - 3.1.3, Level 1)

These recommendations say that client certificate authentication (3.1.1), service account token authentication (3.1.2) and bootstrap token authentication (3.1.3) should not be used for users. The benchmark recognises that client-certificate use cannot be disabled cluster-wide because cluster components rely on it; the requirement concerns end-user access.

Haven+ contribution: Pinniped with Keycloak (or an external identity provider) provides OIDC-based kubectl access, which is the intended alternative for humans. Haven+ cannot prove the negative by itself.

Must configure yourself / show:

Human access to the API goes through OIDC; document how kubeconfigs are issued.
No standing user kubeconfigs that embed client certificates or service account tokens; break-glass credentials are separated, audited and time-bound.
Certificate signing requests are reviewed and approved only for components or documented exceptions (see also CIS 5.1.11).
Bootstrap tokens are removed or short-lived after node join.

Evidence artifact: OIDC/Pinniped configuration, kubeconfig issuance procedure, kubectl get csr history, review of Secrets of type kubernetes.io/service-account-token and bootstrap token Secrets, and a sample of audit-log usernames showing human activity arrives via the OIDC identity, not certificate or service account identities.

5.5.2 Logging and audit policy (CIS 3.2.1 Level 1, CIS 3.2.2 Level 2)

CIS 3.2.1 requires a minimal audit policy to exist; CIS 3.2.2 requires that the audit policy covers key security concerns. Treat the provider as responsible for inaccessible control-plane configuration, while the platform team is responsible for enabling any tenant-facing audit-log export and retaining those logs.

Haven+ contribution: Alloy/Loki can receive and retain logs that are made available to the cluster/platform, but Haven+ cannot create cloud-provider control-plane audit events that the provider has not exposed.

Evidence artifact: audit-log enablement and audit-policy documentation at provider layer (or the policy file for self-managed clusters), log pipeline configuration, Loki retention setting, sample audit events, access controls and alert tests.

5.6 Worker nodes: configuration files, kubelet and kube-proxy (CIS 4.1, 4.2 and 4.3)

CIS 4.1 (worker node configuration files, 10 recommendations) covers restrictive file permissions/ownership for the kubelet service file, proxy kubeconfig, kubelet.conf, certificate authority files and the kubelet config.yaml. CIS 4.2 (kubelet, 14 recommendations) covers kubelet authentication/authorization, readOnlyPort, streaming timeouts, certificate rotation, strong ciphers, pod PID limits (4.2.13) and the --seccomp-default setting (4.2.14). CIS 4.3.1 requires the kube-proxy metrics service to be bound to localhost. Responsibility depends strongly on the service model.

Haven+ contribution: none directly to kubelet or kube-proxy hardening.

Haven baseline contribution: Haven requires supported node hardening technology and a private networking topology, and requires the cluster to stay reasonably current.

Note on CIS 4.3.1. If the cluster runs without kube-proxy (for example, a CNI that replaces it), record N/A - not applicable with that rationale and evidence of the networking mode.

Evidence artifact: node-pool configuration, OS/image type, provider hardening statement, kubelet configuration where exposed, kube-proxy configuration or proof of its absence, node version/upgrade policy and CIS scanner results. If nodes are provider-managed and settings are immutable, document that boundary.

6. Kubernetes policy controls (CIS section 5) where Haven+ and the platform team matter most

CIS section 5 contains 34 recommendations, all Manual. They can be inspected and enforced through the Kubernetes API, which makes them the most actionable for a Haven/Haven+ platform. This section highlights where the platform can do the most; it does not replace the full evidence register. Every applicable CIS recommendation - including the provider-owned families in section 5 - must appear in the register (section 10). Guide section 6.n corresponds to CIS 5.n. Appendix A maps CIS sections to guide sections.

6.1 CIS 5.1 - RBAC and service accounts (13 recommendations, Level 1)

CIS 5.1.1 High-privilege / cluster-admin use

Requirement summary: minimize use of the most privileged cluster-wide role and grant it only where operationally necessary.

Haven+ mechanism: manage RBAC as code through GitOps; integrate human authentication with OIDC/Pinniped/Keycloak or the provider identity system.

Must configure yourself:

Define platform-admin, operator and application roles.
Avoid routine user bindings to cluster-admin.
Separate emergency/break-glass access.
Review ClusterRoleBindings on a fixed cadence.

Test:

# Enumerate all subjects explicitly bound to the cluster-admin role
kubectl get clusterrolebindings -o json | jq '.items[] | select(.roleRef.name=="cluster-admin") | {binding_name: .metadata.name, subjects: .subjects}'

# Verify specific permissions for a targeted user persona
kubectl auth can-i --list --as=<test-user>

Retain the output, Git-managed RBAC manifests, access-review approval and the list of approved privileged identities.

Pass evidence statement: "All bindings to cluster-admin are enumerated, business-justified and approved; normal operations use narrower roles. Evidence: RBAC export <artifact>, review <ticket>, Git commit <sha>."

CIS 5.1.2 Minimize access to secrets

Requirement summary: only identities that require Kubernetes Secret access should receive it.

Haven+ mechanism: OpenBao can provide the central secret backend, External Secrets Operator can retrieve scoped secrets using Kubernetes identity, and Sealed Secrets can support encrypted declarative secret delivery. GitOps provides traceability.

Must configure yourself: restrict get/list/watch on Secrets, scope SecretStores and external-backend policies, and prevent application teams from reading unrelated namespaces.

Test:

kubectl get roles,clusterroles -A -o yaml
kubectl auth can-i get secrets -n <namespace> --as=<test-user>
kubectl auth can-i list secrets -A --as=<test-user>

Also retain external secret-backend policy exports and an access test for representative personas.

CIS 5.1.3 Minimize wildcard permissions

Requirement summary: avoid RBAC rules using broad * verbs/resources unless explicitly justified.

Haven+ mechanism: Git review and Kyverno policy-as-code can reject wildcard RBAC.

Test:

# Roles and ClusterRoles with a wildcard in verbs, resources or apiGroups
kubectl get clusterroles,roles -A -o json | jq -r '.items[] | select(any(.rules[]?; (.verbs // [] | index("*")) or (.resources // [] | index("*")) or (.apiGroups // [] | index("*")))) | "\(.kind)/\(.metadata.namespace // "-")/\(.metadata.name)"'

Retain the output and approved exceptions (system roles shipped with Kubernetes will appear and need a documented decision).

CIS 5.1.4 Minimize pod creation permissions

Requirement summary: pod/workload creation is security-sensitive because it can enable access to service accounts, secrets, nodes or privileged settings.

Must configure yourself: only appropriate deployment identities should create pods/controllers; combine RBAC with admission policies.

Test: kubectl auth can-i create pods --as=<test-user> for personas plus RBAC export and admission tests.

CIS 5.1.5 Default service account usage

Requirement summary: avoid using the namespace default service account for application workloads where dedicated identities can be used.

Implementation: create one service account per workload/security boundary and bind only required permissions.

Test:

kubectl get pods -A -o custom-columns='NS:.metadata.namespace,POD:.metadata.name,SA:.spec.serviceAccountName'

Flag application pods using default; document justified exceptions.

CIS 5.1.6 Service-account token mounting

Requirement summary: do not automatically mount API credentials into pods that do not need Kubernetes API access.

Implementation: set automountServiceAccountToken: false on service accounts/pods by default; enable only when needed.

Test: query service accounts and pod specs; use a Kyverno policy to enforce the default.

CIS 5.1.7 - 5.1.13 Privilege-escalation paths through RBAC

These seven recommendations restrict RBAC permissions that allow privilege escalation. All are Manual, Level 1. Review them together with a quarterly RBAC review.

CIS ID	Requirement summary	Haven+ mechanism	Test
5.1.7	Avoid use of the `system:masters` group	GitOps-managed RBAC; Kyverno rule rejecting bindings to the group	List bindings with subject group `system:masters`; review kubeconfig/CSR issuance for certificates with that group
5.1.8	Limit `bind`, `impersonate` and `escalate` permissions	Git review; Kyverno rule on Roles/ClusterRoles	Query roles for those verbs; retain approved exceptions
5.1.9	Minimize access to create persistent volumes (a route to `hostPath` volumes that Pod Security Admission does not cover)	RBAC as code; Kyverno rule restricting PV `hostPath`	`kubectl auth can-i create persistentvolumes --as=<test-user>`; RBAC export
5.1.10	Minimize access to the `nodes/proxy` sub-resource (kubelet API access)	RBAC as code	`kubectl auth can-i get nodes/proxy --as=<test-user>`; RBAC export
5.1.11	Minimize access to the `certificatesigningrequests/approval` sub-resource	RBAC as code	`kubectl auth can-i update certificatesigningrequests/approval --as=<test-user>`; RBAC export
5.1.12	Minimize access to create/modify/delete webhook configuration objects (validating and mutating)	RBAC as code; note Kyverno itself registers webhooks, so its service account is a legitimate holder that must be documented	`kubectl auth can-i create validatingwebhookconfigurations.admissionregistration.k8s.io --as=<test-user>`; RBAC export
5.1.13	Minimize access to create service account tokens (`serviceaccounts/token`)	RBAC as code	`kubectl auth can-i create serviceaccounts/token -n <namespace> --as=<test-user>`; RBAC export

# 5.1.7: bindings to system:masters
kubectl get clusterrolebindings,rolebindings -A -o json | jq -r '.items[] | select(any(.subjects[]?; .kind=="Group" and .name=="system:masters")) | "\(.kind)/\(.metadata.namespace // "-")/\(.metadata.name)"'

# 5.1.8: roles granting bind, impersonate, escalate (or wildcard verbs)
kubectl get clusterroles,roles -A -o json | jq -r '.items[] | select(any(.rules[]?; (.verbs // [] | map(select(. == "bind" or . == "impersonate" or . == "escalate" or . == "*")) | length > 0))) | "\(.kind)/\(.metadata.namespace // "-")/\(.metadata.name)"'

6.2 CIS 5.2 - Pod Security Standards (12 recommendations)

The benchmark describes this section as recommendations for securing deployed workloads, implemented either through the built-in Pod Security Admission controller or through external policy systems that integrate via validating and mutating webhooks.

CIS 5.2.1 (Level 1) requires at least one active policy control mechanism, Pod Security Admission or a third-party system, in place for every namespace that contains user workloads. The benchmark notes that Pod Security Admission is enabled by default but no policies are in place, meaning namespaces must be labelled to obtain enforcement. In Haven+, Kyverno is the policy engine; Pod Security Admission can additionally be enabled as defense in depth. Either satisfies 5.2.1: document which mechanism covers which namespaces and show that no user-workload namespace is uncovered.

Treat PSA restricted as the preferred baseline for normal application namespaces, with explicit controlled exceptions. Kyverno policies can implement equivalent Pod Security Standards checks (and finer-grained rules than PSA) and are the mechanism for reporting and time-bounded exceptions.

Recommended Haven baseline (PSA, optional defense in depth):

apiVersion: v1
kind: Namespace
metadata:
  name: application
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/warn: restricted

Recommended workload security context (also supports CIS 5.6.2 and 5.6.3):

spec:
  securityContext:
    seccompProfile:
      type: RuntimeDefault
  containers:
    - name: app
      securityContext:
        allowPrivilegeEscalation: false
        runAsNonRoot: true
        capabilities:
          drop: ["ALL"]

For each pod-security requirement, evidence should contain: the enforcing namespace/admission policy, a list of current violations, a negative test showing a prohibited pod is denied, and the exception register.

CIS ID	Requirement summary	Level	Kyverno / PSA implementation	Proof
5.2.1	At least one active policy control mechanism for all user-workload namespaces	1	Kyverno policies and/or PSA namespace labels	Policy export + namespace coverage list + denied test
5.2.2	Minimize privileged containers	1	Deny `privileged: true` (PSA `baseline`+)	Policy + denied test + workload scan
5.2.3	Minimize host process ID namespace sharing	1	Deny `hostPID` (PSA `baseline`+)	Policy + scan + exceptions
5.2.4	Minimize host IPC namespace sharing	1	Deny `hostIPC` (PSA `baseline`+)	Policy + scan + exceptions
5.2.5	Minimize host network namespace sharing	1	Deny `hostNetwork` (PSA `baseline`+)	Policy + scan + exceptions
5.2.6	Minimize `allowPrivilegeEscalation`	1	Require `allowPrivilegeEscalation: false` (PSA `restricted`)	Deployment YAML + policy report
5.2.7	Minimize root containers	2	Require `runAsNonRoot: true` / suitable UID strategy (PSA `restricted`)	YAML + runtime/policy result
5.2.8	Minimize `NET_RAW` capability	1	Disallow `NET_RAW` (PSA `baseline`+; `restricted` drops ALL)	YAML + admission/scanner result
5.2.9	Minimize containers with capabilities assigned	2	Drop ALL; add only justified capabilities (PSA `restricted`)	YAML + admission/scanner result
5.2.10	Minimize Windows HostProcess containers	1	Deny `hostProcess: true` (PSA `baseline`+); `N/A - not applicable` if no Windows nodes, with rationale	Policy + node OS inventory
5.2.11	Minimize HostPath volumes	1	Deny/minimize `hostPath` (PSA `baseline`+)	Policy + scan + exceptions
5.2.12	Minimize containers using HostPorts	1	Deny/minimize `hostPort` (PSA `baseline`+)	Policy + scan + exceptions

The PSA level shown for each row is the expected coverage; confirm it with negative tests on the Kubernetes version in scope rather than relying on this table.

6.3 CIS 5.3 - Network policies and CNI (2 recommendations)

CIS 5.3.1 (Level 1): the CNI in use must support Network Policies, including both ingress and egress policies. The benchmark's own example is a CNI plugin that does not enforce them without an additional component.

CIS 5.3.2 (Level 2): every namespace must have at least one NetworkPolicy defined. This is broader than "application namespaces": it includes kube-system, the platform namespaces and default. Because a namespace with no NetworkPolicy allows all traffic, absence of a policy is a FAIL for this recommendation even where the namespace looks harmless.

Important: Istio authorization/mTLS is valuable but is not a replacement for NetworkPolicy. Service-mesh policy operates at a different layer and should be defense in depth.

Recommended baseline: apply default-deny ingress and egress to application namespaces, then add explicit allows. For system and platform namespaces, define policies deliberately (for example, allow DNS and required control-plane traffic) rather than a blanket deny that could break the cluster. A Kyverno generate policy can create a baseline NetworkPolicy in every new namespace so the "every namespace" requirement does not depend on manual steps.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny
  namespace: application
spec:
  podSelector: {}
  policyTypes: [Ingress, Egress]

Haven+ mechanism: Istio can add workload identity, mTLS and L7 authorization; GitOps manages NetworkPolicies and Istio policies; Kyverno can generate baseline policies.

Must configure yourself/provider: select a CNI that enforces both ingress and egress NetworkPolicy; define namespace policies; configure DNS/egress exceptions; validate Istio PeerAuthentication/AuthorizationPolicy where used.

Test:

# CIS 5.3.2: list namespaces that have no NetworkPolicy
for ns in $(kubectl get namespaces -o jsonpath='{.items[*].metadata.name}'); do
  n=$(kubectl get networkpolicy -n "$ns" --no-headers 2>/dev/null | wc -l)
  [ "$n" -eq 0 ] && echo "NO NETWORKPOLICY: $ns"
done

Evidence artifact: CNI/provider configuration and documentation showing ingress and egress support (5.3.1), kubectl get networkpolicy -A -o yaml, the per-namespace check above (expected output: empty), connectivity tests demonstrating blocked and allowed paths, and service-mesh policy/status where applicable.

6.4 CIS 5.4 - Secrets management (2 recommendations, both Level 2)

CIS 5.4.1: prefer mounting secrets as files rather than injecting them as environment variables, because applications commonly log their environment. The benchmark's audit looks for workload objects that reference secretKeyRef. Mounted files also allow secret updates without a pod restart.

CIS 5.4.2: consider external secret storage instead of using Kubernetes Secrets directly where secret management needs are more complex; the solution should require authentication, audit access to secrets and encrypt them.

Encryption at rest is not part of CIS 5.4. Encryption of Secrets in etcd is covered by CIS 1.2.27 and 1.2.28 (guide section 5.2) and is normally demonstrated with provider evidence.

Haven+ mechanism: OpenBao provides an open-source, Vault-compatible central secrets backend; External Secrets Operator can synchronize scoped secrets from OpenBao (or another backend) using Kubernetes authentication; Sealed Secrets can store encrypted secret material declaratively in Git. Haven+ documentation recommends OpenBao to avoid unnecessary cloud-provider coupling and recommends designated platform services rather than secrets in application code/images/unsecured configuration. Note that External Secrets Operator synchronizes into native Kubernetes Secrets, so CIS 5.4.1 still depends on how workloads consume those Secrets.

Must configure yourself/provider:

Choose and harden the secret backend (CIS 5.4.2). For Haven+ OpenBao, configure HA, tenant-scoped roles/policies, audit logging and protected backups; for production, use a KMS/HSM/PKCS#11/KMIP/OpenBao-Transit or equivalent external unseal mechanism instead of keeping the unseal key only as a Secret in the same cluster.
Prefer workload identity over long-lived static credentials.
Restrict Kubernetes Secret RBAC (CIS 5.1.2).
Mount secrets as files (volume mounts) rather than injecting them as environment variables (CIS 5.4.1); record and time-bound exceptions where an application cannot read files.
Enable/verify provider-supported encryption at rest for Kubernetes secrets/etcd (CIS 1.2.27/1.2.28, provider layer).
Establish rotation and incident procedures.
Prevent plaintext secrets in Git/CI logs.

Test:

# CIS 5.4.1: workloads that take secrets from environment variables (review each hit)
kubectl get pods,deployments,statefulsets,daemonsets,jobs,cronjobs -A -o json | jq -r '.items[] | select([.. | objects | select(has("secretKeyRef") or has("secretRef"))] | length > 0) | "\(.kind)/\(.metadata.namespace)/\(.metadata.name)"'

Evidence artifact: the 5.4.1 query output with approved exceptions; ExternalSecret/SecretStore manifests without secret values, backend authentication/audit/encryption configuration and policy export (5.4.2); RBAC tests; provider encryption configuration (1.2.27/1.2.28); rotation record; repository secret-scanning evidence.

6.5 CIS 5.5 - Extensible admission control (1 recommendation, Level 2)

Requirement summary: CIS 5.5.1 is titled Configure Image Provenance using ImagePolicyWebhook admission controller. It asks that provenance rules exist so that only approved images are deployed; the benchmark's audit is to review pod definitions and verify that image provenance is configured as appropriate. By default image provenance is not set.

Haven+ mechanism: Haven+ uses Kyverno as its admission controller and policy engine. Kyverno policies are managed as code and deployed through Flux/GitOps. Kyverno can validate incoming resources, mutate resources and generate resources. For image governance, use Kyverno policies appropriate to the organization's provenance requirements, such as restricting approved registries and, where required, verifying signed images/attestations.

How to state this honestly in an audit. The recommendation's title names the ImagePolicyWebhook admission plugin, which is an API-server setting and is typically not tenant-configurable on managed Kubernetes. Kyverno delivers the same intent (approved-image enforcement) through a different mechanism. Record it as an equivalent-outcome control, do not claim ImagePolicyWebhook is deployed unless it is, and note the assessor's acceptance in the Exception field.

Do not describe Haven+ as relying on Kubernetes-native ValidatingAdmissionPolicy for this control unless that mechanism is separately deployed. Kubernetes-native admission mechanisms may exist in a cluster, but Kyverno is the Haven+ implementation mechanism.

Must configure yourself:

Define the Kyverno policies that implement the required admission and image-provenance rules.
Run security-critical validation policies in enforcement mode where appropriate rather than audit-only mode.
Define controlled exceptions with owner, rationale and expiry.
Protect the Git repository and review process for Kyverno policy changes.
Monitor Kyverno controller/policy health and admission failures, and confirm the webhook failure behavior (fail-open versus fail-closed) is a documented decision.

Test:

# Kyverno installation and health
kubectl get pods -A -l app.kubernetes.io/part-of=kyverno
kubectl get deployments -A | grep -i kyverno

# Kyverno policy resources (list the kinds available in this version, then export them)
kubectl api-resources --api-group=kyverno.io -o name
kubectl api-resources --api-group=policies.kyverno.io -o name 2>/dev/null
kubectl get clusterpolicies.kyverno.io,policies.kyverno.io -A -o yaml

# Admission registration used by Kyverno
kubectl get validatingwebhookconfigurations,mutatingwebhookconfigurations -o yaml

# Policy reports (where reporting is enabled)
kubectl get policyreports.wgpolicyk8s.io,clusterpolicyreports.wgpolicyk8s.io -A -o yaml 2>/dev/null

Newer Kyverno releases introduce additional policy kinds under the policies.kyverno.io API group; export whichever kinds kubectl api-resources lists, not only ClusterPolicy/Policy.

Also retain the Git-managed Kyverno policy manifests, Flux reconciliation status, policy/admission reports where enabled, and a negative test showing that a non-compliant resource or image is rejected.

Expected result: the required admission and image-governance rules are represented by approved Kyverno policies, active in the cluster and demonstrably enforced; exceptions are explicit, approved and time-bounded; the equivalent-outcome rationale for CIS 5.5.1 is recorded.

6.6 CIS 5.6 - General policies (4 recommendations)

CIS 5.6 covers general cluster management topics such as namespace practices and policies applied to pod objects.

CIS ID	Level	Requirement summary	Haven+ / platform mechanism	Test
5.6.1	1	Create administrative boundaries between resources using namespaces	Namespaces with RBAC per team/environment, managed via GitOps	Namespace inventory + RBAC per namespace
5.6.2	2	Set the seccomp profile in pod definitions (the benchmark's audit and remediation use `seccompProfile.type: RuntimeDefault`, although the title says `docker/default`)	Kyverno policy requiring or mutating `RuntimeDefault` (also PSA `restricted`)	Pod spec inspection + denied test
5.6.3	2	Apply security contexts to pods and containers	Kyverno rules requiring security-context settings (see guide section 6.2)	Pod spec inspection + policy report
5.6.4	2	The `default` namespace should not be used	Kyverno rule denying workload creation in `default`; exceptions documented	`kubectl get all -n default` (expect only system objects such as the `kubernetes` Service) + denied test

Haven+ mechanism: Kyverno is the primary enforcement mechanism for these policies, together with Kubernetes namespaces, workload securityContext settings, RBAC and the platform's GitOps baseline. Where Pod Security Admission is also enabled, treat it as an additional Kubernetes control; do not present it as Haven+'s primary admission-policy engine.

Must configure yourself:

Create administrative boundaries with namespaces and associated RBAC (CIS 5.6.1).
Require a seccomp profile on pods (CIS 5.6.2) and appropriate pod/container security contexts (CIS 5.6.3).
Prevent application workloads from using the default namespace unless explicitly justified (CIS 5.6.4).
Encode enforceable guardrails in Kyverno and manage them through GitOps.
Maintain explicit, reviewed exceptions for workloads that cannot meet the baseline.

Test:

# CIS 5.6.1 / 5.6.4
kubectl get namespaces
kubectl get all -n default

# CIS 5.6.2: pods without a pod-level seccomp profile (container-level settings may still apply; review hits)
kubectl get pods -A -o json | jq -r '.items[] | select(.spec.securityContext.seccompProfile == null) | "\(.metadata.namespace)/\(.metadata.name)"'

Evidence artifact: namespace inventory, workload manifests, securityContext/seccomp inspection, Kyverno policy export, policy/admission reports, Git history and negative admission tests.

Expected result: workloads are separated into appropriate namespaces, a seccomp profile and required security contexts are enforced or verified, use of the default namespace is controlled, and Kyverno policies provide repeatable admission-time enforcement for the Haven+ baseline.

7. Haven+ controls that strengthen evidence but are not direct CIS passes

7.1 GitOps and configuration integrity

Haven+ architecture principles use Git as the source of truth and favor declarative management. For CIS evidence this gives you:

exact configuration version/commit;
peer review history;
traceability from change request to deployment;
evidence of desired-state reconciliation;
a repeatable way to re-create security controls.

Evidence package: repository URL/name, commit SHA, pull/merge request approval, reconciliation status, protected-branch settings and release/promotion record.

7.2 Observability and audit evidence

Alloy, Loki, Mimir, Tempo and Grafana provide a central observability stack. Use OpenTelemetry standards and protocols wherever technically possible for telemetry generation, collection and transport. The Haven+ Overview states that by standardizing on its components, Haven+ implicitly standardizes on OpenTelemetry (as well as OpenID Connect and the Gateway API); it is a consequence of component choice, not a separately enforced requirement. This reduces product coupling and gives security/audit evidence a consistent transport model across logs, metrics and traces. Loki's Haven+ documentation stated a default retention of 31 days (configurable by overlay; confirm the current default in the Haven+ documentation). Set retention to organizational/legal requirements rather than relying blindly on the default.

For CIS-relevant auditability (CIS 3.2.1 and 3.2.2), ensure that Kubernetes/provider audit logs are actually delivered to the stack or another protected log service. Container logs alone are not Kubernetes API audit logs.

Evidence artifact: log-source inventory, pipeline config, retention config, sample security event, access-control test, alert test and time-synchronization evidence.

7.3 TLS and certificates

cert-manager automates certificate issuance and renewal, which supports a secure-by-default platform but does not prove every CIS control-plane TLS requirement. Control-plane certificates are generally provider-owned in managed Kubernetes.

Evidence artifact: ClusterIssuer/Issuer configuration, certificate inventory, renewal status/alerts and ingress/gateway TLS configuration.

7.4 Backup and recovery

Velero supports backup and restore of Kubernetes resources and persistent volumes and uses S3/S3-compatible storage in the Haven+ reference implementation. Backup is operationally important but is not a substitute for CIS hardening.

Evidence artifact: backup schedule, successful backup records, object-storage protection, encryption configuration and periodic restore-test report.

8. Managed Kubernetes: provider evidence strategy

When a public-cloud provider supplies the Haven cluster as a managed service, create a shared-responsibility matrix before testing.

Control area (CIS)	Provider evidence	Tenant/Haven evidence
Control-plane file permissions (1.1)	Provider CIS/security assurance	Managed-service identity + version in scope
API-server flags (1.2)	Provider configuration/docs or provider-specific benchmark	Tenant-exposed API settings, RBAC, identity
Secrets encryption at rest (1.2.27, 1.2.28)	KMS/encryption configuration and attestation	Enablement confirmation where tenant-configurable
etcd TLS/permissions (2)	Provider assurance	Usually none
Scheduler/controller manager (1.3, 1.4)	Provider assurance	Usually none
User authentication methods (3.1)	Identity integration capability; whether client-certificate/token access is exposed	OIDC configuration, kubeconfig issuance, CSR and token review
Audit policy and logs (3.2)	Control-plane audit log export capability and policy documentation	Enablement, ingestion, retention, review
Node/kubelet (4.1, 4.2)	Node-pool/image configuration; provider docs	Tenant-exposed kubelet/node settings, update policy
kube-proxy (4.3)	Networking mode and kube-proxy configuration	Confirmation of mode; `N/A - not applicable` where kube-proxy is not used
Identity/RBAC (5.1)	Identity integration capability	Roles, bindings, access tests/reviews
Pod security (5.2)	N/A unless provider imposes guardrails	Kyverno/PSA policies and workload manifests
Network policy (5.3)	CNI capability/config (ingress and egress)	NetworkPolicy in every namespace and connectivity tests
Secrets management (5.4)	Encryption/KMS capability	ESO/OpenBao/Sealed Secrets, RBAC, backend policies, file-mount usage
Image provenance (5.5)	`ImagePolicyWebhook` availability, if any	Kyverno image policies and negative tests
General policies (5.6)	N/A unless provider imposes guardrails	Namespaces, seccomp, security contexts, `default` namespace control

8.1 Do not use "provider managed" as a blank exemption

For every provider-owned control, retain evidence of why it is provider-owned and what assurance replaces direct inspection. If the provider offers a provider-specific CIS benchmark, use that benchmark for the managed service and cross-reference it from the generic Kubernetes evidence register.

9. Practical evidence collection runbook

Run evidence collection from a dedicated read-only audit identity where possible. Ensure that the identity has sufficient RBAC permissions to list the required namespaced and cluster-scoped resources, without create, update, patch or delete privileges. Store outputs in a dated, access-controlled evidence location, and hash each output file (for example sha256sum) at capture time.

# Cluster and versions
kubectl version -o yaml
kubectl get nodes -o wide

# RBAC (CIS 5.1)
kubectl get roles,rolebindings -A -o yaml
kubectl get clusterroles,clusterrolebindings -o yaml

# Service accounts (CIS 5.1.5, 5.1.6)
kubectl get serviceaccounts -A -o yaml
kubectl get pods -A \
  -o custom-columns='NS:.metadata.namespace,POD:.metadata.name,SA:.spec.serviceAccountName'

# Namespaces and Pod Security Admission labels (CIS 5.2.1, 5.6.1)
kubectl get namespaces --show-labels

# Workload security configuration (CIS 5.2, 5.6)
kubectl get pods -A -o yaml

# Network policies (CIS 5.3)
kubectl get networkpolicies -A -o yaml

# Admission webhooks (CIS 5.2.1, 5.5.1)
kubectl get validatingwebhookconfigurations,mutatingwebhookconfigurations -o yaml

# Kyverno policies and reports (CIS 5.2, 5.5.1, 5.6)
kubectl get pods -A -l app.kubernetes.io/part-of=kyverno
kubectl api-resources --api-group=kyverno.io -o name
kubectl api-resources --api-group=policies.kyverno.io -o name 2>/dev/null
kubectl get clusterpolicies.kyverno.io,policies.kyverno.io -A -o yaml 2>/dev/null || true
kubectl get policyreports.wgpolicyk8s.io,clusterpolicyreports.wgpolicyk8s.io -A -o yaml 2>/dev/null || true

# Validating Admission Policies (where supported/in use)
kubectl get validatingadmissionpolicies,validatingadmissionpolicybindings -o yaml 2>/dev/null || true

# Secret-management objects (CIS 5.4; protect and review outputs for sensitive configuration)
kubectl get externalsecrets,secretstores,clustersecretstores -A -o yaml 2>/dev/null || true
kubectl get sealedsecrets -A -o yaml 2>/dev/null || true

# GitOps reconciliation status (guide section 7.1)
kubectl get kustomizations.kustomize.toolkit.fluxcd.io,helmreleases.helm.toolkit.fluxcd.io -A 2>/dev/null || true
kubectl get applications.argoproj.io -A 2>/dev/null || true

# TLS, backup and mesh objects (guide sections 7.3, 7.4, 6.3)
kubectl get clusterissuers.cert-manager.io,issuers.cert-manager.io,certificates.cert-manager.io -A 2>/dev/null || true
kubectl get backups.velero.io,schedules.velero.io -A 2>/dev/null || true
kubectl get peerauthentications.security.istio.io,authorizationpolicies.security.istio.io -A 2>/dev/null || true

# Haven+ component inventory
kubectl get pods -A

Caution: Kubernetes YAML exports can contain sensitive material. Never place raw Secret data values or provider credentials in an audit bundle. Workload exports (kubectl get pods -A -o yaml) can contain literal environment-variable values; redact or collect metadata-only evidence where necessary.

9.1 Automated assessment

Use an assessment tool that explicitly supports the exact benchmark/version in scope. Prefer an open-source toolchain where it meets the required coverage. Because 67 of the 131 recommendations (including all of sections 3 and 5) are Manual in the benchmark, no scanner produces a complete result on its own.

kube-bench (Apache-2.0) - purpose-built to execute checks from the CIS Kubernetes Benchmark. It is strongest when it can inspect node/control-plane processes and configuration; on managed Kubernetes some checks will be inaccessible/provider-owned. kube-bench also provides managed-service-specific targets (for example GKE, EKS and AKS); use the target matching your provider and service model. Confirm the target list and benchmark-version support in the current kube-bench documentation.
Kubescape (Apache-2.0; CNCF incubating project) - scans live clusters, YAML and Helm charts against CIS and other frameworks; suitable for CI/CD and continuous in-cluster scanning, with JSON/JUnit/SARIF-style automation options depending on mode/version.
Trivy / Trivy Operator (Apache-2.0) - supports Kubernetes configuration/compliance scanning and can run continuously as an operator; useful when vulnerability, configuration and compliance findings should share one open-source pipeline.
Wazuh (open source) - can use Security Configuration Assessment policies for CIS-style checks and can combine findings with broader SIEM/XDR workflows. Treat its benchmark policy coverage as something to validate against the exact CIS version/profile in scope.

For policy enforcement rather than benchmark scanning, Kyverno (the Haven+ policy engine) or OPA Gatekeeper can enforce organization-specific controls at admission time. Their deny/audit events and Kyverno policy reports can complement CIS scanner results but are not, by themselves, a full CIS benchmark assessment.

Tool-to-benchmark coverage record. Before an assessment, fill in this table and retain it with the scan output. Only Wazuh and CIS-CAT Pro coverage of v2.0.1 is cited in this guide's sources; do not assume the other tools cover v2.0.1 or its renumbered recommendations.

Tool	Version used	Benchmark and version it implements	Profile levels covered	Checks skipped/unsupported	Evidence of coverage claim
kube-bench
Kubescape
Trivy Operator
Wazuh SCA
CIS-CAT Pro

Recommended operating model: scan manifests in CI before merge; run a live-cluster scan on a schedule and after material platform upgrades; run kube-bench only where the required host/control-plane access exists. Send developer-owned findings back to the PR/pipeline, and route platform/baseline findings to the platform team. Feed findings, policy events and scanner health into the central observability stack; use OpenTelemetry-compatible collection/transport where possible, and alert via Grafana/Alertmanager or the organization's ticket/incident channel. Retain tool version, benchmark version, scan scope, raw result, exception decision and remediation reference as evidence.

Do not treat a scanner's green percentage as the entire audit conclusion. Managed services can return inaccessible/not-applicable checks, and manual controls still require evidence.

10. Evidence register template

Use one row per recommendation (131 rows for CIS Kubernetes Benchmark v2.0.1 at full scope). Status values must strictly match the vocabulary in section 2.1. The table below is the condensed register. Each row's Record column points to the full evidence record described in section 3, which holds the remaining fields (Alerting, Expected result, Integrity, Timestamp and versions, Reviewed) using the same field names as Appendix C.

The rows below are illustrative examples only (the status values are not real results). Grouped ranges such as 1.2.6 - 1.2.8 are acceptable in a working document for shared evidence, but the register submitted to an auditor should carry one row per recommendation.

CIS ID	Requirement summary	CIS profile / assessment	Applicability	Responsible layer	Implementation	Test	Evidence artifact	Status	Owner	Exception	Record
1.1.1	API server pod spec file permissions	L1 Master / Automated	N/A - provider managed	Provider	Managed Kubernetes	Provider benchmark/assurance	Provider evidence pack	N/A - provider managed	Provider manager	-	REC-1.1.1
3.1.1	No client-cert authentication for users	L1 Master / Manual	Applicable	Haven+	Pinniped/Keycloak OIDC	Kubeconfig + CSR + audit-log review	OIDC config, review record	MANUAL	Platform IAM	Ticket/date	REC-3.1.1
5.1.1	cluster-admin only where required	L1 Master / Manual	Applicable	Haven	Git-managed RBAC	RBAC export + `auth can-i`	`rbac-YYYYMMDD.yaml`	PASS	Platform IAM	Ticket/date	REC-5.1.1
5.2.1	Active policy control mechanism	L1 Master / Manual	Applicable	Haven+	Kyverno (+ optional PSA)	Policy export + namespace coverage	Policy YAML, coverage list	PASS	Platform security	Ticket/date	REC-5.2.1
5.2.2	Minimize privileged containers	L1 Master / Manual	Applicable	Haven+ / Workload	Kyverno enforce (+ optional PSA)	Denied test + scan	Policy report	FAIL	Platform security	Ticket/date	REC-5.2.2
5.3.2	NetworkPolicy in every namespace	L2 Master / Manual	Applicable	Haven / Provider	Enforcing CNI + generated baseline policy	Per-namespace check + connectivity test	NP YAML + test log	PARTIAL	Platform network	Ticket/date	REC-5.3.2
5.4.1	Secrets as files, not env vars	L2 Master / Manual	Applicable	Workload	ESO-synced Secrets mounted as volumes	`secretKeyRef` query	Query output	PARTIAL	App owners	Ticket/date	REC-5.4.1
5.5.1	Image provenance	L2 Master / Manual	Applicable	Haven+	Kyverno image policies (equivalent-outcome)	Negative test with unapproved image	Policy YAML + denial log	MANUAL	Platform security	Assessor acceptance	REC-5.5.1
5.6.4	`default` namespace not used	L2 Master / Manual	Applicable	Haven+ / Workload	Kyverno deny rule	`kubectl get all -n default` + denied test	Output + policy	PASS	Platform security	Ticket/date	REC-5.6.4

11. Minimum audit package

A defensible evidence package should contain:

Scope statement - cluster IDs/names, environment, Kubernetes versions, provider/service model.
Benchmark statement - CIS Kubernetes Benchmark version/profile (Level 1 or Level 2) and any provider-specific benchmark.
Shared-responsibility matrix - provider vs Haven vs Haven+ vs workloads.
Control evidence register - one row per applicable CIS recommendation (131 in v2.0.1 at full scope).
Automated assessment output - exact tool and benchmark versions, and the tool coverage record from section 9.1.
Configuration evidence - Git commit references, Kubernetes exports and provider settings, with capture-time hashes as described in section 3.
Identity/RBAC review - privileged identities and approval, including CIS 3.1 and 5.1.7 - 5.1.13 findings.
Negative enforcement tests - examples of denied privileged pod/network/access/image behavior.
Exceptions register - rationale, compensating controls (including equivalent-outcome controls such as Kyverno for CIS 5.5.1), owner and expiry.
Reassessment record - after Kubernetes/provider/Haven+ upgrades and at the defined periodic cadence (recommended default: at least quarterly).

12. Recommended implementation baseline for a Haven+ managed cluster

A practical target baseline is:

Managed Kubernetes service with provider-specific CIS guidance/assurance.
Private cluster/network topology where feasible and consistent with Haven requirements.
Supported/current Kubernetes and node versions with defined upgrade cadence.
Central human identity via OIDC/provider IdP; no routine static admin credentials and no client-certificate or service-account-token access for users (CIS 3.1).
Least-privilege RBAC managed through GitOps; break-glass separated and audited; no system:masters bindings and reviewed bind/impersonate/escalate grants (CIS 5.1).
Dedicated service accounts; token automount disabled where API access is unnecessary.
Kyverno as the admission policy engine for pod-security, general-policy and image-governance rules, in enforce mode for security-critical rules, with time-bounded exceptions and a documented webhook failure mode (CIS 5.2, 5.5.1, 5.6).
Pod Security Admission restricted for normal application namespaces as defense in depth, alongside Kyverno.
Seccomp RuntimeDefault and required security contexts on all workloads; no workloads in the default namespace (CIS 5.6).
CNI with ingress and egress NetworkPolicy enforcement; default-deny baseline for application namespaces and at least one NetworkPolicy in every namespace (CIS 5.3).
Istio mTLS/L7 authorization as defense in depth where used.
OpenBao as the preferred cloud-agnostic central secret backend, integrated with External Secrets Operator where appropriate; Sealed Secrets where encrypted Git delivery is required; secrets consumed as mounted files rather than environment variables; all with restrictive Secret RBAC and production-grade key/unseal protection (CIS 5.4).
Provider encryption at rest for Secrets enabled/verified where configurable (CIS 1.2.27, 1.2.28).
Central logs/metrics/traces; Kubernetes audit logs ingested when available; audit policy documented; retention defined (CIS 3.2).
Automated TLS lifecycle with cert-manager and renewal monitoring.
Velero backup schedules plus regular restore testing.
CIS scan and evidence-register refresh after material platform changes and periodically (recommended default: at least quarterly).

13. Sources

This guide deliberately paraphrases CIS requirements rather than reproducing the benchmark; CIS asks that anyone quoting portions of the benchmark in third-party documentation contact CIS Legal, and the benchmark document must not be hosted on non-CIS sites. For formal assessment, validate every ID, profile, applicability and exact audit/remediation step against the licensed/current CIS Kubernetes Benchmark v2.0.1. Links and page contents change; re-verify each URL and each version-specific claim before distributing an audit package that relies on them.

Primary/current sources consulted:

Center for Internet Security, CIS Kubernetes Benchmark v2.0.1 (document dated 29 April 2026, Kubernetes v1.34 - v1.35) - the authority for all CIS identifiers and wording: https://www.cisecurity.org/benchmark/kubernetes
Center for Internet Security, CIS Benchmarks June 2026 Update - announcement of the benchmark release (where it differs from the benchmark document, the benchmark document prevails): https://www.cisecurity.org/insights/blog/cis-benchmarks-june-2026-update
Haven, Checks - 15 mandatory and 2 suggested checks; CIS Kubernetes and Kubescape are suggested checks: https://haven.commonground.nl/techniek/checks
Haven+, Overview - reference implementation components and capabilities (component list; does not include Kyverno and OpenBao, which appear in the Components index): https://havenplus.commonground.nl/docs/overview/
Haven+, Components - index listing Kyverno, OpenBao and other components: https://havenplus.commonground.nl/docs/category/components
Haven+, Kyverno component page (listed in the components index): https://havenplus.commonground.nl/docs/components/kyverno
Haven+, Architecture Principles - security by default, GitOps, observability and responsibility separation: https://havenplus.commonground.nl/docs/haven-plus-architecture-principles/
Haven+, External Secrets Operator: https://havenplus.commonground.nl/docs/components/external-secrets-operator/
Haven+, OpenBao: https://havenplus.commonground.nl/docs/components/openbao/
Haven+, OpenBao Unseal Mechanisms: https://havenplus.commonground.nl/docs/guides/openbao-auto-unseal/
Haven+, Loki - includes configurable retention (default documented as 31 days): https://havenplus.commonground.nl/docs/components/loki/
Haven+, Velero - backup/restore implementation: https://havenplus.commonground.nl/docs/components/velero/
Aqua Security, kube-bench: https://github.com/aquasecurity/kube-bench
Kubescape, open-source Kubernetes security platform (CNCF incubating project since February 2025): https://github.com/kubescape/kubescape
Aqua Security, Trivy / Trivy Operator: https://github.com/aquasecurity/trivy
Kyverno project: https://kyverno.io
Wazuh, Scanning Kubernetes infrastructure against CIS Benchmark with Wazuh (6 Aug 2026) - example v2.0.1 assessment coverage: https://wazuh.com/blog/scanning-kubernetes-infrastructure-against-cis-benchmark-with-wazuh/
CIS-CAT Pro Assessor change log - v2.0.1 benchmark coverage: https://ciscat-assessor.docs.cisecurity.org/en/latest/Change%20Log/

Appendix A - CIS-to-guide mapping

Use this table to navigate the guide and to populate the evidence register. Identifiers, titles and counts follow the CIS Kubernetes Benchmark v2.0.1 (see the validation note at the top of this guide); confirm them against the licensed benchmark before formal assessment. The benchmark has 131 recommendations: 60 + 7 + 5 + 25 + 34.

CIS section	Topic (recommendations)	Guide section	Default responsible layer	Typical situation on a managed cluster
1.0	29 September 2026	First public release.
1.4	Scheduler (2)	5.3	Provider (managed) or cluster operator (self-managed)	`N/A - provider managed`
2	etcd (7: 2.1 - 2.7)	5.4	Provider (managed) or cluster operator (self-managed)	`N/A - provider managed`
3.1	Authentication and authorization: client-certificate, service-account-token and bootstrap-token authentication not used for users (3)	5.5	Haven+ (OIDC) + provider	Mixed; review-based (all Manual)
3.2	Logging: minimal audit policy, audit policy covers key security concerns (2; 3.2.2 is Level 2)	5.5	Provider + platform team (tenant-side log export/retention)	Mixed
4.1	Worker node configuration files (10)	5.6	Provider (node image/pool) or cluster operator (self-managed)	Provider evidence, or node-level scans if self-managed
4.2	Kubelet (14)	5.6	Provider (node pool) or cluster operator (self-managed)	As above
4.3	kube-proxy (1: 4.3.1)	5.6	Provider or cluster operator	Confirm networking mode; `N/A - not applicable` if kube-proxy is not used
5.1	RBAC and service accounts (13: 5.1.1 - 5.1.13)	6.1	Haven + Workloads	PASS/FAIL after review of RBAC exports and `auth can-i` tests
5.2	Pod Security Standards (12: 5.2.1 - 5.2.12; 5.2.7 and 5.2.9 are Level 2)	6.2	Haven+ (Kyverno) + Haven (PSA) + Workloads	PASS/FAIL after review of policy exports, negative tests and scans
5.3	Network policies and CNI (2; 5.3.2 is Level 2)	6.3	Haven + provider (CNI capability)	PASS/FAIL via per-namespace policy check and connectivity tests
5.4	Secrets management (2, both Level 2)	6.4	Haven+ (OpenBao/ESO) + Workloads	Often MANUAL/PARTIAL; combine backend, RBAC and file-mount evidence. Encryption at rest is 1.2.27/1.2.28, not 5.4
5.5	Extensible admission control: image provenance via ImagePolicyWebhook (1, Level 2)	6.5	Haven+ (Kyverno) / provider	Kyverno image policies as an equivalent-outcome control; assessor acceptance recorded
5.6	General policies (4: 5.6.1 - 5.6.4; 5.6.2 - 5.6.4 are Level 2)	6.6	Haven+ (Kyverno) + Haven + Workloads	Namespace/seccomp/security-context/`default` namespace evidence plus Kyverno enforcement and negative tests

Appendix B - Workload-owner checklist

Workload teams are a full responsibility layer (section 1.1). Before requesting a compliance sign-off, a workload owner should be able to check every item below and point to evidence.

Pod security (CIS 5.2)

Namespace is covered by an active policy control mechanism (Kyverno policies and/or PSA restricted), or has a documented exception with ticket and expiry (CIS 5.2.1).
No privileged: true, no hostPID / hostIPC / hostNetwork, no hostPath volumes and no hostPort (CIS 5.2.2 - 5.2.5, 5.2.11, 5.2.12; exceptions documented).
allowPrivilegeEscalation: false on all containers (CIS 5.2.6).
runAsNonRoot: true set at pod and/or container level; the image runs as a non-root UID (CIS 5.2.7, Level 2).
Capabilities: drop: ["ALL"]; NET_RAW is not granted; any added capability is justified in a ticket (CIS 5.2.8, 5.2.9).
No Windows hostProcess containers (CIS 5.2.10), or the cluster has no Windows nodes.

General policies (CIS 5.6)

Workload runs in its own namespace, not default (CIS 5.6.1, 5.6.4).
Seccomp profile RuntimeDefault (or an approved custom profile) at pod level (CIS 5.6.2).
Security context defined for pods and containers as required by the platform baseline (CIS 5.6.3).

Image provenance (CIS 5.5)

Images come from approved registries and, where the platform requires it, are signed/attested so they pass the Kyverno image policy (CIS 5.5.1).

Service accounts and RBAC (CIS 5.1)

Dedicated service account per workload; application pods do not run as default (CIS 5.1.5).
automountServiceAccountToken: false unless the workload needs the Kubernetes API; if enabled, justification recorded (CIS 5.1.6).
RBAC for the workload's service account is least-privilege: no wildcards, no Secret access unless required, no bind/impersonate/escalate, no access to nodes/proxy, CSR approval, webhook configuration, persistent volume creation or service account token creation unless justified (CIS 5.1.2, 5.1.3, 5.1.7 - 5.1.13).

Secrets (CIS 5.4)

No plaintext secrets in Git, CI variables or container images.
Secrets delivered via External Secrets Operator, Sealed Secrets or another platform-approved mechanism (CIS 5.4.2).
Secrets are mounted as files rather than passed through secretKeyRef/secretRef environment variables; exceptions are documented (CIS 5.4.1, Level 2).

Networking (CIS 5.3)

The namespace has at least one NetworkPolicy; default-deny is understood and required ingress/egress is declared explicitly (CIS 5.3.2).
Connectivity verified after policy changes.

Evidence readiness

Deployment/manifest repository path and latest commit SHA recorded.
Policy/scan findings for the workload triaged (no unowned FAILs).
Exceptions registered with owner and expiry.

Appendix C - Audit-ready control statement template

For each CIS requirement, use this exact structure in your audit file. The field names are identical to the evidence schema in section 3 and the register in section 10.

CIS <ID> - <short requirement> CIS profile and assessment status: <Level 1 / Level 2, Master Node / Worker Node, Automated / Manual> Applicability: <Applicable / N/A - provider managed / N/A - not applicable> Responsible layer: <Provider / Haven / Haven+ / Workload> Implementation: <technical control> Test: <command/test/scanner/review procedure> Alerting: <where findings/events are routed, or "not applicable"> Expected result: <objective pass condition> Evidence artifact: <artifact path/report/Git SHA/provider export> Integrity: <SHA-256 hash(es) and storage location> Timestamp and versions: <date/time, cluster version, component versions> Status: <PASS / FAIL / PARTIAL / MANUAL / N/A - provider managed / N/A - not applicable> Owner: <person/team> Reviewed: <date, reviewer> Exception: <ticket, owner, expiry, compensating control or equivalent-outcome rationale>

1. Executive summary​

1.1 Responsibility layers​

2. Scope and benchmark selection​

2.1 Status vocabulary​

3. The evidence model: how to prove one CIS requirement​

3.1 Example: RBAC authorization (CIS 1.2.6 - 1.2.8 and CIS 5.1.1)​

3.2 Example: privileged workloads (CIS 5.2.1 and CIS 5.2.2)​

4. Haven+ capabilities and their CIS value​

5. CIS control families 1 - 4: responsibility and evidence​

5.1 Control-plane node configuration files (CIS 1.1)​

5.2 API server (CIS 1.2)​

5.3 Controller manager and scheduler (CIS 1.3 and 1.4)​

5.4 etcd (CIS 2)​

5.5 Control-plane configuration (CIS 3)​

5.5.1 Authentication methods for users (CIS 3.1.1 - 3.1.3, Level 1)​

5.5.2 Logging and audit policy (CIS 3.2.1 Level 1, CIS 3.2.2 Level 2)​

5.6 Worker nodes: configuration files, kubelet and kube-proxy (CIS 4.1, 4.2 and 4.3)​

6. Kubernetes policy controls (CIS section 5) where Haven+ and the platform team matter most​

6.1 CIS 5.1 - RBAC and service accounts (13 recommendations, Level 1)​

CIS 5.1.1 High-privilege / cluster-admin use​

CIS 5.1.2 Minimize access to secrets​

CIS 5.1.3 Minimize wildcard permissions​

CIS 5.1.4 Minimize pod creation permissions​

CIS 5.1.5 Default service account usage​

CIS 5.1.6 Service-account token mounting​

CIS 5.1.7 - 5.1.13 Privilege-escalation paths through RBAC​

6.2 CIS 5.2 - Pod Security Standards (12 recommendations)​

6.3 CIS 5.3 - Network policies and CNI (2 recommendations)​

6.4 CIS 5.4 - Secrets management (2 recommendations, both Level 2)​

6.5 CIS 5.5 - Extensible admission control (1 recommendation, Level 2)​

6.6 CIS 5.6 - General policies (4 recommendations)​

7. Haven+ controls that strengthen evidence but are not direct CIS passes​

7.1 GitOps and configuration integrity​

7.2 Observability and audit evidence​

7.3 TLS and certificates​

7.4 Backup and recovery​

8. Managed Kubernetes: provider evidence strategy​

8.1 Do not use "provider managed" as a blank exemption​

9. Practical evidence collection runbook​

9.1 Automated assessment​

10. Evidence register template​

11. Minimum audit package​

12. Recommended implementation baseline for a Haven+ managed cluster​

13. Sources​

Appendix A - CIS-to-guide mapping​

Appendix B - Workload-owner checklist​

Appendix C - Audit-ready control statement template​

1. Executive summary

1.1 Responsibility layers

2. Scope and benchmark selection

2.1 Status vocabulary

3. The evidence model: how to prove one CIS requirement

3.1 Example: RBAC authorization (CIS 1.2.6 - 1.2.8 and CIS 5.1.1)

3.2 Example: privileged workloads (CIS 5.2.1 and CIS 5.2.2)

4. Haven+ capabilities and their CIS value

5. CIS control families 1 - 4: responsibility and evidence

5.1 Control-plane node configuration files (CIS 1.1)

5.2 API server (CIS 1.2)

5.3 Controller manager and scheduler (CIS 1.3 and 1.4)

5.4 etcd (CIS 2)

5.5 Control-plane configuration (CIS 3)

5.5.1 Authentication methods for users (CIS 3.1.1 - 3.1.3, Level 1)

5.5.2 Logging and audit policy (CIS 3.2.1 Level 1, CIS 3.2.2 Level 2)

5.6 Worker nodes: configuration files, kubelet and kube-proxy (CIS 4.1, 4.2 and 4.3)

6. Kubernetes policy controls (CIS section 5) where Haven+ and the platform team matter most

6.1 CIS 5.1 - RBAC and service accounts (13 recommendations, Level 1)

CIS 5.1.1 High-privilege / cluster-admin use

CIS 5.1.2 Minimize access to secrets

CIS 5.1.3 Minimize wildcard permissions

CIS 5.1.4 Minimize pod creation permissions

CIS 5.1.5 Default service account usage

CIS 5.1.6 Service-account token mounting

CIS 5.1.7 - 5.1.13 Privilege-escalation paths through RBAC

6.2 CIS 5.2 - Pod Security Standards (12 recommendations)

6.3 CIS 5.3 - Network policies and CNI (2 recommendations)

6.4 CIS 5.4 - Secrets management (2 recommendations, both Level 2)

6.5 CIS 5.5 - Extensible admission control (1 recommendation, Level 2)

6.6 CIS 5.6 - General policies (4 recommendations)

7. Haven+ controls that strengthen evidence but are not direct CIS passes

7.1 GitOps and configuration integrity

7.2 Observability and audit evidence

7.3 TLS and certificates

7.4 Backup and recovery

8. Managed Kubernetes: provider evidence strategy

8.1 Do not use "provider managed" as a blank exemption

9. Practical evidence collection runbook

9.1 Automated assessment

10. Evidence register template

11. Minimum audit package

12. Recommended implementation baseline for a Haven+ managed cluster

13. Sources

Appendix A - CIS-to-guide mapping

Appendix B - Workload-owner checklist

Appendix C - Audit-ready control statement template