Automate CIS Kubernetes Compliance

Introduction

In the rapidly evolving landscape of cloud-native technologies, securing your Kubernetes clusters isn’t just a best practice—it’s a fundamental necessity. As organizations increasingly rely on Kubernetes to orchestrate their critical applications, ensuring these environments adhere to robust security standards becomes paramount. One of the most widely recognized and respected frameworks for hardening Kubernetes is the CIS Kubernetes Benchmark. This comprehensive set of guidelines provides prescriptive recommendations for configuring Kubernetes components securely, covering everything from API server settings to node configurations.

However, manually auditing a Kubernetes cluster against hundreds of CIS Benchmark controls can be a daunting, error-prone, and time-consuming task, especially in dynamic, large-scale environments. The good news is that the cloud-native ecosystem offers powerful tools to automate this process, transforming compliance from a reactive, periodic chore into a proactive, continuous state. This guide will walk you through leveraging open-source tools to automate CIS Kubernetes Benchmark compliance, ensuring your clusters are not only secure but also consistently adhere to industry best practices.

By the end of this tutorial, you’ll have a clear understanding of how to implement automated compliance checks, interpret their results, and take corrective actions. We’ll focus on practical, hands-on examples using widely adopted tools, empowering you to build a more secure and compliant Kubernetes infrastructure.

TL;DR: Automate CIS Kubernetes Benchmark Compliance

# Deploy kube-bench (example for a worker node scan)
kubectl apply -f https://raw.githubusercontent.com/aquasecurity/kube-bench/main/job.yaml

# Check kube-bench job status and get logs
kubectl get jobs -n kube-bench
kubectl logs -f $(kubectl get pods -n kube-bench -l app=kube-bench -o jsonpath="{.items[0].metadata.name}") -n kube-bench

# Install Kyverno (using Helm)
helm repo add kyverno https://kyverno.github.io/kyverno/
helm install kyverno kyverno/kyverno -n kyverno --create-namespace

# Apply a sample Kyverno policy for CIS compliance
kubectl apply -f my-cis-policy.yaml

# Check Kyverno policies and reports
kubectl get policies -n kyverno
kubectl get policereports -n kyverno

Prerequisites

Before diving into automating CIS Kubernetes Benchmark compliance, ensure you have the following:

• A Kubernetes Cluster: An existing Kubernetes cluster (e.g., Minikube, kind, EKS, GKE, AKS) where you have administrative access. This guide assumes you have a functional cluster.
• kubectl: The Kubernetes command-line tool, configured to connect to your cluster. Refer to the official Kubernetes documentation for installation instructions.
• helm (Optional, but Recommended): The package manager for Kubernetes, useful for installing tools like Kyverno. Install Helm by following the official Helm documentation.
• Basic Kubernetes Knowledge: Familiarity with Kubernetes concepts such as Pods, Deployments, Namespaces, RBAC, and Custom Resource Definitions (CRDs).
• Understanding of CIS Benchmarks: A general understanding of what the CIS Benchmarks are and why they are important for security.

Step-by-Step Guide

This guide will walk you through two primary approaches to automate CIS Kubernetes Benchmark compliance: auditing with `kube-bench` and enforcing with `Kyverno`.

Step 1: Auditing with kube-bench

kube-bench is an open-source tool from Aqua Security that checks whether Kubernetes is deployed securely by running the checks documented in the CIS Kubernetes Benchmark. It can be run as a Pod within your cluster, directly on a node, or as a container. For cluster-wide automation, running it as a Kubernetes Job is the most convenient approach.

Explanation

We’ll deploy kube-bench as a Kubernetes Job. This Job will create a Pod that runs the necessary checks against your Kubernetes components (control plane, nodes, etcd, etc.) and then exits. The results will be available in the Pod’s logs. kube-bench needs access to host paths to inspect configurations, so it requires specific RBAC permissions and host path mounts. We’ll use a standard YAML definition provided by Aqua Security, which simplifies this setup.

