Nirmata on Nirmata Documentation

Configuring Okta as an Identity Provider in Nirmata

Thu, 21 Mar 2024 00:00:00 +0000

Prerequisites

Administrative access to your Okta organization account or Okta App Integration
Administrative access to Nirmata account

Configuration Steps

1. Create a New Application in Okta

Log in to your Okta Admin Console.
In the left sidebar, navigate to Applications > Applications.
Click Create Application Integration.
Select OIDC.
Choose Web Application as the platform.
Click Create.

2. Configure Application Settings

In the application settings, fill in the following:
- App integration name: (e.g., Nirmata app)
- Application type: Web
- Grant type configuration:
  - Under Grant type:
    - Check Client Credentials (under “Client acting on behalf of itself”).
    - Under Core grants, check Authorization Code. (Leave Refresh Token unchecked unless your use case requires it.)
    - Expand Advanced:
      - Leave all Okta direct auth API grants (OTP, OOB, MFA OTP, MFA OOB) unchecked.
      - Under Other grants, check Implicit (hybrid).
        
        Check both Allow ID Token with implicit grant type and Allow Access Token with implicit grant type.
- Login redirect URIs:
  - Sign-in redirect URIs https://<nirmata-domain>/security/api/oidc/callback/
- Sign-out redirect URIs https://<nirmata-domain>/security/api/oidc/logout/

Click on Save

Nirmata Kube Controller

Mon, 01 Jan 0001 00:00:00 +0000

Nirmata Kube Controller is used to register the cluster with the Nirmata platform.

The following resources will be deployed to the target cluster.

Deployment

nirmata-kube-controller

apiVersion: apps/v1
kind: Deployment
metadata:
 name: nirmata-kube-controller
 namespace: nirmata
spec:
 replicas: 1
 selector:
 matchLabels:
 app: nirmata-kube-controller
 nirmata.io/container.type: system
 app.kubernetes.io/name: nirmata
 app.kubernetes.io/instance: nirmata
 template:
 metadata:
 labels:
 app: nirmata-kube-controller
 nirmata.io/container.type: system
 app.kubernetes.io/name: nirmata
 app.kubernetes.io/instance: nirmata
 spec:
 containers:
 - args:
 - -token
 - $(TOKEN)
 - -url
 - $(URL)
 - -event-aggregation
 command:
 - /nirmata-kube-controller
 env:
 - name: TOKEN
 value: 6fcee39e-44dc-43a6-9792-468b82fd5a24
 - name: URL
 value: wss://www.nirmata.io/tunnels
 image: ghcr.io/nirmata/nirmata-kube-controller:v3.9.8
 imagePullPolicy: IfNotPresent
 livenessProbe:
 exec:
 command:
 - /nirmata-kube-controller
 name: nirmata-kube-controller
 readinessProbe:
 exec:
 command:
 - /nirmata-kube-controller
 resources:
 limits:
 memory: 512Mi
 requests:
 memory: 200Mi
 cpu: 250m
 securityContext:
 allowPrivilegeEscalation: false
 capabilities:
 drop:
 - ALL
 readOnlyRootFilesystem: true
 runAsNonRoot: true
 seccompProfile:
 type: RuntimeDefault
 hostNetwork: false
 imagePullSecrets:
 - name: nirmata-controller-registry-secret
 securityContext:
 seccompProfile:
 type: RuntimeDefault
 serviceAccountName: nirmata
 tolerations:
 - effect: NoSchedule
 key: node-role.kubernetes.io/master
 operator: Exists
```text
</details>

<details>
<summary>otel-agent</summary>

```yaml
apiVersion: apps/v1
kind: Deployment
metadata:
 name: otel-agent
 namespace: nirmata
 labels:
 app: opentelemetry
 component: otel-agent
 app.kubernetes.io/instance: nirmata
 app.kubernetes.io/name: nirmata
spec:
 selector:
 matchLabels:
 app: opentelemetry
 component: otel-agent
 app.kubernetes.io/instance: nirmata
 app.kubernetes.io/name: nirmata
 template:
 metadata:
 labels:
 app: opentelemetry
 component: otel-agent
 app.kubernetes.io/instance: nirmata
 app.kubernetes.io/name: nirmata
 spec:
 containers:
 - name: otel-agent
 image: ghcr.io/nirmata/metrics-agent:0.38.3
 resources:
 limits:
 memory: 512Mi
 requests:
 cpu: 100m
 memory: 200Mi
 securityContext:
 allowPrivilegeEscalation: false
 capabilities:
 drop:
 - ALL
 readOnlyRootFilesystem: true
 runAsNonRoot: true
 seccompProfile:
 type: RuntimeDefault
 livenessProbe:
 httpGet:
 path: /metrics
 port: 8888
 scheme: HTTP
 readinessProbe:
 httpGet:
 path: /metrics
 port: 8888
 scheme: HTTP
 volumeMounts:
 - mountPath: /etc/otel/config.yaml
 name: data
 subPath: config.yaml
 readOnly: true
 terminationGracePeriodSeconds: 30
 volumes:
 - name: data
 configMap:
 name: otel-agent-config
```text
</details>

### ServiceAccount

<details>
<summary>nirmata</summary>

```yaml
apiVersion: v1
kind: ServiceAccount
metadata:
 name: nirmata
 namespace: nirmata
secrets:
 - name: nirmata-sa-secret
```text
</details>

<details>
<summary>nirmata-controller</summary>

```yaml
apiVersion: v1
kind: ServiceAccount
metadata:
 name: nirmata-controller
 namespace: nirmata
```text
</details>

### ConfigMap

<details>
<summary>nirmata-kube-controller-config</summary>

```yaml
apiVersion: v1
kind: ConfigMap
metadata:
 name: nirmata-kube-controller-config
 namespace: nirmata
