---
title: "Enterprise Kyverno"
description: "Hardened and scalable Kyverno OSS with enterprise support"
diataxis: how-to
applies_to:
  product: "kyverno"
audience: ["platform-engineer","devsecops"]
last_updated: 2026-04-16
url: https://docs.nirmata.io/docs/controllers/n4k/
---


## Key Features

[Nirmata Enterprise for Kyverno](https://nirmata.com/kyverno-enterprise/) is Nirmata's enterprise-grade distribution of [Kyverno](https://kyverno.io/). It is fully compatible with Kyverno OSS and provides the reliability, security hardening, and SLAs of an enterprise-grade solution.

**Key Features**

<div class="features-grid">
  <div class="feature-card">
    <div class="feature-icon">
      <i class="fas fa-shield-alt"></i>
    </div>
    <h3>Hardened and Optimized Distribution</h3>
    <p>Enterprise-grade hardened distribution of Kyverno with enhanced security, performance optimizations, and production-ready secure configurations for mission-critical environments.</p>
  </div>

  <div class="feature-card">
    <div class="feature-icon">
      <i class="fas fa-lock"></i>
    </div>
    <h3>0-CVE Images</h3>
    <p>Regular security scanning, patching, and updates to ensure that all container images are free from known vulnerabilities.</p>
  </div>

  <div class="feature-card">
    <div class="feature-icon">
      <i class="fas fa-headset"></i>
    </div>
    <h3>24x7 Support</h3>
    <p>Round-the-clock emergency support from Kyverno experts via phone, email, and messaging channels for production and business-critical workloads.</p>
  </div>

  <div class="feature-card">
    <div class="feature-icon">
      <i class="fas fa-terminal"></i>
    </div>
    <h3>Enhanced Command Line Interface</h3>
    <p>Enhanced CLI to scan Kubernetes manifests, Terraform, Dockerfiles, and other JSON payloads with SARIF support for reporting integrations.</p>
  </div>

  <div class="feature-card">
    <div class="feature-icon">
      <i class="fas fa-clipboard-list"></i>
    </div>
    <h3>Curated Policy Sets</h3>
    <p>300+ pre-built policies covering common security concerns, compliance requirements, and best practices to improve your Kubernetes cluster security posture.</p>
  </div>

  <div class="feature-card">
    <div class="feature-icon">
      <i class="fas fa-calendar-check"></i>
    </div>
    <h3>Long-Term Version Compatibility</h3>
    <p>Two years of Long-Term Support (LTS) with critical fixes and CVE support across Kyverno and Kubernetes versions, ensuring stable and secure deployments.</p>
  </div>

  <div class="feature-card">
    <div class="feature-icon">
      <i class="fas fa-rocket"></i>
    </div>
    <h3>Prioritized Fixes & Features</h3>
    <p>Fast-track your issues and feature requests with prioritized support from the Nirmata team, ensuring your needs are addressed promptly while maintaining upstream compatibility.</p>
  </div>

  <div class="feature-card">
    <div class="feature-icon">
      <i class="fas fa-graduation-cap"></i>
    </div>
    <h3>Training & Support</h3>
    <p>Quarterly training sessions, upgrade assistance, and best practice assessments to help teams master Kyverno and optimize their policy implementations.</p>
  </div>
</div>

<style>
.features-grid {
  display: grid;
  grid-template-columns: repeat(auto-fit, minmax(300px, 1fr));
  gap: 2rem;
  margin: 2rem 0;
}

.feature-card {
  background: linear-gradient(135deg, #f8f9fa 0%, #e9ecef 100%);
  border: 1px solid #dee2e6;
  border-radius: 12px;
  padding: 2rem;
  transition: transform 0.2s ease, box-shadow 0.2s ease;
  box-shadow: 0 4px 6px rgba(0, 0, 0, 0.05);
  text-align: center;
}

.feature-card:hover {
  transform: translateY(-4px);
  box-shadow: 0 8px 25px rgba(0, 0, 0, 0.1);
}

.feature-icon {
  font-size: 3rem;
  margin-bottom: 1rem;
  text-align: center;
  color: #007bff;
}

.feature-card h3 {
  color: #2c3e50;
  margin-bottom: 1rem;
  font-size: 1.25rem;
  font-weight: 600;
  text-align: center;
}

.feature-card p {
  color: #6c757d;
  line-height: 1.6;
  margin: 0;
  text-align: center;
}

@media (max-width: 768px) {
  .features-grid {
    grid-template-columns: 1fr;
    gap: 1.5rem;
  }
  
  .feature-card {
    padding: 1.5rem;
  }
}
</style>


## Frequently Asked Questions

**What is the difference between Nirmata Enterprise for Kyverno and Kyverno?**

Nirmata Enterprise for Kyverno is an enterprise distribution of Kyverno. It is fully compatible with Kyverno, but uses secure defaults, and optimized configuration settings, suitable for production deployments. For example, RBAC best practices and etcd offloading are enabled by default. The Nirmata distribution also provides 0-CVE images with optional FIPS support.

**Why use a distribution?**

Nirmata provides long term support by back-porting cirtical fixes to prior versions which may not be supported in the community. 

Nirmata will also fast track critical fixes and features for enterprise customers by first releasing changes in its distribution, and then merging changes into the next open source release. 

Since open source release timelines are decided in coordination with the community, Nirmata manages its own distribution to meet enterprise support SLAs and other customer committments.

**Will I get locked-in?**

No. Nirmata Enterprise for Kyverno is fully compatible with Kyverno and designed to be a drop-in replacement. You can migrate back to Kyverno anytime, if you choose not to continue with the Nirmata distribution.

**Can Nirmata support Kyverno OSS?**

Nirmata can assist, but cannot gaurantee SLAs on the open source distribution.

## Licensing

Nirmata Enterprise for Kyverno is **commercial software** available under a paid Nirmata subscription. Use is governed by the [Nirmata Terms of Use](https://nirmata.com/terms-of-use/). [Kyverno](https://kyverno.io) itself is an open-source project licensed under Apache 2.0 — Nirmata Enterprise for Kyverno is a separately licensed commercial distribution built on top of it. See the [Licensing]({{< relref "/docs/reference/licensing/" >}}) page for details.

## Learn More

Contact [Nirmata Customer Success](https://nirmata.com/contact-us) for more information on the Kyverno enterprise edition.


---

## Getting Started

Enterprise Kyverno is available as a Helm chart that can be installed using the Helm package manager.

### Prerequisites

- **Helm**: Refer to the [official docs](https://helm.sh/docs/intro/install/) for installation.
- **Kubernetes Cluster**: Any CNCF compliant Kubernetes distribution.


### Installing the Enterprise Kyverno Chart

#### Adding the Kyverno Helm repository
The following commands add the Kyverno helm chart repository and update it accordingly:

````bash
helm repo add nirmata https://nirmata.github.io/kyverno-charts/
helm repo update nirmata
````
#### Creating a namespace
You can install Kyverno in any namespace. The example uses `kyverno` as the namespace:

````bash
kubectl create namespace kyverno
````
**(Optional)** If a custom CA (Certificate Authority) is used in the cluster, create a configmap corresponding to the same in the namespace using the custom-ca.pem key:

````bash
kubectl -n kyverno create configmap <e.g. ca-store-cm> --from-file=custom-ca.pem=<cert file e.g. some-cert.pem>
````
#### Installing the Kyverno chart

>NOTE: If you want to offload reporting mechanism to reports-server, refer to [this guide](./../reports-server/#installation).

The following command installs **only** the Kyverno deployment in the `kyverno` namespace:

````bash
helm install kyverno --namespace kyverno --create-namespace nirmata/kyverno
````

This command deploys Kyverno on the Kubernetes cluster with default configuration. The [detailed installation guide](https://kyverno.io/docs/installation/) lists the parameters that can be configured during installation.

The Kyverno ClusterRole/ClusterRoleBinding that manages webhook configurations must have the suffix `:webhook`. Ex., `*:webhook` or `kyverno:webhook`. Other ClusterRole/ClusterRoleBinding names are configurable.

**(Optional)** Other parameters to the above command corresponding to custom CA, HTTP proxies, or NO_PROXY should be provided as needed:

````bash
--set customCAConfigMap=<e.g. ca-store-cm> --set systemCertPath=<e.g. /etc/ssl/certs> --set "extraEnvVars[0].name=HTTP_PROXY" --set "extraEnvVars[0].value=<e.g. http://test.com:8080>" ...
````

#### Installing the YAML
To install the chart directly without using the ``helm install`` command, simply generate the YAML from the helm chart and install it using the ``kubectl`` command. After updating the Helm repository as described above, proceed to the next step by creating the namespace for Kyverno in your Kubernetes cluster. Once the namespace is created, generate the kyverno YAML file by using the following helm template command:

````bash
helm template kyverno --namespace=kyverno nirmata/kyverno --create-namespace > kyverno.yaml
````
The following `kubectl` command installs the file directly into the namespace:

````bash
kubectl create -f kyverno.yaml
````
>**Notes for ArgoCD users**: You can install this chart with the help of ArgoCD as well. Refer to the [Kyverno documentation](https://kyverno.io/docs/installation/platform-notes/#notes-for-argocd-users) for more details.

### Running Enterprise Kyverno on AWS Fargate

#### Creating a Fargate Profile
Create a new cluster named fargate-testing-cluster and set up a Fargate profile:

````bash
eksctl create fargateprofile \
  --cluster fargate-testing-cluster \
  --name kyverno-profile \
  --namespace kyverno
````

#### Installing Enterprise Kyverno on Fargate

````bash
helm repo add nirmata https://nirmata.github.io/kyverno-charts/
helm repo update nirmata
helm install kyverno --namespace kyverno --create-namespace nirmata/kyverno
````

### Upgrading from open-source Kyverno to Nirmata Enterprise Subscription

For users having open-source Kyverno of version 1.5.0 or above installed in their cluster, execute the following command to upgrade directly to Nirmata Enterprise Subscription:

````bash
helm upgrade kyverno --namespace kyverno nirmata/kyverno
````

### Uninstalling the Enterprise Kyverno Chart

The below command will uninstall the kyverno deployment and remove all the Kubernetes components associated with the chart and delete the release:

````bash
helm delete -n kyverno kyverno
````

### Fetching signatures

Use the following command to fetch the signature for a specified Nirmata Enterprise for Kyverno binary tag:

```bash
COSIGN_REPOSITORY=ghcr.io/nirmata/signatures cosign download signature ghcr.io/nirmata/kyvernopre:<TAG>
```text

Replace the <TAG> variable with the specific version tag as required.

### Fetching the SBOM

**FIPS Binaries**

Use the following commands to fetch the SBOMs for FIPS-enabled Nirmata Enterprise for Kyverno binaries. Replace <TAG> with the desired version tag:

```bash
COSIGN_REPOSITORY=ghcr.io/nirmata/sbom cosign download sbom ghcr.io/nirmata/cleanup-controller-fips:<TAG>
COSIGN_REPOSITORY=ghcr.io/nirmata/sbom cosign download sbom ghcr.io/nirmata/background-controller-fips:<TAG>
COSIGN_REPOSITORY=ghcr.io/nirmata/sbom cosign download sbom ghcr.io/nirmata/reports-controller-fips:<TAG>
COSIGN_REPOSITORY=ghcr.io/nirmata/sbom cosign download sbom ghcr.io/nirmata/kyverno-fips:<TAG>
COSIGN_REPOSITORY=ghcr.io/nirmata/sbom cosign download sbom ghcr.io/nirmata/kyverno-cli-fips:<TAG>
COSIGN_REPOSITORY=ghcr.io/nirmata/sbom cosign download sbom ghcr.io/nirmata/kyvernopre-fips:<TAG>
```text

**Non-FIPS Binaries**

For non-FIPS binaries, use the following commands and replace <TAG> with the specific version tag:

```bash
COSIGN_REPOSITORY=ghcr.io/nirmata/sbom cosign download sbom ghcr.io/nirmata/cleanup-controller:<TAG>
COSIGN_REPOSITORY=ghcr.io/nirmata/sbom cosign download sbom ghcr.io/nirmata/background-controller:<TAG>
COSIGN_REPOSITORY=ghcr.io/nirmata/sbom cosign download sbom ghcr.io/nirmata/reports-controller:<TAG>
COSIGN_REPOSITORY=ghcr.io/nirmata/sbom cosign download sbom ghcr.io/nirmata/kyverno:<TAG>
COSIGN_REPOSITORY=ghcr.io/nirmata/sbom cosign download sbom ghcr.io/nirmata/kyverno-cli:<TAG>
COSIGN_REPOSITORY=ghcr.io/nirmata/sbom cosign download sbom ghcr.io/nirmata/kyvernopre:<TAG>
```text

**Notes**

- Ensure you have [Sigstore Cosign](https://docs.sigstore.dev/quickstart/quickstart-cosign/) installed and configured before running these commands.
- Replace <TAG> with the version tag of the Nirmata Enterprise for Kyverno binary you want to fetch, e.g., v1.13.2-n4k.nirmata.2.
- Refer to the official documentation for further details on cosign usage and capabilities.


---

## Reports Server


Reports server provides a scalable solution for storing policy reports and cluster policy reports. It moves reports out of etcd and stores them in an alternate database instance.

### Why Reports Server?

Before understanding the benefits of reports server, it is essential to have a look at the reasons that makes moving reports out of etcd desirable.

#### Reasons to Transition Away from etcd

- **Capacity Constraints**: etcd has a maximum size of 8GB. Reports, being relatively large objects, can quickly consume this capacity in larger clusters with numerous report producers.
- **Performance Under Load**: High levels of report activity (e.g., cluster churn, scanning, analytics) require significant data buffering by the API server, potentially leading to API unavailability.
- **Data Nature**: Reports are ephemeral and analytical in nature, not requiring CAP guarantees. As such, they are better suited for storage outside the transactional etcd database.
- **Philosophical Alignment**: Analytical data like reports should ideally be stored in a system designed for analytical queries, such as a relational database.

#### Benefits of reports server

- Reduced Load on etcd and API Server: By relocating reports, the load and capacity limitations of etcd and the API server are alleviated.
- Improved Efficiency for Consumers:
     - Report consumers often require analytical or aggregate data queries. The Kubernetes API is not optimized for such queries.
     - For instance, querying all reports with a CVSS severity of 8.0 or higher requires retrieving and parsing all reports via the API, which is inefficient.
     - With reports stored in a relational database, consumers can perform robust queries directly, improving performance and enabling new use cases.
     - This approach can replace certain exporters and streamline reporting workflows.

### Prerequisites

- **Helm**: Refer to the [official docs](https://helm.sh/docs/intro/install/) for installation.
- **Kubernetes Cluster**: Any CNCF compliant Kubernetes distribution.

### Installation
#### Installing Reports Server Natively with Enterprise Kyverno
```bash
 helm repo add nirmata https://nirmata.github.io/kyverno-charts/
 helm repo update nirmata
 helm install kyverno --namespace kyverno --create-namespace nirmata/kyverno  --set crds.reportsServer.enabled=true --set reports-server.install=true
```
For a complete list of values, refer to [values.yaml](https://github.com/nirmata/kyverno-charts/blob/main/charts/nirmata/values.yaml).

##### Handling CRD or APIServices Related Errors

If you encounter errors related to existing CRDs or APIServices during installation, such as:

```text

You can resolve this by adding the migration flag to your installation command:

```bash
 helm install kyverno --namespace kyverno --create-namespace nirmata/kyverno  --set crds.reportsServer.enabled=true --set reports-server.install=true --set reports-server.apiServicesManagement.migrateReportsServer.enabled=true
```text

#### Installing Reports Server Independent of Enterprise Kyverno
The Reports Server serves certain report CRDs through its APIService. At the same time, Enterprise Kyverno expects these CRDs to exist for policy reporting. If both Kyverno and the Reports Server try to define or serve these CRDs simultaneously, the Kubernetes apiserver may fail to reconcile duplicate API paths. This is a known limitation in upstream Kubernetes (see [Kubernetes Issue #122668](https://github.com/kubernetes/kubernetes/issues/122668#issuecomment-2577138150)).

To avoid these conflicts:
* Deploy Reports Server independently first
* Confirm its APIService is fully ready
* Then install Enterprise Kyverno separately

This ordering guarantees the CRDs are correctly served and avoids temporary crash loops or installation failures in Kyverno.

**Note:** The below command installs reports-server in etcd mode. For Postgres, see the section below.

Add and update Helm repo.
```bash
 helm repo add nirmata https://nirmata.github.io/kyverno-charts/
 helm repo update nirmata
```text

```bash
 helm install reports-server -n kyverno nirmata/reports-server --create-namespace

 helm install kyverno --namespace kyverno --create-namespace nirmata/kyverno  --set crds.reportsServer.enabled=true
```text

##### Handling CRD or APIServices Related Errors

If you encounter errors related to existing CRDs or APIServices during the independent installation, such as:

```text
Error: INSTALLATION FAILED: 2 errors occurred:
	* apiservices.apiregistration.k8s.io "v1alpha2.wgpolicyk8s.io" already exists
	* apiservices.apiregistration.k8s.io "v1.reports.kyverno.io" already exists
```text

You can resolve this by adding the migration flag to your Reports Server installation command:

```bash
 helm install reports-server -n kyverno nirmata/reports-server --create-namespace --set apiServicesManagement.migrateReportsServer.enabled=true

 helm install kyverno --namespace kyverno --create-namespace nirmata/kyverno  --set crds.reportsServer.enabled=true
```text

### Installing Reports Server using configurations

There are two configurations available for installing the Reports Server in a production cluster:

- **Reports server with embedded etcd storage**: Store reports in a high-availability (HA) etcd instance.
- **Reports server with managed postgres**: Use a centralized postgres database in or outside of the cluster.


#### Embedded etcd storage

To install the Reports Server with embedded etcd storage:
 
Using Helm Commands:
````bash
 helm repo add nirmata https://nirmata.github.io/kyverno-charts/
 helm repo update nirmata
 helm install reports-server -n kyverno nirmata/reports-server --create-namespace
````

#### Managed Postgres

To configure the Reports Server with a PostgreSQL instance:
 
Using Helm Commands:
```bash
 helm repo add nirmata https://nirmata.github.io/kyverno-charts/
 helm repo update nirmata
 helm install reports-server -n kyverno nirmata/reports-server --create-namespace \
         --set config.etcd.enabled=false \
         --set config.db.host=<Host_Name> \
         --set config.db.name=<DB_Name> \
         --set config.db.user=<Postgres_username> \
         --set config.db.password=<Postgress_password>
```text
>Note: Obtain the hostname, database name, PostgreSQL username, and password from your PostgreSQL instance.


##### Managed Postgres in AWS

Reports Server can be installed with managed postgres in AWS. Create a postgres instance in AWS using Amazon RDS and install the reports-server chart using the above command. Refer to the [official AWS documentation](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Tutorials.WebServerDB.CreateDBInstance.html) for creating the postgres instance. Get the hostname, dbname, postgres username, postgres password, etc., from the postgres instance and fill the values in helm values.

### Migration from etcd to reports-server

When the Reports Server is enabled, migration from etcd occurs automatically under the following conditions:
- The cluster has Kyverno already installed.
- The cluster has policy reports crds already installed.


### QA Testing 
The Reports Server has been verified on both amd64 and arm64 architectures, ensuring robust performance and compatibility.

---

## FIPS Support


FIPS (Federal Information Processing Standards) support is included by default in the Nirmata Enterprise for Kyverno Helm chart. However, it is important to note that FIPS support is exclusive to the enterprise version of Kyverno and is not available in the open-source version.

### Multi-arch support

FIPS support is available for amd64 and arm64. 

### Why FIPS?

The National Institute of Standards and Technology (NIST) created the Federal Information Processing Standard with the goal of improving the security of computer and telecommunications systems in government. 

#### How to enable FIPS support for Nirmata Enterprise for Kyverno
To enable FIPS support for Nirmata Enterprise for Kyverno, follow these steps:
````bash
 helm repo add nirmata https://nirmata.github.io/kyverno-charts/
 helm repo update nirmata
 helm install kyverno -n kyverno nirmata/kyverno  --create-namespace --set fipsEnabled=true
````

### Quality Assurance Verification

Nirmata Enterprise for Kyverno with FIPS support has been rigorously tested and verified on machines with both amd64 and arm64 architectures.



---

## Kyverno MCP Server


## Overview

The Kyverno MCP Server is a Model Context Protocol (MCP) server that provides Kyverno policy management capabilities through a standardized interface. This server enables AI assistants to interact with Kyverno policies in Kubernetes clusters, making policy management more accessible and automated.

Whether you're looking to proactively assess the security posture of your clusters before implementing Kyverno, or you need to monitor and analyze policy violations in existing Kyverno deployments, the MCP server provides the tools and guidance necessary for comprehensive policy management across your Kubernetes infrastructure.

## What is MCP?

Model Context Protocol (MCP) is a standardized protocol that allows AI assistants to interact with external tools and services. The Kyverno MCP Server implements this protocol to expose Kyverno's policy management capabilities to AI-powered tools like Claude Desktop, Amazon Q, Cursor, and other MCP-compatible clients.

## Key Features

- **Proactive Policy Scanning**: Test cluster resources against curated Kyverno policy sets, Git repositories, or local policies to discover security issues without requiring Kyverno installation
- **Real-time Violation Monitoring**: View detailed policy violations and compliance status from PolicyReport and ClusterPolicyReport custom resources in clusters with deployed policies
- **Multi-Cluster Management**: Seamlessly switch between Kubernetes contexts to scan or monitor policies across different environments
- **AI-Powered Guidance**: Natural language interaction with built-in help system for Kyverno installation and troubleshooting
- **Flexible Deployment Options**: Run as a local binary, container, or expose via HTTP(S) for different integration scenarios

## Quick Links

### Getting Started
- [Installation Guide](./installation/) - Detailed installation instructions
- [Quick Start](./getting-started/) - Get up and running in minutes
- [Use Cases & Scenarios](./usage/) - Real-world scenarios and user stories
- [Available Tools](./available-tools/) - Complete tool reference

### Configuration & Usage
- [Configuration Options](./configuration/) - All configuration settings

### Support & Resources
- [Troubleshooting](./troubleshooting/) - Common issues and solutions
- [GitHub Repository](https://github.com/nirmata/kyverno-mcp) - Source code and contributions

## Prerequisites

- Go 1.24 or higher (for building from source)
- Access to a Kubernetes cluster with a valid kubeconfig
- Kyverno installed in your cluster (for violation monitoring; optional for proactive policy assessment)

## Installation Options

### Quick Install with Homebrew

```bash
brew tap nirmata/tap
brew install kyverno-mcp
```text

### Download Pre-built Binaries

Download the appropriate binary for your platform from the [Nirmata downloads page](https://downloads.nirmata.io/kyverno-mcp/downloads/).

### Run with Docker

```bash
# Build the image
docker build -t kyverno-mcp:latest .

# Run with mounted kubeconfig
docker run --rm -i \
  -v $HOME/.kube/config:/kube/config:ro \
  kyverno-mcp:latest -- \
  --kubeconfig /kube/config
```text

For detailed installation instructions, see the [Installation Guide](./installation/).

## Getting Started

### Basic Usage

Start the server using your default kubeconfig:

```bash
./kyverno-mcp
```json

Or specify a custom kubeconfig:

```bash
./kyverno-mcp --kubeconfig=/path/to/kubeconfig
```json

### Configure Your MCP Client

Add the Kyverno MCP server to your MCP client configuration:

```json
{
  "mcpServers": {
    "kyverno": {
      "command": "/path/to/kyverno-mcp",
      "args": [
        "--kubeconfig=/path/to/your/kubeconfig"
      ]
    }
  }
}
```text

For a complete getting started tutorial, see the [Getting Started Guide](./getting-started/).

### Network Access (HTTP/HTTPS)

For remote access or browser-based clients, expose the server over HTTP(S):

```bash
# HTTPS (recommended for production)
./kyverno-mcp \
  --http-addr :8443 \
  --tls-cert /path/to/cert.pem \
  --tls-key /path/to/key.pem

# HTTP (local testing only)
./kyverno-mcp --http-addr :8080
```text

⚠️ **Security Note**: Never expose the server over plain HTTP in production. Always use HTTPS with valid TLS certificates or place the server behind an HTTPS-terminating proxy.

## Available Tools

The Kyverno MCP Server provides the following tools:

### Context Management

- **`list_contexts`**: List all available Kubernetes contexts
- **`switch_context`**: Switch to a different Kubernetes context

### Policy Operations

- **`apply_policies`**: Scan cluster resources against Kyverno policies from curated sets, Git repos, or local files
  - Supports policy sets: `pod-security`, `rbac-best-practices`, `kubernetes-best-practices`, `all`
  - Enable proactive security assessment by testing policies without requiring Kyverno installation
  - Source policies from Git repositories or local filesystem paths for custom policy testing
  - Provides immediate, non-persistent violation reports using `kyverno apply`

### Monitoring & Compliance

- **`show_violations`**: Read and display policy violations from PolicyReport and ClusterPolicyReport custom resources
  - Shows both namespaced and cluster-wide violations with severity levels and timestamps
  - Provides detailed violation analysis including affected resources and policy details
  - Requires Kyverno installation and deployed policies to function
  - Offers Kyverno installation guidance when not yet deployed

### Documentation

- **`help`**: Access built-in Kyverno documentation
  - Topics: `installation`, `troubleshooting`

For detailed tool documentation, see the [Available Tools Reference](./available-tools/).

## Command Line Reference

| Flag | Description | Default |
|------|-------------|---------|
| `--kubeconfig` | Path to kubeconfig file | `$KUBECONFIG` or `~/.kube/config` |
| `--http-addr` | HTTP(S) server bind address | None (stdio mode) |
| `--tls-cert` | TLS certificate file path | None |
| `--tls-key` | TLS private key file path | None |

For complete configuration options, see the [Configuration Guide](./configuration/).

## Use Cases

### Proactive Security Assessment
Scan clusters for policy violations without installing Kyverno:

**Scenario**: *As a DevOps engineer, I want to scan my Kubernetes clusters for policy violations and assess their security posture without needing to install Kyverno or deploy policies to the cluster.*

- Scan existing cluster resources against curated policy sets
- Get immediate, non-persistent violation reports
- Receive guidance on Kyverno installation and policy deployment
- Establish baseline security requirements across multiple environments

```text
Apply pod security policies to my cluster and show me what violations occur
```

### Compliance Monitoring & Violation Analysis
Monitor ongoing compliance in clusters with deployed Kyverno policies:

**Scenario**: *As a security engineer, I want to monitor compliance across my Kubernetes clusters that already have Kyverno installed and policies deployed, and get detailed reports on policy violations from PolicyReport resources.*

- Real-time violation monitoring from PolicyReport custom resources
- Detailed analysis with severity levels, affected resources, and timestamps
- Filtered reporting by namespace, policy type, or severity
- Current state monitoring of policy violations

```text
Show me all high-severity violations in the production namespace
```

### Multi-Cluster Policy Management
Manage policies consistently across development, staging, and production:
```text
Compare policy violations between staging and production clusters
```

### Automated Policy Testing
Test security policies across multiple clusters with AI assistance:
```text
Apply rbac-best-practices to all my clusters and show me the compliance status
```

## Next Steps

- [Install Kyverno](https://kyverno.io/docs/installation/) in your cluster
- Explore [Kyverno policies](https://kyverno.io/policies/)
- Learn about [Model Context Protocol](https://modelcontextprotocol.io/)
- Join the [Kyverno community](https://kyverno.io/community/)

## Support

- **Documentation**: Full documentation available in this guide
- **GitHub Issues**: [Report bugs or request features](https://github.com/nirmata/kyverno-mcp/issues)
- **Community**: Join the [Kyverno Slack channel](https://kubernetes.slack.com/archives/CLGR9BJU9)

## Quick Start

Ready to get started? Check out our guides:

- **[Getting Started](getting-started)** - Quick setup guide
- **[Usage](usage)** - Real-world scenarios and user stories
- **[Installation](installation)** - Detailed installation instructions
- **[Available Tools](available-tools)** - Complete tool reference
- **[Configuration](configuration)** - Configuration options
## Documentation

- **[Troubleshooting](troubleshooting)** - Common issues and solutions

Visit our [GitHub repository](https://github.com/nirmata/kyverno-mcp) for source code and development information.


---

## Cloud Provider Integrations


Enterprise Kyverno can be installed on cloud provider-managed Kubernetes clusters.