First, create a dedicated namespace for kube-bench to keep things organized. Then, we’ll deploy the Job. Note that kube-bench typically scans based on the node it runs on. For a comprehensive audit, you might need to run it on each control plane and worker node, or configure it to scan remote components. We’ll start with a worker node scan.

Code Block

# 1. Create a namespace for kube-bench
kubectl create namespace kube-bench

# 2. Deploy kube-bench as a Job (this example targets worker node checks)
# For a full cluster audit, you might need to adjust the job definition
# or run it on control plane nodes as well.
kubectl apply -f https://raw.githubusercontent.com/aquasecurity/kube-bench/main/job.yaml -n kube-bench

Verify Section

After applying the YAML, a Job and a corresponding Pod will be created in the `kube-bench` namespace. It might take a moment for the Pod to start and complete its scan. You can monitor its status and then retrieve the logs.

# Check the status of the kube-bench Job
kubectl get jobs -n kube-bench

# Expected Output (Job should complete eventually)
# NAME         COMPLETIONS   DURATION   AGE
# kube-bench   1/1           40s        1m

# Get the name of the kube-bench Pod
KUBE_BENCH_POD=$(kubectl get pods -n kube-bench -l app=kube-bench -o jsonpath="{.items[0].metadata.name}")
echo "Kube-bench Pod: $KUBE_BENCH_POD"

# Stream the logs from the kube-bench Pod
kubectl logs -f $KUBE_BENCH_POD -n kube-bench

The logs will contain a detailed report of the CIS Benchmark checks, categorizing them by component (e.g., `Master Node`, `Worker Node`, `etcd`) and indicating `PASS`, `FAIL`, `WARN`, or `INFO` for each control. Look for sections like `[PASS]`, `[FAIL]`, `[WARN]`.

Step 2: Analyzing kube-bench Results

Explanation

The output from kube-bench is extensive and provides granular details about each control check. It’s crucial to understand how to interpret these results. Each check corresponds to a specific recommendation in the CIS Kubernetes Benchmark document. A `[PASS]` means your configuration aligns with the recommendation. A `[FAIL]` indicates a deviation that needs immediate attention. `[WARN]` suggests a configuration that might not be ideal but isn’t a direct failure, while `[INFO]` provides additional context.

The report also often includes remediation steps for failed checks, which are incredibly valuable for improving your cluster’s security posture. You should review all `[FAIL]` and `[WARN]` items, prioritize them based on their security impact and your organizational risk tolerance, and plan for remediation. This manual review is a critical step before moving to automated enforcement.

Code Block

There’s no new code block for this step, as it primarily involves reviewing the output from the previous step. However, you can filter the logs to quickly identify failures:

# Get the name of the kube-bench Pod again if needed
KUBE_BENCH_POD=$(kubectl get pods -n kube-bench -l app=kube-bench -o jsonpath="{.items[0].metadata.name}")

# Filter logs to show only FAILures and WARNINGs
kubectl logs $KUBE_BENCH_POD -n kube-bench | grep -E '\[FAIL\]|\[WARN\]'

Verify Section

The output will list all checks that resulted in a `[FAIL]` or `[WARN]`, along with their descriptions and sometimes remediation suggestions.

# Example filtered output (will vary based on your cluster's configuration)
# [FAIL] 1.1.1 Ensure that the --allow-privileged argument is set to false (Scored)
# [FAIL] 1.2.3 Ensure that the --authorization-mode argument is not set to AlwaysAllow (Scored)
# [WARN] 2.1.2 Ensure that the --anonymous-auth argument is set to false (Scored)
# ...

Step 3: Enforcing Compliance with Kyverno