data:
 IgnoreFields: metadata.managedFields
 FilterPatches: |-
 /metadata/resourceVersion
 /metadata/generation
 /results/*/timestamp/*
 IgnoreEvents: Normal.PolicyApplied.*
 WatchedResources: |-
 events.v1.
 policyreports.v1alpha2.wgpolicyk8s.io
 clusterpolicyreports.v1alpha2.wgpolicyk8s.io
 policies.v1.kyverno.io
 clusterpolicies.v1.kyverno.io
 policyexceptions.v2alpha1.kyverno.io
 FilterEvents: Warning.PolicyViolation.*,Normal.PolicySkipped.*
```text
</details>

<details>
<summary>otel-agent-config</summary>

```yaml
apiVersion: v1
kind: ConfigMap
metadata:
 name: otel-agent-config
 namespace: nirmata
data:
 config.yaml: >-
 receivers:
 prometheus:
 config:
 scrape_configs:
 - job_name: "kyverno"
 scrape_interval: 1m
 static_configs:
 - targets: ["kyverno-svc-metrics.kyverno.svc.cluster.local:8000"]
 metric_relabel_configs:
 - source_labels: [__name__]
 regex: "(kyverno_admission_review_duration_seconds.*|kyverno_policy_execution_duration_seconds.*|kyverno_policy_results_total|kyverno_policy_rule_info_total|kyverno_admission_requests_total|kyverno_controller_reconcile_total|kyverno_controller_requeue_total|kyverno_controller_drop_total)"
 action: keep
 exporters:
 prometheusremotewrite:
 endpoint: https://www.nirmata.io/host-gateway/metrics-receiver
 external_labels:
 clusterId: 6fcee39e-44dc-43a6-9792-468b82fd5a24
 remote_write_queue:
 queue_size: 2000
 num_consumers: 1
 timeout: 300s
 service:
 pipelines:
 metrics:
 receivers: [prometheus]
 exporters: [prometheusremotewrite]
```text
</details>


### ClusterRole
<details>
<summary>nirmata:nirmata-privileged</summary>
Note: This ClusterRole is only needed for NDP

```yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
 annotations: {}
 name: nirmata:nirmata-privileged
rules:
 - apiGroups:
 - kyverno.io
 - operator.kyverno.io
 - security.nirmata.io
 nonResourceURLs: []
 resourceNames: []
 resources:
 - policies
 - clusterpolicies
 - reportchangerequests
 - clusterreportchangerequests
 - kyvernooperators/status
 - kyvernooperators
 - imagekeys
 - imagekeys/finalizers
 - imagekeys/status
 - admissionreports
 - clusteradmissionreports
 - backgroundscanreports
 - clusterbackgroundscanreports
 - policyexceptions
 - cleanuppolicies
 - clustercleanuppolicies
 - kyvernoes
 - kyvernoes/status
 verbs:
 - "*"
 - apiGroups: []
 nonResourceURLs:
 - /metrics
 resourceNames: []
 resources: []
 verbs:
 - get
 - apiGroups:
 - "*"
 nonResourceURLs: []
 resourceNames: []
 resources:
 - tokenreviews
 - subjectaccessreviews
 verbs:
 - get
 - create
 - apiGroups:
 - wgpolicyk8s.io/v1alpha1
 - wgpolicyk8s.io/v1alpha2
 nonResourceURLs: []
 resourceNames: []
 resources:
 - policyreports
 - clusterpolicyreports
 verbs:
 - "*"
 - apiGroups:
 - "*"
 nonResourceURLs: []
 resourceNames: []
 resources:
 - policies
 - policies/status
 - clusterpolicies
 - clusterpolicies/status
 - policyreports
 - policyreports/status
 - clusterpolicyreports
 - clusterpolicyreports/status
 - generaterequests
 - generaterequests/status
 - reportchangerequests
 - reportchangerequests/status
 - clusterreportchangerequests
 - clusterreportchangerequests/status
 - updaterequests
 - updaterequests/status
 - admissionreports
 - clusteradmissionreports
 - backgroundscanreports
 - clusterbackgroundscanreports
 verbs:
 - create
 - delete
 - get
 - list
 - patch
 - update
 - watch
 - deletecollection
 - apiGroups:
 - apiextensions.k8s.io
 nonResourceURLs: []
 resourceNames: []
 resources:
 - customresourcedefinitions
 verbs:
 - delete
 - create
 - get
 - list
 - patch
 - update
 - watch
 - apiGroups:
 - "*"
 nonResourceURLs: []
 resourceNames: []
 resources:
 - namespaces
 - networkpolicies
 - secrets
 - configmaps
 - resourcequotas
 - limitranges
 - deployments
 - services
 - serviceaccounts
 - roles
 - rolebindings
 - clusterroles
 - clusterrolebindings
 - events
 - mutatingwebhookconfigurations
 - validatingwebhookconfigurations
 - certificatesigningrequests
 - certificatesigningrequests/approval
 - poddisruptionbudgets
 - ingresses
 - ingressclasses
 verbs:
 - create
 - update
 - delete
 - list
 - get
 - patch
 - watch
 - apiGroups:
 - "*"
 nonResourceURLs: []
 resourceNames: []
 resources:
 - "*"
 verbs:
 - get
 - list
 - watch
 - update
 - apiGroups:
 - certificates.k8s.io
 nonResourceURLs: []
 resourceNames:
 - kubernetes.io/legacy-unknown
 resources:
 - certificatesigningrequests
 - certificatesigningrequests/approval
 - certificatesigningrequests/status
 verbs:
 - create
 - delete
 - get
 - update
 - watch
 - apiGroups:
 - certificates.k8s.io
 nonResourceURLs: []
 resourceNames:
 - kubernetes.io/legacy-unknown
 resources:
 - signers
 verbs:
 - approve
 - apiGroups:
 - coordination.k8s.io
 nonResourceURLs: []
 resourceNames: []
 resources:
 - leases
 verbs:
 - create
 - delete
 - get
 - patch
 - update
```text
</details>

<details>
<summary>nirmata:policyexception-manager</summary>

```yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
 name: nirmata:policyexception-manager
rules:
- apiGroups:
 - kyverno.io
 resources:
 - policies
 - clusterpolicies
 - policyexceptions
 verbs:
 - '*'
```text
</details>

### ClusterRoleBindings

<details>
<summary>nirmata-cluster-admin-binding</summary>
Note: This ClusterRoleBinding is only needed for NDP

```yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
 name: nirmata-cluster-admin-binding
roleRef:
 apiGroup: rbac.authorization.k8s.io
 kind: ClusterRole
 name: nirmata:nirmata-privileged
subjects:
 - kind: ServiceAccount
 name: nirmata
 namespace: nirmata
```text
</details>

<details>
<summary>nirmata-controller-binding</summary>

```yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
 name: nirmata-controller-binding
roleRef:
 apiGroup: rbac.authorization.k8s.io
 kind: ClusterRole
 name: view
subjects:
 - kind: ServiceAccount
 name: nirmata-controller
 namespace: nirmata
```text
</details>

<details>
<summary>nirmata:policyexception-manager</summary>

```yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
 name: nirmata:policyexception-manager
roleRef:
 apiGroup: rbac.authorization.k8s.io
 kind: ClusterRole
 name: nirmata:policyexception-manager
subjects:
 - kind: ServiceAccount
 name: nirmata
 namespace: nirmata
 - kind: ServiceAccount
 name: kyverno-cleanup-controller
 namespace: kyverno 
```text
</details>

### RoleBinding
<details>
<summary>nirmata-admin-binding</summary>

```yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
 name: nirmata-admin-binding
 namespace: nirmata
roleRef:
 apiGroup: rbac.authorization.k8s.io
 kind: ClusterRole
 name: admin
subjects:
 - kind: ServiceAccount
 name: nirmata
 namespace: nirmata
```text
</details>

### Secret

<details>
<summary>nirmata-sa-secret</summary>

```yaml
apiVersion: v1
kind: Secret
metadata:
 name: nirmata-sa-secret
 namespace: nirmata
 annotations:
 kubernetes.io/service-account.name: nirmata
type: kubernetes.io/service-account-token
```text
</details>

Quick Start

Mon, 01 Jan 0001 00:00:00 +0000

Applies to: nctl 4.0 and later

The Nirmata Controller (nctl) is a command line application that makes it easy to scan Kubernetes, Terraform, Dockerfiles and other resources for misconfigurations using default or custom Kyverno policy sets.

You can use nctl to apply policies and shift-left by applying policies to Kubernetes and IaC resources directly in your code repositories, or to scan Kubernetes clusters without installing a policy engine as an admission controller in each cluster.

Image Verification using Nirmata

Sun, 06 Apr 2025 00:00:00 +0000

Steps for Image Verification

Below are the steps to verify images before deployment to Kubernetes runtime environments:

Deploy Enterprise Kyverno to the Workload cluster
(Optional) If your local image registry uses a custom CA, configure Kyverno to use this custom CA for verifying locally hosted images
Leverage cosign cli to sign the images. Ensure that the node where cosign is installed has the private CA added to its keystore
Deploy the image verification Kyverno policy
Confirm image verification based on policy pass/fail

Prerequisites

Install cosign: Installation Guide
(Optional) When using a local registry with a custom certificate authority (CA), retain the full certificate chain for use during configuration

Sign Image using cosign

To sign your container images, you’ll need to generate a key pair and use it to sign your images. This process ensures the authenticity and integrity of your container images.

AWS Asset Discovery Guide

Mon, 01 Jan 0001 00:00:00 +0000

Introduction

This guide provides a detailed walkthrough for setting up and using the AWS Organisation and Account Discovery feature in Nirmata Cloud Controller. This feature allows for comprehensive discovery of AWS accounts, organisational units (OUs), and EKS clusters within an AWS Organisation. The discovery process follows a hierarchical approach: OUs are discovered first, then accounts within those OUs, and finally EKS clusters within the discovered accounts.

Prerequisites

Before you begin, ensure you meet the following prerequisites:

GitHub App Integration Overview

Mon, 01 Jan 0001 00:00:00 +0000

Applies to: Nirmata Control Hub 4.0 and later

The GitHub App Integration enables seamless integration between Nirmata and your GitHub repositories. By installing Nirmata’s GitHub App, you can enable GitOps workflows, automated policy remediation, and other Git-based operations across your Nirmata platform.

This integration is used by:

AI Agents (e.g., Remediator Agent) for creating pull requests with policy fixes
GitOps workflows for repository synchronization
Policy management for Git-based policy storage
Compliance operations for tracking and remediating violations

Benefits

One-Click Installation: Install Nirmata’s GitHub App directly from the UI
Enhanced Security: Uses short-lived tokens with fine-grained permissions
Centralized Management: Manage GitHub integration through Nirmata Control Hub
Enterprise Ready: Designed for organizational use with proper access control
Audit Trail: Complete tracking and logging of all GitHub operations
Multi-Organization Support: Install across multiple GitHub organizations
No Secret Management: No need to manage tokens or keys manually

Next Steps

To install and configure the integration, see GitHub App Integration.
To understand what the app can and cannot access, see GitHub App Permissions.

Terraform Cloud Integration Overview

Mon, 01 Jan 0001 00:00:00 +0000

Applies to: Nirmata Control Hub 4.0 and later

When a Terraform run reaches the Plan stage, Terraform Cloud triggers a webhook to the Nirmata Terraform Service. This service evaluates the Terraform plan using NCTL (Nirmata CLI) and policy sets managed within Nirmata Control Hub. The results are returned to TFC as pass/fail compliance checks.

Key Components

Component	Description
Nirmata Control Hub Webapp & API	Manages integrations, authentication keys, and displays scan results.
Terraform Service	Receives webhooks, fetches policy sets, and invokes NCTL scans.
NCTL	CLI tool that evaluates Terraform plans against Nirmata and Kyverno policy sets.
TFC Run Task	Executes during Terraform plan runs and triggers compliance scans.

Architecture

flowchart TD
 A[TFC Run Task Triggered] --> B[Nirmata Terraform Service (Webhook)]
 B --> C[Policy Fetch (from Nirmata Control Hub / Git)]
 C --> D[NCTL Policy Scan]
 D --> E[Results sent to Terraform Cloud & Nirmata Control Hub]

Flow Summary: Terraform Cloud Run → Webhook (Terraform Service) → Policy Fetch (Nirmata Control Hub/Git) → NCTL Scan → Results → TFC/Nirmata Control Hub

Account

Mon, 01 Jan 0001 00:00:00 +0000

Users can verify their Nirmata subscription details in Settings > Account. In the subscription section, the following details are available:

Type
Start Date
License Key

Users can also view their Nirmata Quotas and Usage details in Settings > Account. The Quotas and Usage section displays the following metrics:

Clusters
Nodes
Pods
Namespaces

AI Usage

Users can monitor their AI usage and credits in the AI Usage tab within Settings > Account. This section provides detailed tracking of AI-powered feature consumption, including:

Getting Started

Mon, 01 Jan 0001 00:00:00 +0000

Quick Start

This guide will help you get started with Kyverno MCP in minutes.

Prerequisites

Before you begin, ensure you have:

Access to a Kubernetes cluster
A valid kubeconfig file
Kyverno installed in your cluster (optional, but recommended)

Step 1: Install Kyverno MCP

Choose your preferred installation method:

Using Homebrew (macOS/Linux)

brew tap nirmata/tap
brew install kyverno-mcp
```json

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

### Step 2: Configure Your MCP Client

Add Kyverno MCP to your MCP client configuration. For example, in Claude Desktop:

1. Open your Claude Desktop configuration file:
 - macOS: `~/Library/Application Support/Claude/claude_desktop_config.json`
 - Windows: `%APPDATA%\Claude\claude_desktop_config.json`

2. Add the Kyverno MCP server:
```json
{
 "mcpServers": {
 "kyverno": {
 "command": "/path/to/kyverno-mcp",
 "args": [
 "--kubeconfig=/path/to/your/kubeconfig"
 ]
 }
 }
}

Step 3: Test the Connection

Start your MCP client (e.g., Claude Desktop)
Ask about your Kubernetes contexts:

3. The assistant should be able to list your contexts using the `list_contexts` tool

### Step 4: Apply Your First Policy

Try scanning your cluster with recommended policy sets for pod security, RBAC and Kubernetes best practices:

```text
Scan my cluster for policy violations

The assistant will use the apply_policies tool to apply curated pod security policies.

GitHub Authentication Guide

Mon, 01 Jan 0001 00:00:00 +0000

Overview

Nirmata AI Agents support multiple GitHub authentication methods to integrate with your GitHub repositories. This guide helps you choose the right authentication method and configure it properly.

Recommended Method: Use Nirmata’s GitHub App for the simplest, most secure integration. Install it once from Nirmata Control Hub, and it works across all GitOps operations.

Authentication Methods

1. Nirmata GitHub App (Recommended)

Best for: Production environments and all GitOps operations

The Nirmata GitHub App method provides the simplest and most secure authentication. Simply install Nirmata’s GitHub App from the Control Hub UI - no need to create your own GitHub App or manage secrets.

Installation

Mon, 01 Jan 0001 00:00:00 +0000

The Nirmata CLI is available on Linux, macOS, and Windows.

Homebrew

Download and install the latest stable release of the notation CLI on macOS, Linux, or Windows Subsystem for Linux (WSL) using Homebrew:

Install

brew tap nirmata/tap
brew install nctl

Verify

You can verify the nctl installation by checking its version:

nctl version

Upgrade

brew upgrade nctl

Uninstall

brew uninstall nctl

To remove the Nirmata homebrew tap:

brew untap nirmata/tap

Binary download

Download the latest stable release of the Nirmata CLI binary.

nctl

Mon, 01 Jan 0001 00:00:00 +0000

nctl

nctl is the command line interface for Nirmata

nctl [flags]

Examples


 # Scan a Kubernetes cluster and analyze and publish the scan results
 nctl scan kubernetes --cluster --analyze --publish

 # Scan Kubernetes manifests, Dockerfiles, and Terraform code in a repository
 nctl scan repository https://github.com/nirmata/demo-resources

 # Scan the current directory
 nctl scan repository 

```bash

### Options

```text
 -h, --help help for nctl
 -v, --v Level number for the log level verbosity

nctl add

Mon, 01 Jan 0001 00:00:00 +0000

nctl add

Add resources to Nirmata Control Hub

Options

 -h, --help help for add
```text

### Options inherited from parent commands

```text
 -v, --v Level number for the log level verbosity

nctl add cluster

Mon, 01 Jan 0001 00:00:00 +0000

nctl add cluster

Add cluster

nctl add cluster [flags]

Examples


 # Add a cluster with a specified name and onboarding token
 nctl add cluster --cluster-name my-cluster --onboarding-token abc123xyz

 # Add a cluster using a values file for onboarding parameters
 nctl add cluster -f /path/to/values.yaml

 # Specify a custom Helm repository and release name
 nctl add cluster --helm-repo https://custom.repo.com/helm-charts -r custom-release

 # Use a private Helm repository with authentication
 nctl add cluster --helm-repo https://private.repo.com/helm-charts -t my-private-repo-token

 # Register a cluster without installing the operator
 nctl add cluster --cluster-name my-cluster --register-only

 # Deploy Kyverno with a specific version in a custom namespace
 nctl add cluster --kyverno-version 1.12 -n custom-namespace

 # Use a custom Kubeconfig file and context for the cluster
 nctl add cluster --kubeconfig /path/to/kubeconfig --kube-context my-context

 # Specify a private container registry
 nctl add cluster --registry-name my-private-registry --registry-username myuser --registry-password mypassword

 # Allow connections to an address with a self-signed or unverified certificate (not recommended)
 nctl add cluster --insecure

```bash

### Options

```text
 --cluster-name string name of the cluster to onboard is required (not needed if onboarding token is provided)
 -t, --git-token string token for the operator helm chart in private helm repo
 --helm-repo string operator helm repository name (default "https://nirmata.github.io/kyverno-charts")
 -h, --help help for cluster
 --insecure allow connection to a Nirmata server with a insecure certificate (not recommended)
 --kube-context string the kube context from configured kubeconfig. Default is the current or sole context
 --kubeconfig string kubeconfig path (defaults to $HOME/.kube/kubeconfig)
 --kyverno-version string Kyverno version 1.11 (default "1.11")
 -n, --namespace string operator namespace (default "nirmata-system")
 --npm-only npm only mode for the operator
 --onboarding-token string the cluster onboarding token
 --register-only only register cluster, don't install operator
 --registry-name string name of the private registry (no need if images are not pushed to private registry)
 --registry-password string password of the private registry (no need if images are not pushed to private registry)
 --registry-username string user name of the private registry (no need if images are not pushed to private registry)
 -r, --release string operator helm chart release name (default "kyverno-operator")
 --token string the Nirmata API Login Key (env NIRMATA_TOKEN)
 --url string the Nirmata server base URL (env NIRMATA_URL)
 -f, --values-file string the cluster onboarding parameter YAML file
 --yes bypass manual validation
```text

### Options inherited from parent commands

```text
 -v, --v Level number for the log level verbosity

nctl ai

Mon, 01 Jan 0001 00:00:00 +0000

nctl ai

Agentic AI powered workflows

nctl ai [flags]

Examples


 # Run an interactive AI workflow.
 nctl ai

 # Run an interactive AI workflow with a specific prompt.
 nctl ai --prompt "generate a Kyverno policy that enforces all pods have a 'team' label"

 # Use a different LLM provider (e.g., Gemini, Anthropic, or Bedrock).
 nctl ai --provider gemini --model gemini-2.5-pro
 nctl ai --provider anthropic --model claude-sonnet-4-20250514
 nctl ai --provider bedrock --model us.anthropic.claude-sonnet-4-20250514-v1:0

 # Allow AI to access additional directories.
 nctl ai --allowed-dirs "/path/to/policies,/tmp" --prompt "create pod security policies in /path/to/policies"

 # Load custom skills from local path
 nctl ai --skills "/path/to/custom-skill" --prompt "use custom skill"

 # Resume a previous session.
 nctl ai --resume-session latest
 nctl ai --resume-session 20251125-0120

 # List all available sessions.
 nctl ai --list-sessions

 # Use a custom MCP configuration file.
 nctl ai --mcp-config "/path/to/custom/mcp.yaml"

 # Start nctl as an MCP server for external AI clients.
 nctl ai --mcp-server

 # Start MCP server with verbose logging.
 nctl ai --mcp-server -v 1

```bash

### Options

```text
 --allowed-dirs strings additional directories the AI can access (comma-separated, env: NIRMATA_AI_ALLOWED_DIRS)
 --delete-session string delete a session by ID
 --force allow destructive operations in non-interactive mode (requires both --prompt and --skip-permission-checks)
 -h, --help help for ai
 --insecure allow connection to a Nirmata server with a insecure certificate (not recommended)
 --list-sessions list all available sessions
 --max-background-workers int maximum number of background workers that can be spawned in a single tool call (default: 3) (default 3)
 --max-tool-calls int maximum number of tool calls to make (default 200)
 --mcp-config string path to MCP configuration file (default: ~/.nirmata/nctl/mcp.yaml)
 --mcp-server run a MCP (Model Context Protocol) server for Nirmata AI tools
 --mcp-server-port int port to run the MCP (Model Context Protocol) server on when using http transport (default 8080)
 --mcp-server-transport string transport to use for the MCP (Model Context Protocol) server (stdio or http) (default "stdio")
 --new-session create a new session
 --plan force plan mode for all tasks (even simple ones)
 --prompt string prompt for the AI workflow
 --resume-session string ID of session to resume (use 'latest' for the most recent session)
 --skills strings load custom skills from local paths (comma-separated, env: NIRMATA_AI_SKILLS)
 --skip-permission-checks skip permission checks for tools (not recommended)
 --token string the Nirmata API Login Key (env NIRMATA_TOKEN)
 --url string the Nirmata server base URL (env NIRMATA_URL)
 --usage-details show AI usage details and exit
```text

### Options inherited from parent commands

```text
 -v, --v Level number for the log level verbosity

nctl compliance

Mon, 01 Jan 0001 00:00:00 +0000

nctl compliance

Compliance management commands

nctl compliance [flags]

Options

 -h, --help help for compliance
```text

### Options inherited from parent commands

```text
 -v, --v Level number for the log level verbosity

nctl compliance audit

Mon, 01 Jan 0001 00:00:00 +0000

nctl compliance audit

Collect compliance evidence from a Kubernetes cluster

nctl compliance audit [flags]

Examples

 # Collect SOC2 evidence package
 nctl compliance audit --standard soc2

 # Collect NIST 800-53 evidence for specific namespaces
 nctl compliance audit --standard nist-800-53 --namespace production,staging

 # Write evidence to a custom directory
 nctl compliance audit --standard soc2 --output-dir /tmp/evidence
```bash

### Options

```text
 -h, --help help for audit
 --kube-context string the kube context from configured kubeconfig. Default is the current or sole context
 --kubeconfig string kubeconfig path (defaults to $HOME/.kube/kubeconfig)
 --mappings-file string Override path to mappings YAML file
 -o, --output string Output format for the collection summary (text, json, yaml) (default "text")
 --output-dir string Directory for evidence output (default: ~/.nirmata/nctl/compliance/evidence/)
 --standard string Compliance standard (soc2, nist-800-53, nsa-cisa, iso27001, pci-dss, etc.)
```text

### Options inherited from parent commands

```text
 -v, --v Level number for the log level verbosity

nctl compliance checklist

Mon, 01 Jan 0001 00:00:00 +0000

nctl compliance checklist

Show compliance checklist with pass/fail status for a standard

nctl compliance checklist [flags]

Examples

 # Show SOC2 compliance checklist
 nctl compliance checklist --standard soc2

 # Show NIST 800-53 checklist in JSON format
 nctl compliance checklist --standard nist-800-53 -o json

 # Show checklist with custom mappings
 nctl compliance checklist --standard soc2 --mappings-file /path/to/mappings.yaml

Options

 -h, --help help for checklist
 --mappings-file string Override path to mappings YAML file
 -o, --output string Output format (text, json, yaml, openreport) (default "text")
 --standard string Compliance standard (soc2, nist-800-53, nsa-cisa, iso27001, pci-dss, etc.)
```text

### Options inherited from parent commands

```text
 -v, --v Level number for the log level verbosity

nctl create

Mon, 01 Jan 0001 00:00:00 +0000

nctl create

Create policyexceptionrequests

Options

 -h, --help help for create
```text

### Options inherited from parent commands

```text
 -v, --v Level number for the log level verbosity

nctl create pull-request

Mon, 01 Jan 0001 00:00:00 +0000

nctl create pull-request

Create policyexceptionrequests made in Nirmata Control Hub

nctl create pull-request [flags]

Examples


 # Basic pull-request command 
 nctl create pull-request 

 # Specify PER name 
 nctl create pull-request --per-name your-per-name 

 # Specify VCS provider 
 nctl create pull-request --provider github 

 # Specify both PER name and VCS provider 
 nctl create pull-request --per-name your-per-name --provider github

Options

 -h, --help help for pull-request
 --insecure allow connection to a Nirmata server with a insecure certificate (not recommended)
 --per-name string Name of PER to be considered
 -p, --provider string Name of VCS provider to create PER (default "github")
 --token string the Nirmata API Login Key (env NIRMATA_TOKEN)
 --url string the Nirmata server base URL (env NIRMATA_URL)
```text

### Options inherited from parent commands

```text
 -v, --v Level number for the log level verbosity

nctl edit

Mon, 01 Jan 0001 00:00:00 +0000

nctl edit

Edit nctl resources

Options

 -h, --help help for edit
```text

### Options inherited from parent commands

```text
 -v, --v Level number for the log level verbosity

nctl edit config

Mon, 01 Jan 0001 00:00:00 +0000

nctl edit config

Edit nctl configuration file

Synopsis

Edit nctl configuration file by opening editor or entering values of repository to add

nctl edit config [flags]

Examples


 # Add a repository with a name, type, and authentication details 
 nctl edit config --name my-repo --type helm --username example-user --gitToken example-token --file=false 

 # Add a repository with a specific chart repository URL and branch 
 nctl edit config --name nirmata/kyverno-charts --chartRepo https://nirmata.github.io/kyverno-charts --branch main --file=false 

 # Add a Helm chart with a name, version, and authentication token 
 nctl edit config --chartName my-chart --version 1.2.3 --gitToken example-token --file=false 

 # Add a repository with a branch and authentication token 
 nctl edit config --name my-repo --branch dev --gitToken example-token --file=false 

 # Add multiple repository details including username, type, and branch 
 nctl edit config --name my-repo --type helm --username example-user --branch main --gitToken example-token --file=false 

 # Add a repository from a specific branch, chart repository, and authentication 
 nctl edit config --name my-repo --branch dev --chartRepo https://charts.example.com --username example-user --gitToken example-token --file=false

Options

 --branch string Branch of the repository to add
 --chartName string Name of the chart to add
 --chartRepo string URL of the chart repository to add
 --file enable to open config file in editor to edit config file (default true)
 --gitToken string Git token for authentication to add
 -h, --help help for config
 --name string Name of the repository to add
 --type string Type of the repository to add
 --username string Username for authentication to add
 --version string Version of the chart to add
```text

### Options inherited from parent commands

```text
 -v, --v Level number for the log level verbosity

nctl exceptions

Mon, 01 Jan 0001 00:00:00 +0000

nctl exceptions

Manage Kyverno PolicyExceptions

nctl exceptions [flags]

Options

 -h, --help help for exceptions
```text

### Options inherited from parent commands

```text
 -v, --v Level number for the log level verbosity

nctl exceptions audit

Mon, 01 Jan 0001 00:00:00 +0000

nctl exceptions audit

Audit Kyverno PolicyException resources

nctl exceptions audit [flags]

Examples

 # Audit all policy exceptions
 nctl exceptions audit

 # Show only exceptions older than 90 days
 nctl exceptions audit --older-than 90

 # Show only expired exceptions
 nctl exceptions audit --expired

 # Filter by namespace
 nctl exceptions audit --namespace default

 # Output as JSON
 nctl exceptions audit -o json

Options

 --expired Only show exceptions past their expiry date
 -h, --help help for audit
 --kube-context string the kube context from configured kubeconfig. Default is the current or sole context
 --kubeconfig string kubeconfig path (defaults to $HOME/.kube/kubeconfig)
 --namespace string Filter by namespace (default: all namespaces)
 --older-than int Only show exceptions older than N days
 -o, --output string Output format (text, json, yaml, openreport) (default "text")
```text

### Options inherited from parent commands

```text
 -v, --v Level number for the log level verbosity

nctl get

Mon, 01 Jan 0001 00:00:00 +0000

nctl get

Get Nirmata Control Hub resources

Options

 -h, --help help for get
```text

### Options inherited from parent commands

```text
 -v, --v Level number for the log level verbosity

nctl get clusters

Mon, 01 Jan 0001 00:00:00 +0000

nctl get clusters

Get cluster information

nctl get clusters [flags]
```text

### Examples

```text

 # List all clusters that are onboarded to Nirmata Control Hub 
 nctl get clusters 

 # Get detailed information about a specific cluster 
 nctl get clusters <cluster-name> 

 # Show additional details about all clusters 
 nctl get clusters --wide 

 # Allow connections to an address with a self-signed or unverified certificate (not recommended) 
 nctl get clusters --insecure

Options

 -h, --help help for clusters
 --insecure allow connection to a Nirmata server with a insecure certificate (not recommended)
 --token string the Nirmata API Login Key (env NIRMATA_TOKEN)
 --url string the Nirmata server base URL (env NIRMATA_URL)
 --wide to show extra cluster details
```text

### Options inherited from parent commands

```text
 -v, --v Level number for the log level verbosity

nctl get operator

Mon, 01 Jan 0001 00:00:00 +0000

nctl get operator

Get Nirmata Kyverno Operator info

Options

 -h, --help help for operator
```text

### Options inherited from parent commands

```text
 -v, --v Level number for the log level verbosity

nctl get operator helm-values

Mon, 01 Jan 0001 00:00:00 +0000

nctl get operator helm-values

Get Nirmata Kyverno Operator Helm Values for further customization

nctl get operator helm-values [flags]

Options

 -h, --help help for helm-values
 --kube-context string the kube context from configured kubeconfig. Default is the current or sole context
 --kubeconfig string kubeconfig path (defaults to $HOME/.kube/kubeconfig)
 -n, --namespace string namespace in which the operator is deployed (default "nirmata-system")
 --no-cluster prevent all calls to cluster
 -o, --outputfile string output file to store Helm values
 -r, --release string release name for the helm chart (default "kyverno-operator")
```text

### Options inherited from parent commands

```text
 -v, --v Level number for the log level verbosity

nctl get policy-sets

Mon, 01 Jan 0001 00:00:00 +0000

nctl get policy-sets

Get policy-sets

nctl get policy-sets [flags]

Examples


 # Get list of Policy Sets available.
 nctl get policy-sets

Options

 -h, --help help for policy-sets
```text

### Options inherited from parent commands

```text
 -v, --v Level number for the log level verbosity

nctl get policyexceptionrequests

Mon, 01 Jan 0001 00:00:00 +0000

nctl get policyexceptionrequests

Get PolicyExceptionRequest resources

nctl get policyexceptionrequests [flags]

Examples


 # Get all policy exception requests
 nctl get policyexceptionrequests

 # Get policy exception requests with a specific name
 nctl get policyexceptionrequests --name example-policy

 # Get policy exception requests by requester
 nctl get policyexceptionrequests --requested-by npm-automation-devops

 # Get policy exception requests filtered by state (approved, rejected, pendingApproval)
 nctl get policyexceptionrequests --state approved

 # Get policy exception requests from an insecure server (not recommended)
 nctl get policyexceptionrequests --insecure

Options

 -h, --help help for policyexceptionrequests
 --insecure allow connection to a Nirmata server with a insecure certificate (not recommended)
 --name string Name of policy exception to filter by
 --requested-by string State of policy exception to filter by Requester
 --state string State of policy exception to filter by (approved, rejected, pendingApproval)
 --token string the Nirmata API Login Key (env NIRMATA_TOKEN)
 --url string the Nirmata server base URL (env NIRMATA_URL)
```text

### Options inherited from parent commands

```text
 -v, --v Level number for the log level verbosity

nctl info

Mon, 01 Jan 0001 00:00:00 +0000

nctl info

Account and User Information

nctl info [flags]

Options

 -h, --help help for info
 --insecure allow connection to a Nirmata server with a insecure certificate (not recommended)
 --token string the Nirmata API Login Key (env NIRMATA_TOKEN)
 --url string the Nirmata server base URL (env NIRMATA_URL)
 --userid string user id (email)
```text

### Options inherited from parent commands

```text
 -v, --v Level number for the log level verbosity

nctl login

Mon, 01 Jan 0001 00:00:00 +0000

Provide authentication details to login

nctl login [flags]

Options

 -f, --file string the configuration file (defaults to $HOME/.nirmata/config)
 -h, --help help for login
 --insecure allow connection to a Nirmata server with a insecure certificate (not recommended)
 --token string the Nirmata API Login Key (env NIRMATA_TOKEN)
 --url string the Nirmata server base URL (env NIRMATA_URL)
 --userid string user id (email)
```text

### Options inherited from parent commands

```text
 -v, --v Level number for the log level verbosity

nctl login git

Mon, 01 Jan 0001 00:00:00 +0000

nctl login git [flags]

Examples


 # Login to Git provider (GitHub, GitLab, Bitbucket) using a token
 nctl login git --provider github --username myuser --token ghp_xxx

 # Login to GitLab with a custom domain and authentication token
 nctl login git --provider gitlab --domain gitlab.example.com --username myuser --token glpat_xxx

 # Login to Bitbucket using a username and token
 nctl login git --provider bitbucket --username myuser --token bitbucket_xxx

 # Login to a self-hosted GitLab instance with a domain
 nctl login git --provider gitlab --domain gitlab.mycompany.com

 # Login interactively to Git (prompt for username and token)
 nctl login git --provider github

Options

 --domain string custom domain for the VCS
 -h, --help help for git
 --provider string git provider (defaults to github) (default "github")
 --token string git authentication token
 --username string user id (email)
```text

### Options inherited from parent commands

```text
 -v, --v Level number for the log level verbosity

nctl login nch

Mon, 01 Jan 0001 00:00:00 +0000

nctl login nch [flags]

Examples


 # Login to Nirmata Control Hub using an email and API key
 nctl login nch --userid user@example.com --token my-api-key

 # Login to Nirmata using a specific server URL
 nctl login nch --userid user@example.com --token my-api-key --url https://nirmata.example.com

 # Login using a configuration file
 nctl login nch --file /path/to/config.yaml

 # Login interactively (prompt for email and API key)
 nctl login nch

Options

 -f, --file string the configuration file (defaults to $HOME/.nirmata/config)
 -h, --help help for nch
 --insecure allow connection to a Nirmata server with a insecure certificate (not recommended)
 --token string the Nirmata API Login Key (env NIRMATA_TOKEN)
 --url string the Nirmata server base URL (env NIRMATA_URL)
 --userid string user id (email)
```text

### Options inherited from parent commands

```text
 -v, --v Level number for the log level verbosity

nctl mappings

Mon, 01 Jan 0001 00:00:00 +0000

nctl mappings

Work with compliance policy mappings

nctl mappings [flags]

Options

 -h, --help help for mappings
```text

### Options inherited from parent commands

```text
 -v, --v Level number for the log level verbosity

nctl mappings get

Mon, 01 Jan 0001 00:00:00 +0000

nctl mappings get

Get control mappings for a compliance standard or policy

nctl mappings get [standard] [flags]
```text

### Examples

```text
 # Get all policy→control mappings for SOC2
 nctl mappings get soc2

 # Look up which standards and controls a specific policy covers
 nctl mappings get --policy restrict-cluster-admin-binding

 # JSON output
 nctl mappings get soc2 -o json
 nctl mappings get --policy restrict-cluster-admin-binding -o json

Options

 -h, --help help for get
 --mappings-file string Override path to mappings YAML file
 -o, --output string Output format (text, json, yaml) (default "text")
 --policy string Look up a specific policy by name across all standards
```text

### Options inherited from parent commands

```text
 -v, --v Level number for the log level verbosity

nctl mappings list

Mon, 01 Jan 0001 00:00:00 +0000

nctl mappings list

List available compliance standards

nctl mappings list [flags]

Examples

 # List all available compliance standards
 nctl mappings list

 # Filter to a single standard
 nctl mappings list --standard soc2

 # List in JSON format
 nctl mappings list -o json

Options

 -h, --help help for list
 --mappings-file string Override path to mappings YAML file
 -o, --output string Output format (text, json, yaml) (default "text")
 --standard string Filter to a single compliance standard
```text

### Options inherited from parent commands

```text
 -v, --v Level number for the log level verbosity

nctl mappings path

Mon, 01 Jan 0001 00:00:00 +0000

nctl mappings path

Print the path to the mappings file, or the policy directory path within kyverno-policies

nctl mappings path [flags]

Examples

 # Print the path to the embedded (cached) mappings file
 nctl mappings path

 # Show the directory path for a specific policy within kyverno-policies
 nctl mappings path --policy restrict-cluster-admin-binding

Options

 -h, --help help for path
 --mappings-file string Path to a custom mappings YAML file
 --policy string Show the directory path for a specific policy within kyverno-policies
```text

### Options inherited from parent commands

```text
 -v, --v Level number for the log level verbosity

nctl raw

Mon, 01 Jan 0001 00:00:00 +0000

nctl raw

Direct access to the Nirmata REST API

Synopsis

The raw command allows querying Nirmata REST API endpoints.

nctl raw <path> [flags]

Examples


 # Basic GET request 
 nctl raw /path --url https://example.com 

 # GET request with authentication 
 nctl raw /path --url https://example.com --token your-api-token 

 # GET request allowing insecure connection 
 nctl raw /path --url https://example.com --insecure 

 # GET request with json data in a file 
 nctl raw /path --url https://example.com --file data.json

Options

 -d, --data string JSON data string
 -f, --file string JSON data file
 -h, --help help for raw
 --insecure allow connection to an address with a self-signed or non-verifiable certificate (not recommended)
 -m, --method string the HTTP method (default "GET")
 --token string Nirmata API Login Key (env NIRMATA_TOKEN)
 --url string Nirmata server base URL (env NIRMATA_URL)
```text

### Options inherited from parent commands

```text
 -v, --v Level number for the log level verbosity

nctl remediate

Mon, 01 Jan 0001 00:00:00 +0000

nctl remediate

Remediate a resource file or directory for policy violations

nctl remediate <resource file or directory> [flags]

Options

 --cluster-policies Use policies from a cluster (default false)
 --details Show result details for violating resources (default true)
 --file string[="scan-report"] Output file (if --file is used without a value, defaults to 'scan-report')
 -h, --help help for remediate
 --no-color disable the colors for the stdout reports
 -o, --output string Output format (text, json, yaml, scan-report, sarif) (default "text")
 --patch Update the source file with the remediated resource (default true)
 -p, --policies strings Path to policy files
 --policy-sets strings Policy set names (comma separated e.g., "pss-baseline, pss-restricted, rbac-best-practices")
```text

### Options inherited from parent commands

```text
 -v, --v Level number for the log level verbosity

nctl remove

Mon, 01 Jan 0001 00:00:00 +0000

nctl remove

Remove Nirmata Control Hub resources

Options

 -h, --help help for remove
```text

### Options inherited from parent commands

```text
 -v, --v Level number for the log level verbosity

nctl remove cluster

Mon, 01 Jan 0001 00:00:00 +0000

nctl remove cluster

Remove cluster

nctl remove cluster [flags]

Examples


 # Remove a cluster using its name
 nctl remove cluster --cluster-name my-cluster

 # Remove a cluster using its unique cluster ID (Overrides name if provided)
 nctl remove cluster --cluster-id my-cluster-id

 # Deregister a cluster from Nirmata Control Hub without uninstalling components
 nctl remove cluster --cluster-name my-cluster --deregister-only

 # Remove only the operator from the cluster without removing other components
 nctl remove cluster --cluster-name my-cluster --remove-operator-only

 # Forcefully remove a cluster, ignoring the kube-system namespace UID check
 nctl remove cluster --cluster-name my-cluster --force

 # Remove a cluster by specifying a custom kubeconfig file and context
 nctl remove cluster --cluster-name my-cluster --kubeconfig /path/to/kubeconfig --kube-context my-context

 # Remove a cluster while allowing connection to an address with a self-signed or unverified certificate (not recommended)
 nctl remove cluster --cluster-name my-cluster --insecure

 # Remove a cluster using Nirmata credentials
 nctl remove cluster --cluster-name my-cluster --token my-nirmata-token --url https://nirmata.example.com

```bash

### Options

```text
 --cluster-id string the Nirmata Control Hub cluster Id of cluster to be removed (Overrides name. Needed if cluster name is not unique)
 --cluster-name string the Nirmata Control Hub cluster name of cluster to be removed
 --crd-release string release name for the operator CRD helm chart (default "kyverno-operator-crd")
 --deregister-only only deresgisters cluster from nch
 --force force remove cluster ignoring empty kube-system namespace uid check
 -h, --help help for cluster
 --insecure allow connection to a Nirmata server with a insecure certificate (not recommended)
 --kube-context string the kube context from configured kubeconfig. Default is the current or sole context
 --kubeconfig string kubeconfig path (defaults to $HOME/.kube/kubeconfig)
 -n, --namespace string namespace in which the operator is deployed (default "nirmata-system")
 --release string release name for the operator helm chart (default "kyverno-operator")
 --remove-operator-only remove only operator from cluster, removes all components by default
 --timeout duration time to wait until the operation terminates (default 10m0s)
 --token string the Nirmata API Login Key (env NIRMATA_TOKEN)
 --url string the Nirmata server base URL (env NIRMATA_URL)
```text

### Options inherited from parent commands

```text
 -v, --v Level number for the log level verbosity

nctl scan

Mon, 01 Jan 0001 00:00:00 +0000

nctl scan

Scan resources

Examples


 # Scan a Kubernetes cluster and analyze and publish the scan results
 nctl scan kubernetes --cluster --analyze --publish

 # Scan Kubernetes manifests, Dockerfiles, and Terraform code in a repository
 nctl scan repository https://github.com/nirmata/demo-resources

 # Scan the current directory
 nctl scan repository

Options

 -h, --help help for scan
```text

### Options inherited from parent commands

```text
 -v, --v Level number for the log level verbosity

nctl scan compliance

Mon, 01 Jan 0001 00:00:00 +0000

nctl scan compliance

Run a compliance scan against a Kubernetes cluster

nctl scan compliance [flags]

Examples

 # Run a SOC2 compliance scan (fetches policies from github.com/nirmata/kyverno-policies by default)
 nctl scan compliance --standard soc2

 # Scan specific namespaces
 nctl scan compliance --standard nist-800-53 --namespace production,staging

 # Output results as JSON
 nctl scan compliance --standard soc2 -o json

 # Use a local kyverno-policies checkout instead of fetching from GitHub
 # (set once in ~/.nirmata/nctl/nctl_config.yaml: compliance.policies-root: /path/to/kyverno-policies)

 # Override with specific policy paths or GitHub URLs
 nctl scan compliance --standard soc2 \
 -p github.com/nirmata/kyverno-policies/best-practices-k8s \
 -p github.com/nirmata/kyverno-policies/compliance/cis/common

Options

 -h, --help help for compliance
 --kube-context string the kube context from configured kubeconfig. Default is the current or sole context
 --kubeconfig string kubeconfig path (defaults to $HOME/.kube/kubeconfig)
 --mappings-file string Override path to mappings YAML file
 --namespace stringArray Namespaces to scan (comma-separated or repeated flag)
 -o, --output string Output format (text, json, yaml, openreport) (default "text")
 -p, --policies strings Policy paths to scan (local path or github URL; comma-separated or repeated). Overrides the default mappings-derived policy set.
 --standard string Compliance standard (soc2, nist-800-53, nsa-cisa, iso27001, pci-dss, etc.)
```text

### Options inherited from parent commands

```text
 -v, --v Level number for the log level verbosity

nctl scan compliance diff

Mon, 01 Jan 0001 00:00:00 +0000

nctl scan compliance diff

Diff two compliance snapshots

nctl scan compliance diff [flags]

Examples

 # Diff latest vs previous scan
 nctl scan compliance diff --standard soc2

 # Diff latest vs 30 days ago
 nctl scan compliance diff --standard soc2 --days 30

 # Diff two specific snapshots
 nctl scan compliance diff --standard soc2 --from 20240101-100000 --to 20240115-100000

 # Output as JSON
 nctl scan compliance diff --standard soc2 -o json

Options

 --days int Compare latest snapshot vs N days ago
 --from string Snapshot ID to compare from (older)
 -h, --help help for diff
 -o, --output string Output format (text, json, yaml) (default "text")
 --standard string Compliance standard to diff
 --to string Snapshot ID to compare to (newer, defaults to latest)
```text

### Options inherited from parent commands

```text
 -v, --v Level number for the log level verbosity

nctl scan dockerfile

Mon, 01 Jan 0001 00:00:00 +0000

nctl scan dockerfile

scan dockerfile resources

nctl scan dockerfile [flags]

Examples


 # Scan a Dockerfile with a specific policy file and resource directory 
 nctl scan dockerfile --policies /path/to/sample-policy.yaml -r /path/to/sample-resources/ 

 # Scan a Dockerfile with a policies from a GitHub repository 
 nctl scan dockerfile --policies https://github.com/nirmata/kyverno-policies/tree/main/dockerfile-best-practices -r /path/to/sample-resources/ 

 # Scan and output a JSON report 
 nctl scan dockerfile --policies /path/to/sample-policy.yaml -r /path/to/sample-resources/ --scan-report /path/to/scan-report.json 

 # Scan and add a custom report source ID 
 nctl scan dockerfile --policies /path/to/sample-policy.yaml -r /path/to/sample-resources/ --report-sourceid sample-source-id 

 # Scan with violations in audit mode reported as warnings instead of failures 
 nctl scan dockerfile --policies /path/to/sample-policy.yaml -r /path/to/sample-resources/ --audit-as-warn 

 # Scan and display remediation suggestions 
 nctl scan dockerfile --policies /path/to/sample-policy.yaml -r /path/to/sample-resources/ --remediate display 

 # Scan and overwrite files with remediation 
 nctl scan dockerfile --policies /path/to/sample-policy.yaml -r /path/to/sample-resources/ --remediate overwrite 

 # Scan a Dockerfile and output results to console in JSON format
 nctl scan dockerfile --policies /path/to/sample-policy.yaml -r /path/to/sample-resources/ -o json

 # Specify output format and save results to a file with default name (scan-report.json)
 nctl scan dockerfile --policies /path/to/sample-policy.yaml -r /path/to/sample-resources/ -o json --file

 # Specify output format and save results to a file with user defined name
 nctl scan dockerfile --policies /path/to/sample-policy.yaml -r /path/to/sample-resources/ -o json --file=user-defined-name.json

```bash

### Options

```text
 --audit-as-warn Report violations from policies in audit mode as warnings instead of failures
 --details Show result details for violating resources (default true)
 --file string[="scan-report"] Output file (if --file is used without a value, defaults to 'scan-report')
 --git-token string Git authentication token (for Git URLs in --policies)
 --git-username string Git username (for Git URLs in --policies)
 -h, --help help for dockerfile
 --no-color disable the colors for the stdout reports
 -o, --output string Output format (text, json, yaml, scan-report, sarif) (default "text")
 -p, --policies strings Path to policy files (local path, github URL, helm URL)
 --publish Publish reports
 --publish-token string scan reports publish token
 --remediate string Remediate resources ('show', 'patch')
 --report-sourceid string Add source id for report created for local scan
 -r, --resources strings Path to resource files (local path, github URL)
 --scan-report string Output scan report file (in JSON format)
```text

### Options inherited from parent commands

```text
 -v, --v Level number for the log level verbosity

nctl scan github-actions

Mon, 01 Jan 0001 00:00:00 +0000

nctl scan github-actions

Scan GitHub Actions workflow files for security vulnerabilities

nctl scan github-actions [path] [flags]
```text

### Examples

```text

 # Scan the current directory for GitHub Actions workflows
 nctl scan github-actions

 # Scan a specific local repository path
 nctl scan github-actions /path/to/repo

 # Scan with additional custom policies on top of the built-in set
 nctl scan github-actions --policies ./my-policies --severity high

 # Output SARIF for GitHub Code Scanning integration
 nctl scan github-actions --output sarif > results.sarif

 # Publish results to Nirmata Control Hub
 nctl scan github-actions --publish

 # Scan and save a JSON report
 nctl scan github-actions --scan-report ./report.json

Options

 --audit-as-warn Report violations from policies in audit mode as warnings instead of failures
 --details Show result details for violating resources (default true)
 --file string[="scan-report"] Output file (if --file is used without a value, defaults to 'scan-report')
 --git-token string Git authentication token (for Git URLs in --policies)
 --git-username string Git username (for Git URLs in --policies)
 -h, --help help for github-actions
 --no-color disable the colors for the stdout reports
 -o, --output string Output format (text, json, yaml, scan-report, sarif) (default "text")
 -p, --policies strings Path to policy files (optional; bundled defaults used when omitted)
 --publish Publish reports
 --publish-token string scan reports publish token
 --remediate string Remediate resources ('show', 'patch')
 --report-sourceid string Add source id for report created for local scan
 --scan-report string Output scan report file (in JSON format)
```text

### Options inherited from parent commands

```text
 -v, --v Level number for the log level verbosity

nctl scan helm

Mon, 01 Jan 0001 00:00:00 +0000

nctl scan helm

scan helm-charts

nctl scan helm [flags]
```text

### Examples

```text

 # Scan a Helm chart from a local path
 nctl scan helm -r /path/to/helm-chart

 # Scan a Helm chart with a specific policy set
 nctl scan helm -r /path/to/helm-chart --policy-sets pss-baseline,pss-restricted

 # Scan a Helm chart with local and remote policy files
 nctl scan helm -r /path/to/helm-chart -p /path/to/policy.yaml,https://github.com/example/policy.yaml

 # Scan a Helm chart and output results to console
 nctl scan helm -r /path/to/helm-chart -o json

 # Specify output format and save results to a file with default name (scan-report.json)
 nctl scan helm -r /path/to/helm-chart -o json --file

 # Specify output format and save results to a file with user defined name
 nctl scan helm -r /path/to/helm-chart -o json --file=user-defined-name.json

 # Enable detailed result view for violating resources
 nctl scan helm -r /path/to/helm-chart --details

 # Disable color in the scan report output
 nctl scan helm -r /path/to/helm-chart --no-color

```text

### Options

```text
 --audit-as-warn Report violations from policies in audit mode as warnings instead of failures
 --details Show result details for violating resources (default true)
 --file string[="scan-report"] Output file (if --file is used without a value, defaults to 'scan-report')
 --git-token string Git authentication token (for Git URLs in --policies)
 --git-username string Git username (for Git URLs in --policies)
 -h, --help help for helm
 --insecure allow connection to a Nirmata server with a insecure certificate (not recommended)
 --no-color disable the colors for the stdout reports
 -o, --output string Output format (text, json, yaml, scan-report, sarif) (default "text")
 -p, --policies strings Path to policy files (local path, github URL, helm URL)
 --policy-sets strings Comma-separated policy set names (pss-baseline, pss-restricted, rbac-best-practices)
 --policy-view Use with --details to reverse the view from resource->policy to policy->resource
 --publish Publish reports
 --publish-token string scan reports publish token
 --report-sourceid string Add source id for report created for local scan
 -r, --resources strings Path to resource files (local path, github URL)
 --token string the Nirmata API Login Key (env NIRMATA_TOKEN)
 --url string the Nirmata server base URL (env NIRMATA_URL)
 --values string File containing values for policy variables
 --values-file strings Path to values files
```text

### Options inherited from parent commands

```text
 -v, --v Level number for the log level verbosity

nctl scan json

Mon, 01 Jan 0001 00:00:00 +0000

nctl scan json

scan json resources

nctl scan json [flags]

Examples


 # Basic scan with required resource and policy file
 nctl scan json -r path/to/file -p path/to/policy

 # Scan with audit mode enabled (violations reported as warnings)
 nctl scan json -r path/to/file -p path/to/policy --audit-as-warn

 # Scan with detailed results for violating resources
 nctl scan json -r path/to/file -p path/to/policy --details

 # Generate a scan report in JSON format
 nctl scan json -r path/to/file -p path/to/policy -o json --scan-report scan-report.json

 # Scan a JSON file and output results to console
 nctl scan json -r /path/to/file.json -p /path/to/policy -o json

 # Specify output format and save results to a file with default name (scan-report.json)
 nctl scan json -r /path/to/file.json -p /path/to/policy -o json --file

 # Specify output format and save results to a file with user defined name
 nctl scan json -r /path/to/file.json -p /path/to/policy -o json --file=user-defined-name.json

 # Disable colored output in the terminal
 nctl scan json -r path/to/file -p path/to/policy --no-color

```bash

### Options

```text
 --audit-as-warn Report violations from policies in audit mode as warnings instead of failures
 --details Show result details for violating resources (default true)
 --file string[="scan-report"] Output file (if --file is used without a value, defaults to 'scan-report')
 --git-token string Git authentication token (for Git URLs in --policies)
 --git-username string Git username (for Git URLs in --policies)
 -h, --help help for json
 --insecure allow connection to a Nirmata server with a insecure certificate (not recommended)
 --no-color disable the colors for the stdout reports
 -o, --output string Output format (text, json, yaml, scan-report, sarif) (default "text")
 -p, --policies strings Path to policy files (local path, github URL, helm URL)
 --publish Publish reports
 --publish-token string scan reports publish token
 --remediate string Remediate resources ('show', 'patch')
 --report-sourceid string Add source id for report created for local scan
 -r, --resources strings Path to resource files (local path, github URL)
 --scan-report string Output scan report file (in JSON format)
 --token string the Nirmata API Login Key (env NIRMATA_TOKEN)
 --url string the Nirmata server base URL (env NIRMATA_URL)
```text

### Options inherited from parent commands

```text
 -v, --v Level number for the log level verbosity

nctl scan kubernetes

Mon, 01 Jan 0001 00:00:00 +0000

nctl scan kubernetes

scan kubernetes resources

nctl scan kubernetes [flags]
```text

### Examples

```text

 # Scan a Kubernetes cluster and analyze the scan results
 nctl scan kubernetes --cluster --analyze

 # Scan a Kubernetes cluster and publish scan results
 nctl scan kubernetes --cluster --publish

 # Scan Kubernetes resources from a local file with a specific policy
 nctl scan kubernetes --resources ./resource.yaml --policies ./policy.yaml

 # Scan resources in a specific namespace using a policy set
 nctl scan kubernetes --namespace default --policy-sets pss-baseline

 # Scan a Kubernetes cluster using cluster policies and exceptions
 nctl scan kubernetes --cluster --cluster-policies --cluster-exceptions

 # Scan Kubernetes resources and output results to console in JSON format
 nctl scan kubernetes --cluster -o json

 # Specify output format and save results to a file with default name (scan-report.json)
 nctl scan kubernetes --cluster -o json --file

 # Specify output format and save results to a file with user defined name
 nctl scan kubernetes --cluster -o json --file=user-defined-name.json

 # Scan with a specific kubeconfig and context
 nctl scan kubernetes --kubeconfig /path/to/kubeconfig --kube-context my-context

 # Output the scan results in JSON format with detailed violations
 nctl scan kubernetes --resources ./resource.yaml --policies ./policy.yaml --details -o json

 # Scan resources while allowing insecure connections (not recommended)
 nctl scan kubernetes --resources ./resource.yaml --insecure

 # Scan and show remediation suggestions for violating resources
 nctl scan kubernetes --resources ./resource.yaml --remediate

```text

### Options

```text
 --analyze Analyze cluster using AI
 --audit-as-warn Report violations from policies in audit mode as warnings instead of failures
 --cluster Scan resources in a cluster using cluster policies and exceptions (default value false)
 --cluster-exceptions Use exceptions from a cluster (default value false)
 --cluster-name string Override name of cluster while publishing report to Nirmata Control Hub
 --cluster-policies Use policies from a cluster (default value false)
 --cluster-resources Use resources from a cluster (default value false)
 --continue-on-fail If set to true, will continue to apply policies on the next resource upon failure to apply to the current resource instead of exiting out
 --details Show result details for violating resources (default true)
 -e, --exceptions strings Policy exceptions to be considered when evaluating policies against resources
 --file string[="scan-report"] Output file (if --file is used without a value, defaults to 'scan-report')
 --git-token string Git authentication token (for Git URLs in --policies)
 --git-username string Git username (for Git URLs in --policies)
 -h, --help help for kubernetes
 --insecure allow connection to a Nirmata server with a insecure certificate (not recommended)
 --kube-context string the kube context from configured kubeconfig. Default is the current or sole context
 --kubeconfig string kubeconfig path (defaults to $HOME/.kube/kubeconfig)
 -l, --label strings Label the cluster and Label selector in the format key=value for policy sets in Nirmata Control Hub
 -n, --namespace strings Namespace of the resources to scan
 --no-color disable the colors for the stdout reports
 -o, --output string Output format (text, json, yaml, scan-report, sarif) (default "text")
 -p, --policies strings Path to policy files (local path, github URL, helm URL)
 --policy-sets strings Comma-separated policy set names (pss-baseline, pss-restricted, rbac-best-practices)
 --policy-view Use with --details to reverse the view from resource->policy to policy->resource
 --publish Publish reports
 --publish-token string scan reports publish token
 --remediate string Remediate resources ('show', 'patch')
 --report-sourceid string Add source id for report created for local scan (is required for local scans; is the cluster id for cluster scan)
 -r, --resources strings Path to resource files (local path, github URL)
 --token string the Nirmata API Login Key (env NIRMATA_TOKEN)
 --url string the Nirmata server base URL (env NIRMATA_URL)
 --values-file string File containing values for policy variables
```text

### Options inherited from parent commands

```text
 -v, --v Level number for the log level verbosity

nctl scan prompt

Mon, 01 Jan 0001 00:00:00 +0000

nctl scan prompt

[Experimental] scan LLM prompts

nctl scan prompt [flags]

Examples


 # Scan prompts in a config file
 nctl scan prompt -r path/to/prompts.yaml -p path/to/policy.yaml

 # Scan a directory of prompt files
 nctl scan prompt -r path/to/prompts/ -p policies/prompts-baseline.yaml

 # Scan a prompt string directly
 nctl scan prompt --string "You are a helpful assistant..." -p path/to/policy.yaml

 # Read prompt from stdin
 echo "You are a helpful assistant..." | nctl scan prompt --stdin -p path/to/policy.yaml

 # Scan with minimum confidence threshold for file extraction
 nctl scan prompt -r path/to/config/ -p path/to/policy.yaml --min-confidence 0.6

 # Scan with audit mode enabled (violations reported as warnings)
 nctl scan prompt -r path/to/prompts.yaml -p path/to/policy.yaml --audit-as-warn

 # Output results in JSON format
 nctl scan prompt -r path/to/prompts.yaml -p path/to/policy.yaml -o json

 # Filter policies by severity
 nctl scan prompt -r path/to/prompts.yaml -p path/to/policies/ --selector "severity=critical"

 # Enable AI-assisted classification (uses Nirmata by default)
 nctl scan prompt -r path/to/prompts.yaml -p path/to/policy.yaml --ai-check

 # AI classification with a specific provider
 nctl scan prompt -r path/to/prompts.yaml -p path/to/policy.yaml --ai-check --ai-provider gemini --ai-model gemini-2.5-pro

Options

 --ai-check Enable AI-assisted prompt classification (requires Nirmata authentication)
 --ai-model string AI model for --ai-check (defaults to provider's default model)
 --ai-provider string AI provider for --ai-check (nirmata, gemini, anthropic, bedrock, azopenai) (default "nirmata")
 --audit-as-warn Report violations from policies in audit mode as warnings instead of failures
 --details Show result details for violating resources (default true)
 --file string[="scan-report"] Output file (if --file is used without a value, defaults to 'scan-report')
 --git-token string Git authentication token (for Git URLs in --policies)
 --git-username string Git username (for Git URLs in --policies)
 -h, --help help for prompt
 --insecure allow connection to a Nirmata server with a insecure certificate (not recommended)
 --min-confidence float Minimum confidence threshold for file-based prompt extraction (0.0-1.0) (default 0.5)
 --no-color disable the colors for the stdout reports
 -o, --output string Output format (text, json, yaml, scan-report, sarif) (default "text")
 -p, --policies strings Path to policy files (optional; bundled defaults used when omitted)
 --publish Publish reports
 --publish-token string scan reports publish token
 --report-sourceid string Add source id for report created for local scan
 -r, --resources strings Path to resource files/directories (YAML, JSON, TOML, txt, md)
 --risk-threshold int Fail if aggregate risk score meets or exceeds this value (0 = disabled)
 --scan-report string Output scan report file (in JSON format)
 --selector stringArray Filter policies by annotation (key=value). Key is shorthand for policies.kyverno.io/{key}. Multiple selectors with the same key are OR'd; different keys are AND'd. Example: --selector severity=critical --selector severity=high
 --stdin Read prompt text from stdin
 --string string Provide prompt text directly as a string
 --token string the Nirmata API Login Key (env NIRMATA_TOKEN)
 --url string the Nirmata server base URL (env NIRMATA_URL)
```text

### Options inherited from parent commands

```text
 -v, --v Level number for the log level verbosity

nctl scan repository

Mon, 01 Jan 0001 00:00:00 +0000

nctl scan repository

scan files in a git repository

nctl scan repository [flags]

Examples


 # Scan the Nirmata demo-resources repository
 nctl scan repository https://github.com/nirmata/demo-resources

 # Scan the repository with a specific policy set
 nctl scan repository https://github.com/nirmata/demo-resources --policy-sets pss-baseline,pss-restricted

 # Scan the repository using specific policies from local and remote sources
 nctl scan repository https://github.com/nirmata/demo-resources 

 # Scan a repository and output results to console in JSON format
 nctl scan repository https://github.com/nirmata/demo-resources -o json

 # Specify output format and save results to a file with default name (scan-report.json)
 nctl scan repository https://github.com/nirmata/demo-resources -o json --file

 # Specify output format and save results to a file with user defined name
 nctl scan repository https://github.com/nirmata/demo-resources -o json --file=user-defined-name.json

 # Scan a specific branch of the repository
 nctl scan repository https://github.com/nirmata/demo-resources --branch main

 # Enable audit mode to report violations as warnings instead of failures
 nctl scan repository https://github.com/nirmata/demo-resources --audit-as-warn

 # Display remediation suggestions for policy violations
 nctl scan repository https://github.com/nirmata/demo-resources --remediate display

 # Overwrite resource files with remediations
 nctl scan repository https://github.com/nirmata/demo-resources --remediate overwrite

 # Exclude a specific directory (use the full path as it appears in the repository), 
 # Avoid using single directory name like 'policies' for potential name collision on multi directory level.
 nctl scan repository https://github.com/nirmata/demo-resources --exclude='nirmata/demo-resources/policies'

 # Exclude a specific file by its exact name
 nctl scan repository https://github.com/nirmata/demo-resources --exclude='disallow-secrets-from-env-vars.yaml'

 # Exclude all YAML files (case-insensitive) using a regex pattern
 nctl scan repository https://github.com/nirmata/demo-resources --exclude-regex='(?i)\.ya?ml$'

```bash

### Options

```text
 --analyze Analyze cluster using AI
 --analyzers strings Analyzers to enable (all,dockerfile,github-actions,json,kubernetes,terraform-plan,helm-charts,skills) (default [all])
 --audit-as-warn Report violations from policies in audit mode as warnings instead of failures
 --branch string name of the branch
 --details Show result details for violating resources (default true)
 --exclude strings List of filenames to exclude during the scan, separated by commas.
 --exclude-regex string Regex pattern for excluding files during the scan.
 --file string[="scan-report"] Output file (if --file is used without a value, defaults to 'scan-report')
 --git-token string Git authentication token (for Git repository URLs)
 --git-username string Git username (for Git repository URLs)
 -h, --help help for repository
 --include strings List of filenames to include during the scan, separated by commas.
 --include-regex string Regex pattern for including files during the scan. If not provided, all files are included.
 --insecure allow connection to a Nirmata server with a insecure certificate (not recommended)
 --labels strings Report label
 --no-color disable the colors for the stdout reports
 -o, --output string Output format (text, json, yaml, scan-report, sarif) (default "text")
 -p, --policies strings Path to policy files (local path, github URL, helm URL)
 --policy-sets strings policy set names (pss-baseline, pss-restricted, rbac-best-practices)
 --publish Publish reports (default true)
 --publish-token string scan reports publish token
 --remediate string Remediate resources ('show', 'patch')
 --token string the Nirmata API Login Key (env NIRMATA_TOKEN)
 --url string the Nirmata server base URL (env NIRMATA_URL)
```text

### Options inherited from parent commands

```text
 -v, --v Level number for the log level verbosity

nctl scan skills

Mon, 01 Jan 0001 00:00:00 +0000

nctl scan skills

[Experimental] scan agent skills

nctl scan skills [flags]

Examples


 # Basic scan with required resource and policy file
 nctl scan skills -r path/to/skill-dir -p path/to/policy.yaml

 # Scan multiple skills
 nctl scan skills -r skills/skillA -r skills/skillB -p policies/skill-baseline.yaml

 # Scan with audit mode enabled (violations reported as warnings)
 nctl scan skills -r path/to/skill-dir -p path/to/policy.yaml --audit-as-warn

 # Scan with detailed results for violating resources
 nctl scan skills -r path/to/skill-dir -p path/to/policy.yaml --details

 # Generate a scan report in JSON format
 nctl scan skills -r path/to/skill-dir -p path/to/policy.yaml -o json --scan-report scan-report.json

 # Output results to console in JSON
 nctl scan skills -r path/to/skill-dir -p path/to/policy.yaml -o json

 # Save results to a file with default name (scan-report.json)
 nctl scan skills -r path/to/skill-dir -p path/to/policy.yaml -o json --file

 # Disable colored output
 nctl scan skills -r path/to/skill-dir -p path/to/policy.yaml --no-color

 # Scan with only critical-severity policies
 nctl scan skills -r path/to/skill-dir -p path/to/policies/ --selector "severity=critical"

 # Scan with critical and high severity policies
 nctl scan skills -r path/to/skill-dir -p path/to/policies/ --selector "severity=critical" --selector "severity=high"

Options

 --audit-as-warn Report violations from policies in audit mode as warnings instead of failures
 --details Show result details for violating resources (default true)
 --exclude-files stringArray Glob patterns to exclude from indicator content scanning (e.g. 'docs/*', 'CHANGELOG.md')
 --file string[="scan-report"] Output file (if --file is used without a value, defaults to 'scan-report')
 --git-token string Git authentication token (for Git URLs in --policies)
 --git-username string Git username (for Git URLs in --policies)
 -h, --help help for skills
 --insecure allow connection to a Nirmata server with a insecure certificate (not recommended)
 --no-color disable the colors for the stdout reports
 -o, --output string Output format (text, json, yaml, scan-report, sarif) (default "text")
 -p, --policies strings Path to policy files (optional; bundled defaults used when omitted)
 --publish Publish reports
 --publish-token string scan reports publish token
 --remediate string Remediate resources ('show', 'patch')
 --report-sourceid string Add source id for report created for local scan
 -r, --resources strings Path to resource files (local path, github URL)
 --risk-threshold int Fail if aggregate risk score meets or exceeds this value (0 = disabled)
 --scan-report string Output scan report file (in JSON format)
 --selector stringArray Filter policies by annotation (key=value). Key is shorthand for policies.kyverno.io/{key}. Multiple selectors with the same key are OR'd; different keys are AND'd. Example: --selector severity=critical --selector severity=high
 --token string the Nirmata API Login Key (env NIRMATA_TOKEN)
 --url string the Nirmata server base URL (env NIRMATA_URL)
```text

### Options inherited from parent commands

```text
 -v, --v Level number for the log level verbosity

nctl scan terraform

Mon, 01 Jan 0001 00:00:00 +0000

nctl scan terraform

scan terraform resources

nctl scan terraform [flags]

Examples


 # Basic scan with required resource and policy file
 nctl scan terraform -r path/to/file -p path/to/policy

 # Scan with audit mode enabled (violations reported as warnings)
 nctl scan terraform -r path/to/file -p path/to/policy --audit-as-warn

 # Scan with remediation suggestions displayed
 nctl scan terraform -r path/to/file -p path/to/policy --remediate display

 # Overwrite resource files with remediations
 nctl scan terraform -r path/to/file -p path/to/policy --remediate overwrite

 # Generate a scan report in JSON format
 nctl scan terraform -r path/to/file -p path/to/policy -o json --scan-report scan-report.json

 # Save scan results to a file
 nctl scan terraform -r path/to/file -p path/to/policy --file output.txt

 # Disable colored output in the terminal
 nctl scan terraform -r path/to/file -p path/to/policy --no-color

 # Scan a Terraform file and output results to console in JSON format
 nctl scan terraform -r /path/to/terraform-file.tf -p /path/to/policy -o json

 # Specify output format and save results to a file with default name (scan-report.json)
 nctl scan terraform -r /path/to/terraform-file.tf -p /path/to/policy -o json --file

 # Specify output format and save results to a file with user defined name
 nctl scan terraform -r /path/to/terraform-file.tf -p /path/to/policy -o json --file=user-defined-name.json

```bash

### Options

```text
 --audit-as-warn Report violations from policies in audit mode as warnings instead of failures
 --details Show result details for violating resources (default true)
 --file string[="scan-report"] Output file (if --file is used without a value, defaults to 'scan-report')
 --git-token string Git authentication token (for Git URLs in --policies)
 --git-username string Git username (for Git URLs in --policies)
 -h, --help help for terraform
 --insecure allow connection to a Nirmata server with a insecure certificate (not recommended)
 --no-color disable the colors for the stdout reports
 -o, --output string Output format (text, json, yaml, scan-report, sarif) (default "text")
 -p, --policies strings Path to policy files (local path, github URL, helm URL)
 --publish Publish reports
 --publish-token string scan reports publish token
 --remediate string Remediate resources ('show', 'patch')
 --report-sourceid string Add source id for report created for local scan
 -r, --resources strings Path to resource files (local path, github URL)
 --scan-report string Output scan report file (in JSON format)
 --token string the Nirmata API Login Key (env NIRMATA_TOKEN)
 --url string the Nirmata server base URL (env NIRMATA_URL)
```text

### Options inherited from parent commands

```text
 -v, --v Level number for the log level verbosity

nctl signup

Mon, 01 Jan 0001 00:00:00 +0000

Create a new Nirmata Control Hub account

Synopsis

Create a new account on Nirmata Control Hub using your email address.

nctl signup [flags]

Options

 --email string Email address for signup (format: name@company.com)
 -h, --help help for signup
 --nirmataUrl string Nirmata Url (default: https://nirmata.io) (default "https://nirmata.io/")
 --password string Password for signup
```text

### Options inherited from parent commands

```text
 -v, --v Level number for the log level verbosity

nctl transform

Mon, 01 Jan 0001 00:00:00 +0000

nctl transform

Transform resource manifests to json

Synopsis

Transform resource manifests (Dockerfile, Terraform plan, Terraform config, Terraform state, Kubernetes) to json. This helps write kyverno json policies for these resources

nctl transform [flags]

Options

 -h, --help help for transform
 -o, --output-file string Output file
 -r, --resource strings Path to resource file
```text

### Options inherited from parent commands

```text
 -v, --v Level number for the log level verbosity

nctl update

Mon, 01 Jan 0001 00:00:00 +0000

nctl update

Update Nirmata Control Hub resources

Options

 -h, --help help for update
```text

### Options inherited from parent commands

```text
 -v, --v Level number for the log level verbosity

nctl update cluster

Mon, 01 Jan 0001 00:00:00 +0000

nctl update cluster

Update cluster

nctl update cluster [flags]

Examples


 # Update a cluster using its name
 nctl update cluster --cluster-name my-cluster

 # Update a cluster using its unique cluster ID (Overrides name if provided)
 nctl update cluster --cluster-id my-cluster-id

 # Update a cluster using a values file with onboarding parameters
 nctl update cluster -f /path/to/values.yaml

 # Specify a private Helm repository and token for updating the operator
 nctl update cluster --helm-repo https://private.repo.com/helm-charts -t my-private-repo-token

 # Update a cluster while allowing connections to an address with a self-signed or unverified certificate (not recommended)
 nctl update cluster --cluster-name my-cluster --insecure

 # Update a cluster with a specific Kyverno version
 nctl update cluster --cluster-name my-cluster --kyverno-version 1.12

 # Specify a custom release name for the Kyverno operator Helm chart
 nctl update cluster --cluster-name my-cluster --release my-kyverno-release

 # Specify a custom namespace for the operator deployment
 nctl update cluster --cluster-name my-cluster --namespace custom-namespace

 # Update a cluster using a specific kubeconfig file and context
 nctl update cluster --cluster-name my-cluster --kubeconfig /path/to/kubeconfig --kube-context my-context

```bash

### Options

```text
 -i, --cluster-id string the Nirmata Control Hub cluster Id of cluster to be updated (Needed if cluster name is not unique)
 --cluster-name string the name of cluster to be updated. Needed only if Id is not provided
 -t, --git-token string token for the operator helm chart in private helm repo
 --helm-repo string operator helm repository name (default "https://nirmata.github.io/kyverno-charts")
 -h, --help help for cluster
 --insecure allow connection to a Nirmata server with a insecure certificate (not recommended)
 --kube-context string the kube context from configured kubeconfig. Default is the current or sole context
 --kubeconfig string kubeconfig path (defaults to $HOME/.kube/kubeconfig)
 --kyverno-version string Kyverno version 1.11 (default "1.11")
 -n, --namespace string operator namespace (default "nirmata-system")
 --registry-name string name of the private registry (no need if images are not pushed to private registry)
 --registry-password string password of the private registry (no need if images are not pushed to private registry)
 --registry-username string user name of the private registry (no need if images are not pushed to private registry)
 -r, --release string operator helm chart release name (default "kyverno-operator")
 --token string the Nirmata API Login Key (env NIRMATA_TOKEN)
 --url string the Nirmata server base URL (env NIRMATA_URL)
 -f, --values-file string the cluster onboarding parameter YAML file
```text

### Options inherited from parent commands

```text
 -v, --v Level number for the log level verbosity

nctl version

Mon, 01 Jan 0001 00:00:00 +0000

nctl version

Show version and build information

nctl version [flags]

Options

 -h, --help help for version
```text

### Options inherited from parent commands

```text
 -v, --v Level number for the log level verbosity

Users and Roles

Mon, 01 Jan 0001 00:00:00 +0000

An account can have multiple users, and each user has a role that defines what they can see and do. When a new account is created, the first user has an admin role which allows that user to create and manage additional users for the account.

User roles and description

The following user roles are available:

Role	Description
admin	admin users have full access to the account and can manage other users and their access.
platform	platform users can access all resources including Compliance, Inventory Report, and Policies, but cannot manage users.
security	security users can view the Policy Report and manage Policy Exceptions. They have the privilege to review Policy Exception requests and have access to Compliance, Clusters, and Repositories, but cannot manage users.
devops	devops users have the least privileged access. A devops user can view the Policy Report and create Policy Exceptions. They do not have access to Compliance, Inventory Report, and cannot manage users.

Configuring user roles and permissions

Identity & Access Management (IAM) lets you add users, set user privileges, group users in teams, and configure access methods such as Security Assertion Markup Language (SAML), OpenID Connect (OIDC), and Multi-Factor Authentication (MFA).

Teams

Mon, 01 Jan 0001 00:00:00 +0000

In Nirmata, users can be organized into teams. A team is a logical entity that allows you to manage permissions for a group of users who require shared access to organizational resources. Each team can include multiple users, each with specific roles and permissions.

Adding a Team

To create a new team:

Navigate to Identity & Access > Teams.
Click the Add Team button. The Add a New Team page will appear.
In the Name field, enter the team’s name.
In the Description field, provide a brief description of the team.
To add users:
- In the Users section, click the Add Users button.
- In the search field, enter the user’s name and select the checkbox next to it.
To assign namespace access:
- Click the Add Access Control button.
- In the search field, enter the desired namespaces and select the corresponding checkboxes.
Click Create to finalize the team.

Editing or Deleting a Team

To edit a team:

Service Account Authentication

Mon, 01 Jan 0001 00:00:00 +0000

Nirmata Control Hub Service Account tokens allow nctl to authenticate with Nirmata Control Hub without requiring a user login. This is the recommended approach for CI/CD pipelines, GitOps workflows, and any automated scanning or publishing process where storing user credentials is not practical.

Overview

By default, nctl authenticates using a user API key (set via nctl login, the NIRMATA_TOKEN environment variable, or ~/.nirmata/config). Service Account tokens provide an alternative authentication path scoped to specific operations, making them well-suited for automation.

GitHub App Permissions

Mon, 01 Jan 0001 00:00:00 +0000

Applies to: Nirmata Control Hub 4.0 and later

Repository Permissions

Permission	Access Level	Purpose
Metadata	Read	Required by GitHub (mandatory for all apps)
Contents	Read & Write	Create and modify files, branches, and commits
Pull Requests	Read & Write	Create, update, and merge pull requests
Issues	Read & Write	Create and manage issues for tracking

What Nirmata Can Do

With these permissions, Nirmata can:

Read repository contents and metadata
Create branches for policy fixes
Commit changes to branches
Open pull requests with automated fixes
Add comments to pull requests
Create issues for violations or notifications
Read and respond to PR comments

What Nirmata Cannot Do

The app cannot:

Scanning Resources

Mon, 01 Jan 0001 00:00:00 +0000

nctl scan is the primary command group for scanning resources for policy violations and security misconfigurations. It supports a wide range of resource types — from live Kubernetes clusters and Git repositories to Terraform plans, Dockerfiles, and Helm charts — making it easy to shift-left security across your entire stack.

Subcommands

Command	Description
`nctl scan kubernetes`	Scan Kubernetes resources from a live cluster or local manifests against Kyverno policies
`nctl scan repository`	Scan all supported resource types in a Git repository or local directory in a single command
`nctl scan terraform`	Scan Terraform plan files for policy violations
`nctl scan dockerfile`	Scan Dockerfiles for security and best-practice violations
`nctl scan helm`	Scan Helm charts for policy violations
`nctl scan json`	Scan arbitrary JSON-formatted resources
`nctl scan github-actions`	Scan GitHub Actions workflow files for security vulnerabilities
`nctl scan compliance`	Run a compliance scan against a Kubernetes cluster for a named standard (SOC2, NIST 800-53, PCI-DSS, etc.)
`nctl scan prompt`	[Experimental] Scan LLM prompts for policy violations
`nctl scan skills`	[Experimental] Scan agent skills

Output Formats

Most scan commands support multiple output formats via the -o / --output flag:

Usage

Mon, 01 Jan 0001 00:00:00 +0000

Overview

Kyverno MCP serves two primary use cases that address different stages of the Kubernetes policy management lifecycle. Whether you’re proactively assessing cluster security or monitoring existing policy deployments, these scenarios demonstrate how to leverage Kyverno MCP effectively.

Scenario 1: Proactive Assessment

In this scenario, Kyverno is not installed on your clusters. You can use the Kyverno MCP server to scan cluster resources with recommended or custom policy sets.

The Challenge

“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.”

Cluster Onboarding

Sat, 10 Oct 2020 11:02:05 +0600

nctl provides an easy way to add new clusters to Nirmata Control Hub, and also to interact with existing clusters.

Note: You must be logged in to your Nirmata Control Hub account before performing any of the below actions. View the steps to login here.

Add a new cluster to Nirmata Control Hub

To onboard an existing cluster to the Nirmata Control Hub, use the add command.

nctl add cluster --cluster-name <cluster-name>
```text

This will install the Kyverno Operator, and also deploy the following PolicySets:
* Pod Security Standards (Baseline)
* Pod Security Standards (Restricted)
* RBAC Best Practices

If you wish to only onboard the cluster without deploying the Kyverno Operator and related components, use the `--register-only` flag.


## List all clusters
To get a list of all clusters that are onboarded to Nirmata Control Hub, use the `get` command.

```bash
nctl get cluster
```text

## Get cluster details
To view more details about a cluster:

```bash
nctl get cluster <cluster-name>
```text

## Remove cluster from Nirmata Control Hub
To remove a cluster from Nirmata Control Hub:

```bash
nctl remove cluster --cluster-name <cluster-name>

This deregisters the cluster from Nirmata Control Hub and removes the Kyverno Operator, related components, and policysets that were installed during cluster registration.

Amazon EKS

Mon, 01 Jan 0001 00:00:00 +0000

Amazon Elastic Kubernetes Service (Amazon EKS) is a popular managed Kubernetes service for deploying and managing containerized applications. Amazon EKS users are challenged with ensuring security and governance across their entire fleet of clusters. Kyverno, an open-source policy engine, enables policy-based security, governance, and compliance for Amazon EKS clusters. Using Kyverno, enterprise platform teams can deploy the necessary guardrails to ensure that deployed applications are secure, compliant, and follow Amazon EKS Best Practices.

Available Tools

Mon, 01 Jan 0001 00:00:00 +0000

The following tools are available to nctl ai. The agent selects the appropriate tool based on your request.

Tools by category

Category	Tool	Description
Command execution	`bash`	Execute a bash command. Use when you need to run a shell command.
Command execution	`kubectl`	Command-line tool for interacting with Kubernetes clusters.
Policy	`generate_policy`	Generate a Kyverno policy.
Policy	`generate_kyverno_tests`	Generate Kyverno CLI tests for a policy. Returns filenames and contents for `kyverno-test.yaml`, `resources.yaml`, and optionally `variables.yaml`.
Policy	`generate_chainsaw_tests`	Generate or update Chainsaw tests for Kyverno policies.
Policy	`run_kyverno_tests`	Test Kyverno policies using the Kyverno CLI test command.
Security	`remediate`	Fix policy violations for a resource.
Security	`scan_kubernetes_resources`	Scan Kubernetes resource files against policies and return results.
Security	`scan_kubernetes_cluster`	Scan Kubernetes resources in a cluster against policies and return results.
Security	`scan_terraform`	Scan Terraform resources against policies and return results.
Security	`scan_prompt`	Scan LLM prompts against security policies for injection attacks, jailbreak patterns, PII leakage, credential exposure, and other risks. Accepts inline content, file paths, or directories. Returns policy evaluation results with a risk score.
Security	`skills_scan`	Scan a skill (folder or artifact) against policies and return a signed/hashed receipt with decision and findings. Normalizes the skill directory, applies Kyverno ValidatingPolicies, computes a trust score and decision (Allow/Review/Deny), and produces a receipt for later verification.
Communication	`email`	Send an email via Nirmata Control Hub.
Communication	`list_slack_channels`	List all Slack channels the user has access to.
Communication	`send_slack_message`	Send a message to a Slack channel via Nirmata Control Hub.
File system	`read_file`	Read the complete contents of a file.
File system	`read_multiple_files`	Read the contents of multiple files in a single operation.
File system	`write_file`	Create a new file or overwrite an existing file with new content.
File system	`modify_file`	Update a file by finding and replacing text. Pattern matching without needing exact character positions.
File system	`copy_file`	Copy files and directories.
File system	`move_file`	Move or rename files and directories.
File system	`delete_file`	Delete a file or directory from the file system.
File system	`create_directory`	Create a new directory or ensure a directory exists.
File system	`list_directory`	Get a detailed listing of all files and directories in a specified path.
File system	`tree`	Return a hierarchical JSON representation of a directory structure.
File system	`get_file_info`	Retrieve detailed metadata about a file or directory.
File system	`search_files`	Recursively search for files and directories matching a pattern.
File system	`search_within_files`	Search for text within file contents. Scans text files for matching substrings; binary files are excluded. Reports file paths and line numbers.
File system	`list_allowed_directories`	Return the list of directories the server is allowed to access.
File system	`add_allowed_directory`	Add a directory to the allowed list for filesystem operations. Use when you get errors about directories being outside allowed directories.
Utility	`todo`	Manage a todo list (add, remove, update, list items). Automatically prevents duplicate items.
Utility	`worker`	Manage background workers for concurrent task processing.

Slack integration

Slack tools (list_slack_channels, send_slack_message) require Slack integration configured in Nirmata Control Hub. No additional environment variables are needed once configured in Nirmata Control Hub.

Cluster Deployment Options

Mon, 01 Jan 0001 00:00:00 +0000

Applies to: Nirmata Control Hub 4.0 and later

Choose whether to allow Nirmata to deploy custom resources directly to your cluster or manage them using your own GitOps and Continuous Delivery tools.

Read-Only

Nirmata will not deploy Policies or Policy Exceptions to your cluster. You retain complete control and deploy these resources yourself using your own tools (Argo CD, Flux, kubectl, etc.).

Nirmata still provides full visibility: compliance reports, violation dashboards, and monitoring all function normally.

Installation

Mon, 01 Jan 0001 00:00:00 +0000

Installation Methods

Kyverno MCP can be installed using several methods depending on your operating system and preferences.

Prerequisites

Go 1.24 or higher (only for building from source)
Access to a Kubernetes cluster with a valid kubeconfig
Kyverno installed in your cluster (for policy operations)

Option 1: Homebrew (Recommended for macOS/Linux)

The easiest way to install Kyverno MCP on macOS or Linux:

# Add the Nirmata tap
brew tap nirmata/tap

# Install Kyverno MCP
brew install kyverno-mcp

# Verify installation
kyverno-mcp --version

Option 2: Pre-built Binaries

Download pre-built binaries for your platform:

Profile

Mon, 01 Jan 0001 00:00:00 +0000

In the Settings > Profile view, users can Copy API Key, Generate a new API Key, and Change Password. Under My Settings, the user’s details are displayed with information related to Name, Email, Identity Provider, Role, and Last Login.

Admin users can edit their profile information by clicking on the edit button. They can change their role, name, email address, and identity provider and turn on multi-factor authentication.

Available Skills

Mon, 01 Jan 0001 00:00:00 +0000

nctl ai loads specialized skills dynamically based on your task. The following built-in skills are available.

Skills by category

Category	Skill	Description
Design	brand-guidelines	Applies Nirmata’s official brand colors and typography to generated content. Use when creating emails, reports, presentations, Slack/Teams messages, or any artifact requiring Nirmata branding or company design standards.
Policy	chainsaw-tests	Generate and run Chainsaw E2E integration tests. Use when the user asks for chainsaw tests, e2e tests, or integration tests, or wants to test policies in a real Kubernetes cluster. Creates test manifests and validates admission webhook behavior for ValidatingPolicy, MutatingPolicy, and ClusterPolicy.
Setup	cluster-setup	Set up a local Kubernetes development environment with Docker, Kind, Kyverno, and testing tools. For developers who can install tools locally.
Policy	converting-chainsaw-tests	Convert Chainsaw tests from ClusterPolicy (kyverno.io/v1) to ValidatingPolicy (policies.kyverno.io/v1alpha1) format. Use when converting existing test suites to work with new Kyverno ValidatingPolicy resources.
Policy	converting-policies	Convert any policy to modern Kyverno ValidatingPolicy format. Use when the user asks to convert, migrate, upgrade, or transform a policy. Handles ClusterPolicy to ValidatingPolicy, OPA Rego migration, Gatekeeper constraint templates, Sentinel policies, and cross-engine policy translation.
Cost	cost-management	Installs, configures, and validates the Nirmata Cost Management Add-on. Deploys OpenCost for cost visibility, Prometheus integration, Grafana dashboards for chargeback, and Kyverno cost guardrails for namespace labeling and resource requests. Supports kind, EKS, GKE, and AKS with real cloud pricing. Use when setting up cost visibility, cost allocation, cost hygiene labels, or troubleshooting OpenCost.
Setup	installing-remediator-agent	Installs and configures the Remediator Agent for policy violation remediation. Guides through environment selection (ArgoCD Hub, Local Cluster, VCS Target), LLM provider setup (NirmataAI, AWS Bedrock, Azure OpenAI), GitHub auth (App or PAT), action config (CreatePR, CreateIssue), scheduling, and verification. Use when setting up automated AI-powered policy remediation.
Compliance	cis-benchmark-scan	Scans Kubernetes clusters against CIS Benchmarks using nctl scan compliance and generates a full markdown compliance report. No policies are deployed to the cluster — nctl evaluates them locally with results stored as snapshots. Supports EKS (CIS EKS Benchmark v1.7.0), AKS, GKE, and generic Kubernetes (CIS Kubernetes Benchmark v1.8.0). Covers RBAC and Pod Security controls, plus AWS API checks for Control Plane (Section 2) and cluster networking (Section 5.3–5.5) on EKS. Use when performing CIS compliance audits, generating compliance reports for security teams, or assessing cluster security posture against industry benchmarks.
Compliance	compliance-evidence	Collects and packages Kubernetes-native compliance evidence for external auditors. Exports RBAC configurations, NetworkPolicies, admission webhooks, Kyverno PolicyReports and PolicyExceptions, and generates a timestamped MANIFEST.md with control-ID mapping and a manual evidence checklist. Supports NSA/CISA, NIST SP 800-53, SOC 2 Type II, ISO/IEC 27001, and PCI-DSS. Use when preparing evidence packages for SOC 2, ISO 27001, NIST, or PCI-DSS auditors, or to document accepted risks via PolicyExceptions.
Compliance	compliance-scan	Scans Kubernetes clusters against regulatory compliance standards using nctl scan compliance and generates a full markdown report with control-ID mapping. Supports NSA/CISA Kubernetes Hardening Guide, NIST SP 800-53, SOC 2 Type II, ISO/IEC 27001, and PCI-DSS. No policies are deployed — nctl evaluates them locally and stores results as snapshots. Use when performing regulatory audits, generating SOC 2 or ISO 27001 evidence, or assessing Kubernetes security posture against NIST or NSA/CISA frameworks.
Compliance	kyverno-compliance-management	Install Kyverno or Nirmata Enterprise Kyverno with optional compliance dashboards. Detects if Kyverno is missing and guides installation. Supports Pod Security Standards (PSS Baseline, PSS Restricted), RBAC Best Practices, and Grafana compliance visualization. Use when installing Kyverno/Nirmata Enterprise for Kyverno, setting up Kubernetes compliance, or configuring PSS or RBAC policies.
Policy	kyverno-policies	Generate and create Kyverno policies from natural language requirements. Use when the user asks to generate, create, or write a policy, or needs help with policy development. Covers ValidatingPolicy, MutatingPolicy, GeneratingPolicy, ClusterPolicy, and other Kyverno policy types.
Policy	kyverno-tests	Generate and run Kyverno CLI unit tests for fast offline policy validation. Use when the user asks for unit tests, kyverno test, cli tests, or wants to test policies without a cluster. Creates kyverno-test.yaml files and runs the kyverno test command.
Onboarding	quickstart	First-run cluster assessment: checks cluster maturity, identifies issues, runs security scans, and recommends policy packs. Alias: assessment. Use on first launch, or when assessing a new cluster, running a health check, getting security recommendations, checking policy coverage, or identifying quick wins for Kubernetes governance.
Policy	recommend-policies	Analyzes Kubernetes clusters to recommend Kyverno policies based on installed workloads and platform type. Detects baseline security gaps (pod-security, RBAC, workload-security), platform-specific needs (EKS, OpenShift), and add-on policies (Istio, Linkerd, Flux, Tekton, Veeam Kasten, KubeVirt, Karpenter, ArgoCD, Crossplane). Use when assessing cluster security posture, implementing policy governance, or ensuring compliance.
Policy	policy-exception	generate PolicyExceptions for running workloads so that Enforce or Deny mode does not block existing workloads; migrate policies from Audit to Enforce by creating exceptions for current violations
Troubleshooting & Operations	troubleshooting-kyverno	Diagnoses Kyverno issues: webhook timeouts, OOMKilled pods, CrashLoopBackOff, policy failures, permission errors, performance degradation, report accumulation. Use when policies not enforcing, admission controller crashing, context deadline exceeded, client-side throttling, or cloud-specific failures on EKS/GKE/AKS.
Troubleshooting & Operations	troubleshooting-workloads	Troubleshoot Kubernetes workloads, pods, and applications in any namespace. Diagnoses CrashLoopBackOff, ImagePullBackOff, Pending pods, OOMKilled, failed probes, resource constraints. Use when debugging pods, investigating application failures, pods not starting, containers crashing, high restart counts, or services unreachable. Recommends Kyverno policies to prevent recurrence.

Adding custom skills

You can extend the agent with your own skills. See Adding Custom Skills for loading custom skill directories and creating SKILL.md files.

Kyverno Operator Management

Sat, 10 Oct 2020 11:02:05 +0600

The Enterprise Kyverno Operator is a Kubernetes Operator to manage lifecycle of Kyverno, Adapters and Nirmata supported policies. It offers comprehensive lifecycle management capabilities that go beyond just Kyverno itself, extending to related components like policies and adapters. Managing these components at scale can be challenging due to compatibility and upgrade issues. The Operator provides a seamless solution for your policy and governance ecosystem, ensuring stability and smooth operation. The Operator itself can be used with nctl and is also available as a Helm chart.

Amazon EKS-A

Mon, 01 Jan 0001 00:00:00 +0000

Amazon EKS Anywhere lets you create and operate Kubernetes clusters on your own infrastructure. Amazon EKS Anywhere builds on the strengths of Amazon EKS Distro and provides open-source software that’s up to date and patched so you can have an on-premises Kubernetes environment that’s more reliable than a self-managed Kubernetes offering. Kyverno, an open-source policy engine, enables policy-based security, governance, and compliance for Amazon EKS-A clusters. Using Kyverno, enterprise platform teams can deploy the necessary guardrails to ensure that deployed applications are secure, compliant, and follow Amazon EKS Best Practices.

Available Tools

Mon, 01 Jan 0001 00:00:00 +0000

Overview

Kyverno MCP provides several tools that AI assistants can use to interact with Kyverno and Kubernetes. Each tool is designed for specific operations and returns structured data.

Context Management Tools

list_contexts

Lists all available Kubernetes contexts from your kubeconfig.

Purpose: Discover available Kubernetes clusters/contexts

Example Request:

List all my available Kubernetes contexts
```text

**Example Response**:
```json
{
 "contexts": [
 {
 "name": "production-cluster",
 "cluster": "prod-k8s",
 "user": "admin@prod"
 },
 {
 "name": "staging-cluster",
 "cluster": "staging-k8s",
 "user": "admin@staging"
 }
 ],
 "current": "production-cluster"
}
```json

### switch_context

Switches to a different Kubernetes context.

**Purpose**: Change the active Kubernetes cluster

**Parameters**:
- `context`: The name of the context to switch to

**Example Request**:
```text
Switch to the staging-cluster context
```text

**Example Response**:
```json
{
 "message": "Switched to context: staging-cluster",
 "previous": "production-cluster",
 "current": "staging-cluster"
}
```json

## Policy Management Tools

### apply_policies

Applies Kyverno policies from various sources.

**Purpose**: Deploy policies to enforce security and compliance

**Parameters**:
- `source`: The source of policies
 - Curated sets: `pod-security`, `rbac-best-practices`, `kubernetes-best-practices`, `all`
 - Git repository: `https://github.com/org/repo`
 - Local path: `/path/to/policies`
- `namespace`: (Optional) Target namespace for policies

**Example Requests**:

1. Apply curated pod security policies:
```text
Apply pod security policies to my cluster
```text

2. Apply policies from a Git repository:
```text
Apply policies from https://github.com/myorg/kyverno-policies
```text

3. Apply all curated policies:
```text
Apply all best practice policies to the cluster
```text

**Example Response**:
```json
{
 "message": "Successfully applied 15 policies",
 "policies": [
 "disallow-privileged-containers",
 "require-run-as-non-root",
 "restrict-volume-types"
 ],
 "source": "pod-security"
}
```json

## Monitoring Tools

### show_violations

Displays policy violations from PolicyReport and ClusterPolicyReport resources.

**Purpose**: Monitor compliance and identify issues

**Parameters**:
- `namespace`: (Optional) Filter violations by namespace
- `severity`: (Optional) Filter by severity level

**Example Requests**:

1. Show all violations:
```text
Show me all policy violations in the cluster
```text

2. Show violations in a specific namespace:
```text
Show policy violations in the production namespace
```text

**Example Response**:
```json
{
 "violations": [
 {
 "policy": "disallow-privileged-containers",
 "resource": "pod/webapp-xyz",
 "namespace": "production",
 "severity": "high",
 "message": "Privileged containers are not allowed",
 "timestamp": "2024-01-15T10:30:00Z"
 },
 {
 "policy": "require-resource-limits",
 "resource": "deployment/backend",
 "namespace": "staging",
 "severity": "medium",
 "message": "Container 'api' does not have resource limits set"
 }
 ],
 "summary": {
 "total": 2,
 "high": 1,
 "medium": 1,
 "low": 0
 }
}
```json

**What this tool provides**:
- Current violation snapshots from PolicyReport CRs
- Individual violation details (policy, resource, namespace, severity, message)
- Basic timestamps for when violations occurred
- Summary counts by severity level

**What this tool does NOT provide**:
- Historical violation data or trends over time
- Policy set categorization (e.g., which violations belong to "kubernetes-best-practices")
- Aggregation capabilities (e.g., violation counts by namespace)
- PolicyReport metadata (creation times, report metadata)
- Trend analysis or time-based patterns

**Note**: If Kyverno is not installed, this tool will provide installation instructions.

## Documentation Tool

### help

Provides built-in documentation and guidance.

**Purpose**: Access Kyverno documentation and troubleshooting help

**Parameters**:
- `topic`: The help topic
 - `installation`: Kyverno installation guide
 - `troubleshooting`: Common issues and solutions

**Example Requests**:

1. Get installation help:
```text
Show me how to install Kyverno
```text

2. Get troubleshooting help:
```text
Help me troubleshoot Kyverno issues
```bash

**Example Response**:
```json
{
 "topic": "installation",
 "content": "To install Kyverno using Helm:\n\n1. Add the Kyverno Helm repository:\n helm repo add kyverno https://kyverno.github.io/kyverno/\n\n2. Install Kyverno:\n helm install kyverno kyverno/kyverno -n kyverno --create-namespace\n\n..."
}
```json

## Tool Usage Best Practices

### 1. Context Awareness
Always verify the current context before performing operations:

What Kubernetes context am I currently using?

Security

Mon, 01 Jan 0001 00:00:00 +0000

Applies to: nctl 4.0 and later

nctl ai is built with a security-first approach. The agent operates within strict boundaries and always asks for permission before performing operations.

Allowed Directories

By default, nctl ai can only access the current working directory. To grant access to additional directories, use the --allowed-dirs flag:

nctl ai --allowed-dirs "/path/to/policies,/tmp"

You can also set the NIRMATA_AI_ALLOWED_DIRS environment variable:

export NIRMATA_AI_ALLOWED_DIRS="/path/to/policies,/tmp"
nctl ai

The agent will refuse to read, write, or execute files outside of the allowed directories, ensuring your filesystem remains protected.

Configuration

Mon, 01 Jan 0001 00:00:00 +0000

Configuration Overview

Kyverno MCP can be configured through command-line flags and MCP client configuration files. This guide covers all configuration options and best practices.

Command Line Options

Basic Options

Flag	Description	Default	Example
`--kubeconfig`	Path to kubeconfig file	`$KUBECONFIG` or `~/.kube/config`	`--kubeconfig=/path/to/config`
`--help`	Show help message	-	`--help`
`--version`	Show version information	-	`--version`

Network Options

Flag	Description	Default	Example
`--http-addr`	HTTP(S) server bind address	None (stdio mode)	`--http-addr=:8443`
`--tls-cert`	TLS certificate file path	None	`--tls-cert=/path/to/cert.pem`
`--tls-key`	TLS private key file path	None	`--tls-key=/path/to/key.pem`

MCP Client Configuration

Claude Desktop

Location:

Session & Task Management

Mon, 01 Jan 0001 00:00:00 +0000

Applies to: nctl 4.0 and later

Session Management

Sessions automatically capture your conversation history, tool calls, and results. You can resume any previous session to continue where you left off.

Interactive commands:

Command	Description
`sessions`	List all available sessions
`save`	Save current session
`new`	Create a new session
`resume <id>`	Resume a specific session (or `latest`)
`exit` / `quit` / `q`	Save session and exit
`exit-nosave`	Exit without saving

CLI flags:

AI Provider Configuration

Mon, 01 Jan 0001 00:00:00 +0000

Applies to: nctl 4.0 and later

By default, nctl ai uses Nirmata Control Hub as its AI provider. You can configure it to work with other AI providers using the --provider flag.

Nirmata (Default)

The default provider uses Nirmata Control Hub for AI services. Authentication uses nctl login — no additional setup needed.

nctl ai --prompt "generate a policy to require pod labels"

Anthropic Claude

Set the environment variable with your Anthropic API key:

Troubleshooting

Mon, 01 Jan 0001 00:00:00 +0000

Common Issues

This guide covers common issues you might encounter when using Kyverno MCP and their solutions.

Installation Issues

Command Not Found

Problem: After installation, kyverno-mcp command is not found.

Solution:

Check if the binary is in your PATH:
```
echo $PATH
```
If using Homebrew, ensure it’s properly linked:
```
brew link kyverno-mcp
```

For manual installation, add to PATH:

export PATH=$PATH:/path/to/kyverno-mcp
echo 'export PATH=$PATH:/path/to/kyverno-mcp' >> ~/.bashrc

Permission Denied

Problem: Getting “permission denied” when trying to run kyverno-mcp.

Activity

Mon, 01 Jan 0001 00:00:00 +0000

Activity/Audit enables security administrators to view operations performed or initiated in Nirmata Control Hub. It also helps track operations performed on Kyverno resources such as Policies and Cluster Policies inside managed clusters.

To view the activity log details:

Go to Menu>Monitor>Activity. The Activity page displays logs for all users.

If you want to see the Activity for a particular user, then in the User Name filter field, enter the user name for whom you want to view the Activity.

Events

Mon, 01 Jan 0001 00:00:00 +0000

When resources are blocked due to enforced validation failure actions in Kubernetes clusters, Kyverno policies generate events for them. As an admin, you can view these events for all blocked resources with details such as cluster, namespace, policy name, rule, last seen time, and more. These events enable admins to take necessary actions to unblock resources in clusters.

NOTE:
a) Events are generated only for clusters running Kyverno release version 1.7.0 and later.
b) Events for blocked resources are stored for 7 days.

Extending Nirmata Assistant

Mon, 01 Jan 0001 00:00:00 +0000

Applies to: nctl 4.0 and later

Extending with MCP Servers

The Model Context Protocol (MCP) allows you to extend nctl ai with additional capabilities by connecting external MCP servers. These servers can provide specialized tools, resources, and functionality beyond the built-in features.

Configuration

To configure MCP servers, create a configuration file at ~/.nirmata/nctl/mcp.yaml. To use a different path, pass --mcp-config:

nctl ai --mcp-config "/path/to/custom/mcp.yaml"

An example ~/.nirmata/nctl/mcp.yaml:

servers:
 - name: resend-email
 command: node
 args:
 - /path/to/directory/mcp-send-email/build/index.js
 env:
 RESEND_API_KEY: your_api_key_here
 SENDER_EMAIL_ADDRESS: example@email.com
 REPLY_TO_EMAIL_ADDRESS: another_example@email.com
 capabilities:
 tools: true
 prompts: false
 resources: false
 attachments: true

Configuration Options

name: Unique identifier for the MCP server
command: Executable command to start the server (e.g., node, python, binary path)
args: Array of command-line arguments passed to the server
env: Environment variables required by the server (API keys, configuration values, etc.)
capabilities: Defines what features the server provides:
- tools: Server provides callable tools/functions
- prompts: Server provides prompt templates
- resources: Server provides data resources
- attachments: Server can handle file attachments

Note: Make sure the MCP server executable is installed and accessible at the specified path before adding it to the configuration.

Kyverno & Policy Health

Mon, 01 Jan 0001 00:00:00 +0000

The Kyverno Health Check feature in Nirmata Control Hub provides visibility into the operational health and configuration best practices of your Kyverno installation. It continuously analyzes Kyverno deployments across your clusters and offers a detailed health score based on four key categories:

Security
Availability
Scalability
Observability

Each category is evaluated independently and flagged as Healthy, Warning, or Critical based on current configurations. The overall health score is then calculated and displayed prominently in the UI.

Nirmata on Nirmata Documentation

Configuring Okta as an Identity Provider in Nirmata

Prerequisites

Configuration Steps

1. Create a New Application in Okta

2. Configure Application Settings

Nirmata Kube Controller

Deployment

Quick Start

Image Verification using Nirmata

Table of Contents

Steps for Image Verification

Prerequisites

Sign Image using cosign

AWS Asset Discovery Guide

Introduction

Prerequisites

GitHub App Integration Overview

Benefits

Next Steps

Terraform Cloud Integration Overview

Key Components

Architecture

Account

AI Usage

Getting Started

Quick Start

Prerequisites

Step 1: Install Kyverno MCP

Using Homebrew (macOS/Linux)

Step 3: Test the Connection

GitHub Authentication Guide

Overview

Authentication Methods

1. Nirmata GitHub App (Recommended)

Installation

Homebrew

Install

Verify

Upgrade

Uninstall

Binary download

nctl

nctl

Examples

SEE ALSO

nctl add

nctl add

Options

SEE ALSO

nctl add cluster

nctl add cluster

Examples

SEE ALSO

nctl ai

nctl ai

Examples

SEE ALSO

nctl compliance

nctl compliance

Options

SEE ALSO

nctl compliance audit

nctl compliance audit

Examples

SEE ALSO

nctl compliance checklist

nctl compliance checklist

Examples

Options

SEE ALSO

nctl create

nctl create

Options

SEE ALSO

nctl create pull-request

nctl create pull-request

Examples

Options

SEE ALSO