--- title: "Policy Hub" description: "Policy management, reporting, exceptions, and compliance in Nirmata Control Hub." diataxis: how-to applies_to: product: "nirmata-control-hub" audience: ["platform-engineer","devsecops"] last_updated: 2026-04-16 url: https://docs.nirmata.io/docs/control-hub/policy-hub/ --- > **Applies to:** Nirmata Control Hub 4.0 and later Policy Hub is the central place in Nirmata Control Hub for managing all aspects of Kyverno policy governance across your clusters — from applying policy sets to reviewing violations, managing exceptions, and tracking compliance. ## Capabilities - [Policy Sets]({{< relref "policy-sets/" >}}) — Apply curated and custom policy sets to clusters and namespaces - [Policy Reports]({{< relref "policy-reports/" >}}) — View and share policy violation reports across clusters - [Policy Exceptions]({{< relref "policy-exceptions/" >}}) — Manage temporary deviations from policy with approval workflows - [Auto Remediations]({{< relref "Remediations/" >}}) — Automated, context-aware suggestions for resolving violations - [Repository Scanning]({{< relref "repository-scan-reports/" >}}) — Scan Git repositories for policy compliance - [Compliance]({{< relref "Compliance/" >}}) — Map policy violations to compliance controls and standards - [Offline Cluster Scanning]({{< relref "offline-cluster-scanning/" >}}) — Scan clusters without in-cluster agents using nctl --- ## Offline Cluster Scanning ## Overview [nctl](/docs/nctl/getting-started) provides a seamless way to scan Kubernetes clusters for misconfigurations without the need for any in-cluster agents. Leveraging the kubeconfig and Kubernetes context, `nctl` scans your clusters against policysets defined in Nirmata. The results are then published in the Nirmata Control Hub dashboard, where you can view detailed insights and remediation steps, share reports with your team, and manage multiple clusters from a single platform. ## Key Features * Agent-less scanning: No need to install agents in your Kubernetes clusters. * Policy-based scanning: Automatically scans clusters against policysets defined in Nirmata. * Real-time insights: Get immediate, actionable security and operational reports. * Unified dashboard: View results for all clusters in one central platform. ## Prerequisites * Kubernetes Access: Ensure you have access to your clusters via kubectl and a valid kubeconfig file. * Nirmata Account: You will need an active Nirmata Control Hub account for policy management and report viewing. If you don't have one, sign up for a [15-day free trial](https://try.nirmata.io/). * Tools: * nctl: Download the CLI tool [here](/docs/nctl/installation) * kubectl: Ensure kubectl is installed and configured ## Setup and Configuration ### Step 1: Verify Kubernetes Context Before running any scan, ensure that you are using the correct Kubernetes context. To check your current context, run the following command: ```bash kubectl config current-context ```text If you need to switch to a different context, use the command: ```bash kubectl config use-context ```text ### Step 2: Configure Policies for Scan Policies can be loaded from various sources. The following options are available: * Use the `--policies` flag to load policies from the local filesystem or point to a Git URL * Use the `--cluster-policies` flag if you want to use policies already present in the cluster * Use the `--policysets` flag to refer to policysets in Nirmata Control Hub * If you are logged into Nirmata Control Hub, the policysets that are marked as default or have matching label selectors will be used for scanning * If none of the above apply, nctl uses three default policysets: * Pod Security Standard - Baseline * Pod Security Standard - Restricted * RBAC Best Practices ## Performing an Offline Scan ### Step 1: Initiate the Scan Once you've set up your policies, initiate the scan using nctl. The CLI will automatically detect the active Kubernetes context and scan your cluster against the configured policies. Login to Nirmata Control Hub to retrieve policysets and publish the results of the scan. ```bash nctl login npm --url https://www.nirmata.io --userid --token ```text Run the following command: ```bash nctl scan kubernetes --cluster-resources --publish ```text >Note: The reports will be published to Nirmata Control Hub **only** if you are logged into your Nirmata Control Hub account. This command will: * Scan the currently selected Kubernetes context. * Report misconfigurations against the configured policies. * Output the results directly to your CLI. ### Step 2: View Results in the CLI Once the scan is complete, the results are shown directly in your terminal. The output includes: * A summary of passed and failed policy checks. * Detailed information on violations. ## Viewing and Managing Scan Reports in Nirmata Control Hub ### Step 1: Access the Nirmata Control Hub Dashboard After scanning, the results are automatically published to the Nirmata Control Hub dashboard, where you can see a unified view of your cluster scans. ![image](/images/offline-scan.png) * Login to the Nirmata Control Hub Dashboard. * Navigate to Cluster Reports: Go to the _Policy Reports > Clusters_ section to view all scans across multiple clusters. ### Step 2: Analyze and Share Results The Nirmata Control Hub dashboard provides detailed insights into each scan: * Unified View: See the security posture of multiple clusters, with aggregated grades and detailed pass/fail results. * Issue Breakdown: Dive into individual policy violations for more detailed information, including affected resources and remediation steps. * Collaboration Features: Share reports with team members or export them for auditing purposes. --- ## Policy Reports ### View Policy Reports in Nirmata Control Hub Policy Reports provide a comprehensive overview of clusters, namespaces, and repositories. **To access the Policy Reports:** 1. Go to **Policies** > **Policy Reports**. The Policy Reports can be viewed based on Categories, Clusters, Namespaces, or Repositories. ![image](/images/policy_reports.png) 2. To view the Policy Reports in any Category, click on the Category Name (for example, **RBAC Best Practices**). The findings in this category will be displayed with information related to Severity, Findings, Impact (Clusters and Resources), and Status (% Pass or Fail). ![image](/images/rbac_best_practices.png) 3. To view a detailed report of a particular finding, click on any **Findings** link. The details contain violation and policy information such as the policy name, rule name, severity of the violation, and other metadata. The page also lists the impacted resources for this finding. ![image](/images/policy_findings.png) ### Sharing Policy Reports To share policy reports with your team, click on the `Share` icon on the top right of the page. 1. Optionally edit the title of the report. 1. Select either the `Cluster` or `Namespace` scope for the report. 1. Filtered Findings is used to generate the report based on the filters applied on the page. 1. All Findings includes all the results for the given cluster or namespaces. 1. You can either download the report or send email to your team members. 1. To send email, the user need not be present in the Nirmata system. However, the email domain should be pre-configured in Nirmata Control Hub. 1. To schedule periodic emails, click on `Email` and then set the schedule to periodically send the emails to all the recipients. ![image](/images/share-report.png) --- ## Repository Scanning Repository scan reports provide insights on the compliance of different Git repositories containing configuration files. ## Onboarding Repositories Add Git repositories to the Nirmata Control Hub to view scan reports containing misconfiguration information. Git providers like GitHub, GitLab, and BitBucket are supported. To onboard a repository with Nirmata: 1. Go to **Menu**>**Repositories**. The repositories page with the listed scanned repositories is displayed. The page shows the repository names, their last scanned status, the branches available within them, the type, and the number of files present within the repositories. ![image](/images/repositories-list.png) 2. Click on the `Adding Repositories with nctl` button located on the right hand top corner of the screen. It will display the repositories onboarding page. This workflow requires `nctl`. Refer to the [documentation](https://docs.nirmata.io/docs/nctl/) for installation. 3. The repositories onboarding page requires the repository details. Enter the URL of the repository to be scanned under `Repository URL` and labels under `Labels`. Labels are optional but it should be entered as a key-value pair. Click on the `+` button to add multiple labels. 4. After entering the repository details, scroll down to click on the `Scan Repos with Compliance Standards` button to proceed to the next step. ![image](/images/repositories-onboarding.png) 5. Select the Nirmata curated policies with which the repository needs to be scanned by clicking on the toggle switch beside them. The set of policies are grouped under `Kubernetes`, `Dockerfile`, and `Terraform`. Click on each of them to see further profiling of policies and select the ones based on the needs. 6. The repository can be scanned with custom policies as well. In that case, enter the policy repository URL beside `Policy file or directory`. ![image](/images/set-policies.png) 7. After selecting the polices for scanning, click on the `Repo Scan Commands` button to proceed to the final step. 8. The `nctl` commands required to scan the repository are shown in the final step based on the selection. Copy and run the commands in the shell/terminal to perform the repository scan and publish the reports to Nirmata Control Hub. ![image](/images/run-commands.png) >Note: While using the `nctl login` command, if the token is not auto generated, visit the Profile page and click on `Generate API Key` button to generate the token. 9. After successfully running the commands, click on the `Done` button to complete the onboarding process. The onboarded repository will now be listed on the Repositories page. ## Publishing Repository Scan Results to Nirmata Control Hub via the CLI ### Admin User Login to the Nirmata Control Hub tenant with the user's API Key. ```bash nctl login --url https://nirmata.io --userid admin@acme.corp --token ```text Clone the repository locally. ```bash git clone https://github.com/nirmata/nctl-shift-left ```text Run the repo scan command ```bash nctl scan repository ./nctl-shift-left --policy-sets pss-baseline ```text ### DevOps User Login to the Nirmata Control Hub tenant with the user's API Key. ```bash nctl login --url https://nirmata.io --userid user@acme.corp --token ```text Clone the repository locally. ```bash git clone https://github.com/nirmata/nctl-shift-left ```text >NOTE: A DevOps user can publish scan reports to Nirmata Control Hub **only** if they belong to a team that has permission to publish scan results. Please contact an Admin user for granting permission. Run the repo scan command ```bash nctl scan repository ./nctl-shift-left --policy-sets pss-baseline --publish-token ```text >NOTE: All users belonging to the team will be able to view the repository scan results. ## Publishing Repository Scan Results to Nirmata Control Hub via CI Pipelines To scan repositories and publish report to Nirmata Control Hub via CI pipelines, refer to the [Workflows](../workflows/PipelineScanning/_index.md) section. ## Viewing Repository Scan Reports in Nirmata Control Hub To view the scan reports: 1. Go to **Policies**>**Policy Reports**. The Policy Reports can be viewed based on Categories, Clusters, Namespaces, and Repositories. 2. Click on the **Repositories** tab to get a list of the available repositories. The information related to the repositories are displayed with the type and number of files present within, the grade obtained, and the status of the repository with the number of *Failed, Warning, Passed, Error, and Skipped*. ![image](/images/repositories_view.png) 3. Click on any of the repositories to view the list of findings under the **Findings** tab. The findings are displayed with information related to *Impact (File Types and # of Files), and Status (% Pass or Fail)*. The page also shows the repository status with the overall grade, % Pass, and % Fail. 4. To view the findings on different available branches of the repository, change the branch by clicking on the `All Branches` tab at the top of the screen. Filter the violations by severity by clicking on the `Severity` tab located beside the search bar. Click on the `Filter File Type` tab to filter by the type of file with which the violation is associated. ![image](/images/view_findings.png) 5. Now, click on any of the findings to view the details of the finding. The details contain violation and policy information as the policy name, rule name, severity of the violation, and other metadata. The page also lists the impacted files associated with the violation, their branch name, and status. ![image](/images/finding_detail.png) 6. Go back to the previous page and click on the **Files** tab to view the list of impacted files. The files are listed with information detailing the Status of the file with *Failed, Warning, Passed, Error, and Skip* and the number of violations that has impacted the file. The files can be viewed in different branches of the repository and can be filtered according to the type and status of the file. ![image](/images/view_file.png) ## Adding Ownership to Repositories A team or a user can be added to a repository as an owner to get access to the repository scan reports. To add a user or a Team as an owner to a repository: 1. Go to **Menu**>**Repositories**. The page lists the scanned repositories and the information related to them. At the end of each row displaying information about a scanned repository, the button for editing owners to the repository is present. 2. Click on the button with the `+` sign on the far right hand side of the row to open the dialog box for adding and editing Users/Teams to a particular repository. 3. Select `Add Users` or `Add Teams` from the dropdown depending on the preference. 4. Next, select the User or Team to be selected as owner from the list of Users or Teams available in the dropdown. 5. Then, click on the `+` button to add that User or Team as the owner of that repository. 6. Finally, click **Save**. ![image](/images/repository-owners.png) >Note: By default, an Admin user has access to all repositories. Only an Admin user can add other users/teams as repository owners. Similarly, repository publishing for DevOps users in a Team can be configured by an Admin user. To configure repository publishing for DevOps users in all teams: 1. Go to **Identity & Access**>**Teams**. All Teams available are displayed on this page. 2. Click on the `Configure` button located on the right hand top corner of the screen. The *Team Settings* dialog box opens. 3. Next, scroll down to **Repositories** and click on the `toggle button` beside **Enable repository publishing for all Nirmata Control Hub teams**. 4. Finally, click **Save**. ![image](/images/repositories_allteams.png) To configure repository publishing for DevOps users of a particular team: 1. Go to **Identity & Access**>**Teams** and click on the team card that needs permission to publish scan reports. 2. Now, click on the `toggle button` beside **Enable repository publishing for team members**. 3. The DevOps users in the team can now publish scan reports to Nirmata Control Hub. ![image](/images/repositories_particularteam.png) --- ## Auto Remediations Remediations in Nirmata Control Hub enable automated, context-aware suggestions for resolving policy violations in your workloads and resources. This feature is designed to accelerate remediation workflows while improving compliance and security posture across your environments. ## Prerequisites 1. Remediation Assistant should be enabled for your tenant. 1. Go to _Settings>AI_ and enable Remediation Assistant. >NOTE: Only users with Admin access can change the AI settings for the tenant. ## How it Works When a workload or resource in your cluster violates policies or rules defined in Nirmata Control Hub, the system can now generate AI-powered remediation suggestions. These are based on the specific context of the resource and the policy violation. Key details: * Remediations are generated using Cloud 3.7, a large language model (LLM). * The suggestions are designed to provide a first-level fix to bring resources back into compliance. * Each remediation includes a summary of the changes and a rationale for the suggested fix. >NOTE: While AI-generated remediations are often accurate and actionable, it is strongly recommended to review and test all changes before applying them to production or target environments. ## Supported Resources AI Remediations can be generated for any Kubernetes resource that violates policy—this includes Deployments, Services, ConfigMaps, NetworkPolicies, and more. ## Viewing Remediation Suggestions in Nirmata Control Hub 1. Go to _Policy Reports>Namespace>Resources_. 1. For every resource with one or more violations, the `Actions` column has a remediate option. 1. Clicking on the remediate icon will show a diff of actual resource vs the remediated resource. 1. Review the changes suggested and also go through the explanation to understand why a particular change is necessary. ![image](/images/rem-diff.png) ## Best Practices * Always validate AI-generated remediations in a test environment before promoting to production. * Treat AI Remediations as guided suggestions - ideal for improving MTTR (Mean Time to Remediate) and accelerating developer feedback loops. * Integrate with your GitOps or CI pipelines for automated yet controlled rollouts. --- ## Policy Sets Policy Sets are a collection of individual policies that allow a set of configuration standards to be applied to various objects within the Kubernetes clusters. ## Creating a Policy Set To create a new Policy Set: 1. Go to **Policies**>**Policy Sets**. The Policy Sets page displays the existing policy sets along with their details. ![image](/images/ps-default.png) 2. Click on the `Add Policy Set` button located on the top right-hand corner of the page. 3. Nirmata provides curated policy sets for Pod Security Standards and RBAC Best Practices. Nirmata manages these policies and upgrades them as necessary. The policies can be found in the [kyverno-policies](https://github.com/nirmata/kyverno-policies) repository. 4. It is not mandatory to use Nirmata's curated policy sets. Create a custom policy set by clicking on **Add Custom Policy Set**. This option provides more control over the lifecycle of the underlying policies. The page displays two options to create a policy set:
a. **Git (recommended)** - Select this option to create a Policy Set from an existing Git repository.
b. **YAML** - Select this option to create a Policy Set by uploading YAML files directly. ![image](/images/ps-options.png) ### Creating a Git Policy Set (Recommended) To create a Git Policy Set, click on the **Git** option. The Policy Set form is displayed. In that form: 1. Provide a unique name and description for the Policy Set. 2. Specify the time for sync interval in seconds under the `Sync Interval (seconds)` field. If not specified, the default sync interval will be 300 seconds. 3. Select the `Default Policy Set` checkbox if you want to make this policy set as a default whenever future clusters are onboarded. 3. Select `Auto Deploy Changes` checkbox if you want the changes in Git to automatically sync to the clusters. 4. Specify any cluster selectors under the `Cluster Selector` field by adding `Match Labels` and `Match Expressions` in the form of key-value pairs.
a. Add Match Labels by entering the values within the `key` and `value` sections.
b. Click on `Add item` to add multiple Match Labels.
c. Add Match Expressions by entering the values within the `key` and `value` sections and specifying the operator within the `operator` section from the drop-down list. The available `operator` options are *In*, *Not In*, *Exists*, and *Does Not Exist*. Multiple values for `Match Expressions` must be comma-separated (e.g., "value1, value2").
d. Click on `Add Selector` to add multiple Match Expressions.
>Note: In the case of multiple selectors being specified, all the cluster selectors must be satisfied for the Policy Set to be deployed to the cluster. 5. After specifying the cluster selectors, fill out the Git Repository, Branch, and Path details to fetch the policies. 8. If the repository is private, click on the `Private repository` checkbox. The `K8s secrets` form will be displayed. In that form:
a. Enter the name of the `namespace`, `secret`, and `token key`. >NOTE: Create a Kubernetes secret in the provided namespace containing Git credentials. This allows the Operator to connect to your private Git repo to fetch the policies. 9. After that, determine the repository type by clicking on the radio button beside `Policies`, `Kustomize`, and `HelmChart`.
a. If `HelmChart` is selected, an additional form will be displayed to specify the `Helm Customizations` in the form of key-value pair.
b. Enter the values for customization within the `key` and `value` section.
c. Click on `Add item` to add multiple customizations.
11. Finally, click **Create**. Upon clicking, the Policy Set gets created and the **Upload Policies** section opens. ![image](/images/add-git-ps.png) ### Creating a YAML Policy Set To create a YAML Policy Set: 1. Click on the **YAML** option. The Policy Set form is displayed. 2. In the **Name** field, enter a unique name for the Policy Set. 3. Click **Create**. Upon clicking, the Policy Set gets created and the **Upload Policies** section opens. ![image](/images/upload-policy-yaml.png) 4. Next, click on the section to upload the YAML policy. 5. After that, click on the **Import and Validate Policies** button. This will open the **Add Policies** section, where the policy added is validated and mentioned with a check mark if it passes the validation. ![image](/images/validate-policy-yaml.png) 6. Click on the **Add Valid Policies** button. The **Add Clusters** section is displayed with the list of available clusters. 7. Choose the cluster/s by clicking the checkbox on which the Policy Set created needs to be deployed. 8. Afterwards, click on the **Add Clusters** button. A success message is displayed. ![image](/images/add-clusters-yaml.png) 9. Finally, click **Done**. ## Viewing a Policy Set To view a newly created Policy Set: 1. Go to **Policies**>**Policy Sets**. The Policy Sets page displays the existing policy sets along with their details. 2. Click on the Policy Set card that is newly created. The created Policy Set page opens. 3. The Policy Set page contains information on the current policy version, the number of clusters subscribed with the policy set, the number of policies present in the policy set, and the last rollout status. ![image](/images/policy-set-view.png) 4. More clusters and policies can be added by clicking on the `+` button available within the cards. Alternatively, clicking on the `Add Cluster` button on the top right corner will do the same for adding clusters in the Policy Set. 5. The *Policies* tab opens by default. It contains information of the policies present in the Policy Set, including the *Name* of the policy, the *Source* of the policy, the *Scope* defined, any associated *Namespace*, and the *Description* of the policy. 6. Click on the *Clusters* and *Settings* tab to know more information about the subscribed clusters with the Policy Set and the settings of the overall Policy Set. ## Deploying Policy Set to Clusters In addition to specifying matching cluster labels and expressions for the policy sets, you can also directly choose the clusters to deploy policy sets. 1. Go to the policy set that you want to deploy. 2. Click on `Add Cluster` and select one or more clusters from the list. ## Verifying Policy Set Deployment 1. Go to the policy set and click on the `Deployed Policies` tab. All the deployed policies along with their Status will be shown. 2. Alternatively, if you have access to the kubeconfig of the cluster, use `kubectl` to view policies on the command line. ```bash kubectl get policyset -A kubectl get cpol ```text --- ## Policy Exceptions Management Policy Exceptions are temporary deviations that are required when following policy practices might not be possible because they can hinder operational needs. ## Policy Exception workflow Every policy exception request is sent to an admin for review. The admin can either accept or reject the request. If the request gets accepted, the PolicyException resource gets deployed and the user who requested the exception gets notified via email. ## Configuring Policy Exception Settings A Nirmata Admin User can manage the approval and review settings of Policy Exception Requests as per requirements. To manage the Policy Exception settings: 1. Go to **Settings** -> **Policy Exceptions**. 2. Manage the approval of Policy Exception Requests by checking the boxes beside the available options.
a. Checking the `Require Two Factor Authentication (2FA) to approve a request` option will require setting up two-factor authentication and compel users to complete the two-factor authentication to approve an exception request.
b. Checking the `Automatically approve requests by Administrators` option will automatically approve policy exception requests that are raised by administrators without going through the approval process.
c. Checking the `Revoke all approvals if the requestor changes the resources or policies for the exception` option will revoke any previous approvals given to an exception request if the user changes any of the target selectors like cluster, violations, or namespaces for the request.
3. Select the intital reviewers for the Policy Exception Requests under the `Reviewers and required approvals` section by choosing any of the available options.
a. Choosing the `Any Administrator or Platform user` option will allow any Admin or Platform user to review the raised exception request.
b. Choosing the `Selected Administrators` option will allow only the selected Admin users for the review of the requests. Multiple Admin users can be selected from the available dropdown. An Admin user can also add or remove reviewers on specific requests.
4. Define the number of reviewers required to approve a Policy Exception Request for the exception to be granted by writing the number in the given text box. 5. Click on the **Save** button to save the changes. ![image](/images/polex-admin-settings.png) ## Requesting a Policy Exception Policy Exception Request can be raised directly from the **Policy Exceptions** page or from the **Policy Reports** page of a particular namespace of a cluster. >Note: Existing clusters in Nirmata Control Hub need to provide extra permissions for Policy Exception expiry feature to work. The extra permission is for the `kverno-cleanup-controller` to delete policy exceptions from the cluster. Check out the `nirmata:policyexception-manager` ClusterRoleBinding in [Nirmata Kube Controller](https://docs.nirmata.io/docs/control-hub/cluster/nirmata-kube-controller/#clusterrolebindings) to see the changes. To raise a **Policy Exception Request**: 1. Go to **Policy** -> **Policy Exceptions**. The page displays the already created Policy Exception Requests that are either approved, denied, or requires approval. 2. Click on the `Request Policy Exception` button located on the right hand top corner of the screen. Fill out the Policy Exception Request form with all the details. 3. Give a brief description on why the exception is required. 4. Select the start date for the exception request to be applied according to the needs or opt for the option `Immediately after approval` to apply the exception immediately after approval from the reviewers. 5. Select the time duration for the policy excetion. The available options are `1 day`, `1 week`, `1 month`, or `Never Expires`. >NOTE: Exceptions should be short-lived. Thus, it is not recommended to use `Never Expires`. 6. Exceptions can be applied for cluster resources and/or repository files. a. If exceptions should be applied to cluster resources, select all the namespaces and clusters that require the exception. b. If exceptions should be applied to files in the Git repository, select all the repositories and branches that require the exception. 9. Select the violations for which the policy exception will be applied.
a. If the policy exception is to be applied to all the available policy violations in the selected namespaces and repositories, select the `All Violations` option.
![image](/images/polex-request.png) 8. Click on the `Request Exception` button to raise the Policy Exception Request. It will send an alert to the admin for a review. >Note: The Policy Exception Request can be raised in the same way through the Policy Reports page. For that, go to the **Policy Reports** page and view the available namespaces. Click on any of the namespaces that will require a Policy Exception, and raise a Policy exception request by clicking on the `Request Policy Exception` button. ## Reviewing a Policy Exception Request To review the Policy Exception Requests: 1. Go to **Policy** -> **Policy Exceptions**. The page displays the list of already created Policy Excepttion Requests. 2. Click on the Policy Exception Request name to view the created Policy Exception Request in detail. The page will also contain information on the activity of the reviewer under the **Reviews and Edits** section located at the right hand side of the screen. ![image](/images/polex-review.png) ## Viewing Policy Exceptions If a Policy Exception Request is approved, Nirmata Control Hub deploys the corresponding `PolicyException` resource to the target environments. These can be viewed under `Policy Exceptions -> Deployed Policy Exceptions` tab along with their deployment status and expiry details. >NOTE: For expiry of policy exceptions, Nirmata Control Hub uses the Cleanup Controller in Kyverno. This controller needs permissions to perform the cleanup action. Make sure the ClusterRoleBinding nirmata:policyexception-manager is present in the cluster. Review all nirmata resources [here](/docs/control-hub/cluster/nirmata-kube-controller/). --- ## Compliance Kyverno policies map to one or more compliance controls and compliance standards. Policy violations are generated when a resource fails a policy rule. A compliance standard contains various controls or rules that policies need to comply with. To view the Compliance report: 1. Go to **Menu**>**Compliance**. The Compliance Standards page with the default standards is displayed. In the top right corner of each standard, click the Kebab Menu to view the options: **Details**, **Generate Report**, **Clone**, **Disable**, and **Delete**. Additionally, the **Edit** option is displayed for User Managed Standards. Select any option for the respective action. 2. Click any default standard, for example, CIS Benchmarks v8. The CIS Benchmarks v8 report will be displayed. ![image](/images/new_compliance1.png) By default, the report shows Controls. Click the **Clusters** button to view the report for clusters. You can view the report for All Clusters or search for a particular cluster in the Search field. Additionally, you can filter by status and view the report for a particular status such as *pass*. 3. Click on the control name to see the details of the control, its status, policy mappings, and findings. Similarly by clicking on the Clusters button, you can view the cluster list and clicking on the cluster name, you can view the controls associated with it. You can also click on the control name to see the details of the control. 4. In the Compliance Standards page, click the **Add Standard** button to add a standard. A drop-down list of Nirmata Managed Standards and an option to add User Managed Standard are displayed. When you click the Nirmata Managed option, it is directly added. When you click the User Managed option, the Add Compliance Standard window opens.
a. Enter **Name, Version and Description** and click **Save**.
b. In the Controls block, you can either add a control by clicking on the **Add Control** button or import a CSV file by clicking the block, **Click to import a CSV file or drop a CSV file here**. >NOTE: Nirmata recommends you to add controls while adding the standard. However, you can skip this step and can add/update/delete controls later. c. Click on the **Download CSV Template** link to download the example template.
d. When you click on the Add Control button, the Add Compliance Control window opens. On this window, add **Control Details** such as Name, ID, SubID, Description, select **Cloud Providers** such as EKS, AKS, GKE, or Self Managed, and add **Policy Mappings** such as Policy Name, Rule, UUID, and click **Save**. ![image](/images/add_standard.png) 5. Click on the **Generate Report** button to generate a report on the standard. The Generate Report page opens.
a. In the Mail block, enter **Sender**, **Recipients**, **Subject**, **Message** details.
b. Select the **Schedule** checkbox to schedule the email. The options available are hourly, daily, weekly, and monthly.
c. Click on the **Save** button. 6. Click on the **Scheduled Reports** and click on the **+** symbol to schedule a periodic email to notify any policy violations. The Schedule Email window opens.
a. Select a cluster from the list or search the cluster and click **Next**. The Schedule Email page is displayed.
b. In the Scope block, select the radio button, either **Cluster or Namespaces** to choose the scope of the report.
c. In the Mail block, enter **Sender**, **Recipients**, **Subject**, **Message** details.
d. Select the **Schedule** checkbox to schedule the email. The options available are hourly, daily, weekly, and monthly.
e. Click on the **Save** button. 7. Go to **Policies**>**Policy Reports**. Click on the Kebab Menu at the right corner of the screen. The *Enable CIS Benchmarks* option is displayed. 8. Click on the **Enable CIS Benchmarks** option. A window to install kube-bench adapter is displayed. In this window you will see the instructions to execute commands to install the helm chart and run the cron job to see policy violations immediately. >NOTE: Installing kube-bench adapter prompts the user to check policy reports and report CIS Benchmark violations on a weekly schedule. 9. Click **OK**. ![image](/images/enable_cis_benchmark1.png)