While kube-bench helps you *audit* your existing compliance, Kyverno helps you *enforce* it. Kyverno is a policy engine designed for Kubernetes. It can validate, mutate, and generate Kubernetes resources, allowing you to define policies as Kubernetes resources themselves. This makes it ideal for enforcing CIS Benchmark recommendations by preventing non-compliant configurations from being deployed or automatically correcting them. For more advanced security measures, Kyverno can also integrate with supply chain security tools like Sigstore, as discussed in our Sigstore and Kyverno Security guide.

Explanation

First, we’ll install Kyverno into your cluster using Helm. Kyverno runs as an admission controller, intercepting API requests to your Kubernetes cluster and applying policies before resources are persisted. After installation, we’ll create a sample Kyverno policy that enforces a common CIS Benchmark recommendation, such as ensuring images come from trusted registries or disallowing privileged containers. This demonstrates how to translate a benchmark control into an actionable policy.

Code Block

# 1. Add the Kyverno Helm repository
helm repo add kyverno https://kyverno.github.io/kyverno/

# 2. Update your Helm repositories
helm repo update

# 3. Install Kyverno into its own namespace
helm install kyverno kyverno/kyverno -n kyverno --create-namespace

Verify Section

Check if Kyverno Pods are running correctly.

# Verify Kyverno deployment
kubectl get pods -n kyverno -l app.kubernetes.io/name=kyverno

# Expected Output
# NAME                             READY   STATUS    RESTARTS   AGE
# kyverno-admission-controller-xyz   1/1     Running   0          2m
# kyverno-background-controller-abc  1/1     Running   0          2m
# kyverno-cleanup-controller-def     1/1     Running   0          2m

Step 4: Creating and Applying Kyverno Policies for CIS Compliance

Explanation

Now that Kyverno is installed, let’s create a policy. A common CIS Benchmark recommendation is to ensure containers do not run as privileged. This maps to CIS control `5.2.1` in the Kubernetes v1.23 benchmark: “Ensure that the admission control plugin PodSecurityPolicy is enabled.” While PodSecurityPolicy is deprecated, its functionalities are largely covered by Pod Security Standards and tools like Kyverno. We’ll create a Kyverno `ClusterPolicy` to enforce that no container can be privileged. This policy will validate incoming Pod creation requests.

Code Block

Create a file named `disallow-privileged-containers.yaml`:

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: disallow-privileged-containers
  annotations:
    policies.kyverno.io/description: "Disallow privileged containers to comply with CIS Kubernetes Benchmark 5.2.1."
    policies.kyverno.io/category: "CIS Benchmark"
spec:
  validationFailureAction: Enforce
  background: true
  rules:
    - name: privileged-containers
      match:
        any:
          - resources:
              kinds:
                - Pod
      validate:
        message: "Privileged containers are not allowed. Refer to CIS Kubernetes Benchmark 5.2.1."
        pattern:
          spec:
            containers:
              - securityContext:
                  privileged: "false" # Must be explicitly false or omitted
            initContainers:
              - securityContext:
                  privileged: "false" # Must be explicitly false or omitted

Apply the policy:

kubectl apply -f disallow-privileged-containers.yaml

Verify Section

Check if the policy is created and then test it by trying to deploy a privileged Pod.

# Verify the policy is active
kubectl get clusterpolicy disallow-privileged-containers

# Expected Output
# NAME                             AGE
# disallow-privileged-containers   1m

# Attempt to deploy a privileged Pod (create privileged-pod.yaml)
cat < privileged-pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: privileged-test-pod
spec:
  containers:
  - name: my-privileged-container
    image: busybox
    command: ["sleep", "3600"]
    securityContext:
      privileged: true # This should be blocked
EOF

kubectl apply -f privileged-pod.yaml

You should see an error message from Kyverno:

# Expected Output (Error from Kyverno)
# Error from server (Privileged containers are not allowed. Refer to CIS Kubernetes Benchmark 5.2.1.): error when creating "privileged-pod.yaml": admission webhook "validate.kyverno.svc-fail" denied the request: validation failure: Privileged containers are not allowed. Refer to CIS Kubernetes Benchmark 5.2.1.

Now, try deploying a non-privileged Pod:

# Attempt to deploy a non-privileged Pod (create non-privileged-pod.yaml)
cat < non-privileged-pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: non-privileged-test-pod
spec:
  containers:
  - name: my-container
    image: busybox
    command: ["sleep", "3600"]
    securityContext:
      privileged: false # This should be allowed
EOF

kubectl apply -f non-privileged-pod.yaml

# Expected Output (Success)
# pod/non-privileged-test-pod created

# Clean up the test Pod
kubectl delete pod non-privileged-test-pod

This demonstrates how Kyverno can actively prevent non-compliant configurations, moving beyond just auditing to actual enforcement. For more complex networking policies, Kyverno can complement tools like Kubernetes Network Policies by ensuring pods adhere to security contexts that enable effective network segmentation.

Step 5: Generating Compliance Reports with Kyverno

Explanation

Kyverno not only enforces policies but also generates reports on policy violations. These reports are stored as Kubernetes Custom Resources (`PolicyReport` and `ClusterPolicyReport`). This allows you to programmatically query and integrate compliance status into your CI/CD pipelines, dashboards, or security information and event management (SIEM) systems. Kyverno’s reporting capabilities are essential for continuous compliance monitoring.

Code Block

To see the results of policy evaluations, you can query the `PolicyReport` or `ClusterPolicyReport` resources.

# Get all ClusterPolicyReports (for ClusterPolicies)
kubectl get clusterpolicyreport -n kyverno

# Expected Output (may vary, showing the policy and its status)
# NAME                                          SCOPE   RESULTS   PASS   FAIL   WARN   ERROR   SKIP   AGE
# clpolr-disallow-privileged-containers-xxxxx     1         0      1      0      0       0      5m

# Describe a specific ClusterPolicyReport for details
# Replace clpolr-disallow-privileged-containers-xxxxx with the actual name from the previous command
kubectl describe clusterpolicyreport clpolr-disallow-privileged-containers-xxxxx -n kyverno

Verify Section

The `describe` command will provide detailed information about the policy evaluations, including which resources failed, the rule that was violated, and the associated message. This granular data is invaluable for understanding your cluster’s compliance posture.

# Partial Expected Output from describe (showing a failed result)
# ...
# Results:
#   Message:    validation failure: Privileged containers are not allowed. Refer to CIS Kubernetes Benchmark 5.2.1.
#   Policy:     disallow-privileged-containers
#   Rule:       privileged-containers
#   Source:     Kyverno
#   Timestamp:
#     Nanos:    720000000
#     Seconds:  1678886400
#   Resource:
#     Api Version:  v1
#     Kind:         Pod
#     Name:         privileged-test-pod
#     Namespace:    default
#     Uid:          a1b2c3d4-e5f6-7890-1234-567890abcdef
#   Result:       fail
# ...

This shows a clear record of the `privileged-test-pod` failing the `disallow-privileged-containers` policy. This automated reporting mechanism allows for continuous monitoring and rapid identification of non-compliant resources.

Production Considerations

Automating CIS Kubernetes Benchmark compliance in a production environment requires careful planning and continuous management.

1. Phased Rollout: Do not enable `Enforce` mode for all policies immediately in production. Start with `Audit` mode (Kyverno’s `validationFailureAction: Audit`) to identify violations without blocking deployments. Gradually transition to `Enforce` as you address existing non-compliant resources.
2. Policy Lifecycle Management: Treat your Kyverno policies as code. Store them in a Git repository, use version control, and integrate them into your CI/CD pipelines. This ensures policies are reviewed, tested, and deployed consistently.
3. Baseline Definition: Not all CIS Benchmark controls are applicable or practical for every environment. Establish a clear baseline of which controls your organization aims to comply with. Document any justified exceptions.
4. Alerting and Monitoring: Integrate Kyverno’s `PolicyReport` results into your existing monitoring and alerting systems. Set up alerts for `FAIL` results to ensure immediate attention to critical compliance violations. eBPF observability tools like Hubble can provide deeper insights into network behavior, complementing policy enforcement by monitoring actual traffic patterns.
5. Performance Impact: Kyverno, as an admission controller, introduces a slight latency to API requests. Monitor its performance, especially in high-traffic clusters. Ensure sufficient resources are allocated to Kyverno components.
6. Custom Resource Definitions (CRDs): Be aware that Kyverno policies are CRDs. Ensure proper backup and restore procedures are in place for your CRDs.
7. Integration with Cloud Provider Tools: Many cloud providers offer their own security and compliance tools (e.g., AWS Security Hub, Azure Security Center, GCP Security Command Center). Integrate Kyverno’s reports into these platforms for a unified security posture view.
8. Regular Review: The CIS Kubernetes Benchmark is updated periodically. Review your policies and `kube-bench` configurations regularly to align with the latest benchmark versions and new Kubernetes features.
9. RBAC for Policy Management: Implement strict Role-Based Access Control (RBAC) for who can create, modify, or delete Kyverno policies. Only authorized personnel should have this capability.
10. Network Policy Integration: While Kyverno focuses on resource configuration, Kubernetes Network Policies are critical for controlling pod-to-pod and pod-to-external traffic. Use both in conjunction for comprehensive security.
11. Node-Level Compliance: Remember that `kube-bench` also checks node-level configurations. For managed Kubernetes services, some of these controls might be handled by the cloud provider. For self-managed clusters, ensure your node images and configurations are hardened according to CIS guidelines.
12. Supply Chain Security: Beyond runtime, ensure your images are secure from the start. Tools like Sigstore, when combined with Kyverno, can enforce image signing and verification, preventing unauthorized or untrusted images from running, as detailed in our Securing Container Supply Chains with Sigstore and Kyverno article.

Troubleshooting

Here are some common issues you might encounter when automating CIS Kubernetes Benchmark compliance and their solutions.

1. kube-bench Job Fails or Hangs

Issue: The `kube-bench` Job never completes, or the Pod enters a `CrashLoopBackOff` state.
Solution:

This often indicates permission issues or incorrect host path mounts. Check the logs of the kube-bench Pod for specific errors.

kubectl logs $(kubectl get pods -n kube-bench -l app=kube-bench -o jsonpath="{.items[0].metadata.name}") -n kube-bench

Look for messages like “permission denied” or errors related to mounting volumes. Ensure the ServiceAccount used by the Job has the necessary RBAC permissions (e.g., cluster-admin or a more restrictive role with specific permissions to read host paths and API server configurations) and that the host path mounts in the Job definition are correct for your node’s OS and Kubernetes version.

For example, if running on a non-Linux OS or a custom Kubernetes setup, paths like /etc/kubernetes/pki might differ.

2. kube-bench Reports “Unknown” for Many Checks

Issue: Many checks in the `kube-bench` report show `[INFO]` with a message like “Unknown, cannot determine if control plane is present.”
Solution:

kube-bench needs to know which component it’s scanning (master, worker, etcd). By default, it tries to auto-detect. If it fails, you might need to explicitly specify the `target` in the Job arguments. For example, if running on a control plane node, add --target master.

Modify the job.yaml to include the target argument:

# ...
    spec:
      containers:
      - name: kube-bench
        image: aquasec/kube-bench:latest
        command: ["kube-bench", "--json", "--target", "master"] # or "worker", "etcd"
# ...

Also, ensure that the job.yaml used is compatible with your Kubernetes version. Aqua Security provides different YAMLs for different Kubernetes versions.

3. Kyverno Installation Fails (Helm)

Issue: `helm install kyverno` fails or Kyverno Pods don’t start.
Solution:

Check the Helm output for errors. Common issues include:

• CRD Conflicts: If you had a previous Kyverno installation or another tool using similar CRDs, there might be conflicts. Try deleting existing Kyverno CRDs if safe to do so.
• RBAC Permissions: The user running helm install needs sufficient permissions to create namespaces, CRDs, Deployments, etc. Ensure your kubeconfig context has administrative privileges.
• Resource Constraints: Kyverno components might require more CPU/memory than available, leading to `Pending` or `CrashLoopBackOff` states. Check events and logs:

kubectl get pods -n kyverno
kubectl describe pod  -n kyverno
kubectl logs  -n kyverno

Adjust resource requests/limits in the Helm chart values if necessary.

4. Kyverno Policy Not Enforcing/Mutating

Issue: A Kyverno policy is applied, but it doesn’t seem to have any effect (e.g., privileged Pods are still created).
Solution:

Several reasons could cause this:

• Policy Status: Check if the `ClusterPolicy` is in `Active` status:

kubectl get clusterpolicy 

• `validationFailureAction`: Ensure `validationFailureAction` is set to `Enforce` for blocking actions. If it’s `Audit`, it will only report violations without blocking.
• Match/Exclude Rules: Carefully review the `match` and `exclude` blocks in your policy. A typo or incorrect selector can prevent the policy from applying to the intended resources. Test with a very broad match initially to ensure it’s hitting resources.
• Namespace Exclusion: Kyverno by default excludes its own namespace (`kyverno`) from policy evaluation. If you’re testing in the `kyverno` namespace, it won’t apply.
• Admission Webhook Order: In rare cases, if multiple admission webhooks are installed, their order might affect policy evaluation. Ensure Kyverno’s webhook is correctly configured if you have other webhooks.
• Resource Version: Kyverno policies only apply to *new* resource creations or updates. Existing resources are not automatically remediated unless you configure `generate` rules or run a background scan.

5. Kyverno Pods in `CrashLoopBackOff` After Policy Application

Issue: After applying a new Kyverno policy, the Kyverno admission controller Pods crash.
Solution:

This usually indicates an invalid or malformed policy definition. Kyverno’s admission controller might crash if it cannot parse or process a newly applied policy. This is more common with complex policies or when using advanced features.

• Rollback the Policy: Immediately delete the problematic policy:

kubectl delete clusterpolicy 

This should allow the Kyverno Pods to recover. If not, you might need to restart the Kyverno deployment.

• Validate Policy YAML: Use a YAML linter or schema validator to check your policy file for syntax errors.
• Test Policies in Audit Mode: Always test new or complex policies with `validationFailureAction: Audit` first in a non-production environment.

6. Kyverno Policy Reports Not Appearing

Issue: Kyverno policies are active and enforcing, but `kubectl get policereports` shows no results or stale results.
Solution:

Kyverno generates `PolicyReport` and `ClusterPolicyReport` resources. If you’re looking for cluster-wide policy violations (from `ClusterPolicy` resources), you should query `ClusterPolicyReport`. If you’re looking for namespace-scoped policies, you’d look for `PolicyReport` in that specific namespace.

# For ClusterPolicies
kubectl get clusterpolicyreport -A

# For Namespace-scoped Policies (e.g., in 'default' namespace)
kubectl get policyreport -n default

Ensure Kyverno’s `background` controller is running (`kyverno-background-controller` Pod). This component is responsible for generating reports for existing resources and background scans.

kubectl get pods -n kyverno -l app.kubernetes.io/component=background-controller

If you’ve just applied a policy, it might take a few minutes for the background scan to process existing resources and generate reports.

FAQ Section

Q1: What is the CIS Kubernetes Benchmark and why is it important?

The CIS (Center for Internet Security) Kubernetes Benchmark is a security hardening guide that provides prescriptive recommendations for configuring Kubernetes components to minimize attack surface and enhance security. It’s important because it offers a widely accepted, vendor-neutral framework for establishing a strong security posture in Kubernetes, helping organizations meet compliance requirements and protect sensitive data.

Q2: Can I use kube-bench to fix issues, or just identify them?

kube-bench is primarily an auditing tool. It identifies configuration deviations from the CIS Kubernetes Benchmark and provides remediation advice. It does not automatically fix issues. For automated remediation or enforcement, you would typically use a policy engine like Kyverno or OPA Gatekeeper, or configuration management tools like Ansible or Terraform.

Q3: How often should I run kube-bench scans?

The frequency depends on your environment’s change rate and compliance requirements. For production clusters, it’s recommended to run kube-bench scans periodically (e.g., weekly or monthly) and especially after major cluster upgrades or significant configuration changes. Integrating it into your CI/CD pipeline for new cluster deployments is also a best practice to ensure a secure baseline from day one.

Q4: How does Kyverno compare to OPA Gatekeeper for policy enforcement?

Both Kyverno and OPA Gatekeeper are powerful policy engines for Kubernetes. The main difference lies in their policy language: Kyverno uses YAML-native policies, making it potentially easier for Kubernetes administrators to adopt without learning a new language. Gatekeeper uses Rego, a declarative policy language, which is very powerful and flexible but has a steeper learning curve. Kyverno also offers mutation and generation capabilities out-of-the-box, which are often more complex to achieve with Gatekeeper and OPA.

Q5: Can I apply CIS Benchmark compliance to managed Kubernetes services (EKS, GKE, AKS)?

Yes, absolutely. While cloud providers manage the underlying infrastructure and some control plane components, you are still responsible for securing your worker nodes, Pod configurations, and cluster-level settings. kube-bench can still be run on these clusters, and Kyverno can enforce policies on your deployed applications. For specific cloud provider recommendations, refer to their security best practices, which often align with CIS Benchmarks. For example, some controls related to etcd security might be handled directly by AWS for EKS, but controls related to Pod security contexts are still your responsibility.

Cleanup Commands

After you’ve finished experimenting, you can clean up the resources created during this tutorial.

# 1. Delete the sample Kyverno policy
kubectl delete clusterpolicy disallow-privileged-containers

# 2. Uninstall Kyverno
helm uninstall kyverno -n kyverno
kubectl delete namespace kyverno

# 3. Delete kube-bench Job and namespace
kubectl delete job kube-bench -n kube-bench
kubectl delete namespace kube-bench

# 4. Delete any test Pods or YAML files created
rm privileged-pod.yaml non-privileged-pod.yaml disallow-privileged-containers.yaml

Next Steps / Further Reading

Congratulations on taking a significant step towards automating your Kubernetes compliance! Here are some next steps and resources for deeper exploration:

• Explore More Kyverno Policies: The Kyverno Policy Library is an excellent resource for pre-built policies covering many security best practices, including more CIS Benchmark controls.
• Integrate with CI/CD: Learn how to integrate Kyverno into your CI/CD pipelines to shift left on security, catching non-compliant configurations before they even reach your cluster.
• Advanced kube-bench Usage: Explore kube-bench‘s options for scanning specific components, custom configuration files, or generating different output formats. Check the kube-bench GitHub repository for details.
• Pod Security Standards: Familiarize yourself with Kubernetes Pod Security Standards, which are a built-in way to enforce baseline, restricted, or privileged security profiles for Pods. Kyverno can enforce these standards.
• Network Security: Dive deeper into securing inter-pod communication with our Kubernetes Network Policies: Complete Security Hardening Guide. For advanced encryption, consider Cilium WireGuard Encryption for Pod-to-Pod Traffic.
• Runtime Security: Beyond configuration, explore runtime security tools like Falco or Cilium’s runtime capabilities to detect and respond to threats in real-time.
• Cost Optimization with Compliance: