install

Signed-off-by: Charles-Edouard Brétéché <[email protected]>

best-practices/add-rolebinding/artifacthub-pkg.yml

@@ -4,7 +4,7 @@ displayName: Add RoleBinding
 createdAt: "2023-04-10T19:47:15.000Z"
 description: >-
   Typically in multi-tenancy and other use cases, when a new Namespace is created, users and other principals must be given some permissions to create and interact with resources in the Namespace. Very commonly, Roles and RoleBindings are used to grant permissions at the Namespace level. This policy generates a RoleBinding called `<userName>-admin-binding` in the new Namespace which binds to the ClusterRole `admin` as long as a `cluster-admin` did not create the Namespace. Additionally, an annotation named `kyverno.io/user` is added to the RoleBinding recording the name of the user responsible for the Namespace's creation.
-install: |- 
+install: |-
   ```shell
   kubectl apply -f https://raw.githubusercontent.com/kyverno/policies/main/best-practices/add-rolebinding/add-rolebinding.yaml
   ```

best-practices/add-safe-to-evict/artifacthub-pkg.yml

@@ -4,7 +4,7 @@ displayName: Add Safe To Evict
 createdAt: "2023-04-10T19:47:15.000Z"
 description: >-
   The Kubernetes cluster autoscaler does not evict pods that  use hostPath or emptyDir volumes. To allow eviction of these pods, the annotation  cluster-autoscaler.kubernetes.io/safe-to-evict=true must be added to the pods. 
-install: |- 
+install: |-
   ```shell
   kubectl apply -f https://raw.githubusercontent.com/kyverno/policies/main/best-practices/add-safe-to-evict/add-safe-to-evict.yaml
   ```

best-practices/check-deprecated-apis/artifacthub-pkg.yml

@@ -4,7 +4,7 @@ displayName: Check deprecated APIs
 createdAt: "2023-04-10T19:47:15.000Z"
 description: >-
   Kubernetes APIs are sometimes deprecated and removed after a few releases. As a best practice, older API versions should be replaced with newer versions. This policy validates for APIs that are deprecated or scheduled for removal. Note that checking for some of these resources may require modifying the Kyverno ConfigMap to remove filters. In the validate-v1-22-removals rule, the Lease kind has been commented out due to a check for this kind having a performance penalty on Kubernetes clusters with many leases. Its enabling should be attended carefully and is not recommended on large clusters. PodSecurityPolicy is removed in v1.25 so therefore the validate-v1-25-removals rule may not completely work on 1.25+. This policy requires Kyverno v1.7.4+ to function properly.
-install: |- 
+install: |-
   ```shell
   kubectl apply -f https://raw.githubusercontent.com/kyverno/policies/main/best-practices/check-deprecated-apis/check-deprecated-apis.yaml
   ```

best-practices/disallow-empty-ingress-host/artifacthub-pkg.yml

@@ -5,7 +5,7 @@ createdAt: "2023-04-10T19:47:15.000Z"
 description: >-
   An ingress resource needs to define an actual host name in order to be valid. This policy ensures that there is a hostname for each rule defined.
 install: |-
-  ```shell 
+  ```shell
   kubectl apply -f https://raw.githubusercontent.com/kyverno/policies/main/best-practices/disallow-empty-ingress-host/disallow-empty-ingress-host.yaml
   ```
 keywords:

istio/add-sidecar-injection-namespace/artifacthub-pkg.yml

@@ -5,7 +5,7 @@ createdAt: "2023-04-10T20:07:52.000Z"
 description: >-
   In order for Istio to inject sidecars to workloads deployed into Namespaces, the label `istio-injection` must be set to `enabled`. As an alternative to rejecting Namespace definitions which don't already contain this label, it can be added automatically. This policy adds the label `istio-inject` set to `enabled` for all new Namespaces.
 install: |-
-  ```shell 
+  ```shell
   kubectl apply -f https://raw.githubusercontent.com/kyverno/policies/main/istio/add-sidecar-injection-namespace/add-sidecar-injection-namespace.yaml
   ```
 keywords:

nginx-ingress/disallow-ingress-nginx-custom-snippets/artifacthub-pkg.yml

@@ -4,7 +4,7 @@ displayName: Disallow Custom Snippets
 createdAt: "2023-04-10T20:23:06.000Z"
 description: >-
   Users that can create or update ingress objects can use the custom snippets  feature to obtain all secrets in the cluster (CVE-2021-25742). This policy  disables allow-snippet-annotations in the ingress-nginx configuration and  blocks *-snippet annotations on an Ingress. See: https://github.com/kubernetes/ingress-nginx/issues/7837
-install: |- 
+install: |-
   ```shell
   kubectl apply -f https://raw.githubusercontent.com/kyverno/policies/main/nginx-ingress/disallow-ingress-nginx-custom-snippets/disallow-ingress-nginx-custom-snippets.yaml
   ```

other/b-d/block-cluster-admin-from-ns/artifacthub-pkg.yml

@@ -6,10 +6,10 @@ createdAt: "2023-05-18T00:00:00.000Z"
 description: >-
   In some cases we would want to block operations (CREATE/UPDATE/DELETE) of certain privileged users (i.e. cluster-admins), in a specific namespace.
           In this policy, Kyverno look for all user operations (`CREATE, UPDATE, DELETE`), on every object kind (Pod,Deployment,Route,Service,etc.), in the testnamespace namespace, and for the `clusterRole cluster-admin`. The `subject User testuser` is also mentioned so it won’t include all the cluster-admins in the cluster, but will be flexiable enough to apply only for a sub-group of the cluster-admins in the cluster.
-install: |- 
-    ```shell
-    kubectl apply -f https://raw.githubusercontent.com/kyverno/policies/main/other/b-d/block-cluster-admin-from-ns/block-cluster-admin-from-ns.yaml
-    ```   
+install: |-
+  ```shell
+  kubectl apply -f https://raw.githubusercontent.com/kyverno/policies/main/other/b-d/block-cluster-admin-from-ns/block-cluster-admin-from-ns.yaml
+  ```   
 keywords:
   - rbac
   - cluster-admin 

other/b-d/block-pod-exec-by-namespace/artifacthub-pkg.yml

@@ -4,7 +4,7 @@ displayName: Block Pod Exec by Namespace Name
 createdAt: "2023-04-10T20:30:03.000Z"
 description: >-
   The `exec` command may be used to gain shell access, or run other commands, in a Pod's container. While this can be useful for troubleshooting purposes, it could represent an attack vector and is discouraged. This policy blocks Pod exec commands to Pods in a Namespace called `pci`.
-install: |- 
+install: |-
   ```shell
   kubectl apply -f https://raw.githubusercontent.com/kyverno/policies/main/other/b-d/block-pod-exec-by-namespace/block-pod-exec-by-namespace.yaml
   ```

other/b-d/block-pod-exec-by-pod-name/artifacthub-pkg.yml

@@ -7,7 +7,6 @@ description: >-
 install: |-
   ```shell
   kubectl apply -f https://raw.githubusercontent.com/kyverno/policies/main/other/b-d/block-pod-exec-by-pod-name/block-pod-exec-by-pod-name.yaml
-  ``
   ```
 keywords:
   - kyverno

other/b-d/check-serviceaccount/artifacthub-pkg.yml

@@ -4,7 +4,7 @@ displayName: Check ServiceAccount
 createdAt: "2023-04-10T20:30:03.000Z"
 description: >-
   ServiceAccounts with privileges to create Pods may be able to do so and name a ServiceAccount other than the one used to create it. This policy checks the Pod, if created by a ServiceAccount, and ensures the `serviceAccountName` field matches the actual ServiceAccount.
-install: |- 
+install: |-
   ```shell
   kubectl apply -f https://raw.githubusercontent.com/kyverno/policies/main/other/b-d/check-serviceaccount/check-serviceaccount.yaml
   ```

other/b-d/check-subjectaccessreview/artifacthub-pkg.yml

@@ -4,7 +4,7 @@ displayName: Check SubjectAccessReview
 createdAt: "2023-05-01T00:00:00.000Z"
 description: >-
   In some cases a validation check for one type of resource may need to take into consideration the requesting user's permissions on a different type of resource. Rather than parsing through all Roles and/or ClusterRoles to check if these permissions are held, Kyverno can perform a SubjectAccessReview request to the Kubernetes API server and have it figure out those permissions. This policy illustrates how to perform a POST request to the API server to subject a SubjectAccessReview for a user creating/updating a ConfigMap. It is intended to be used as a component in a more functional rule.
-install: |- 
+install: |-
   ```shell
   kubectl apply -f https://raw.githubusercontent.com/kyverno/policies/main/other/b-d/check-subjectaccessreview/check-subjectaccessreview.yaml
   ```

other/b-d/cordon-and-drain-node/artifacthub-pkg.yml

@@ -6,7 +6,7 @@ description: >-
   There are cases where either an operations or security incident may occur and Nodes should be evacuated and placed in an unused state for further analysis. For example, a Node is found to be running a vulnerable version of a CRI engine or kernel and to minimize chances of a compromise may need to be decommissioned so another can be built. This policy shows how to use Kyverno to both cordon and drain a given Node and uses a hypothetical label being written to it called `testing=drain` to illustrate the point. For production use, the match block should be modified to trigger on the appropriate condition.
 install: |-
   ```shell
-  kubectl apply -f https://raw.githubusercontent.com/kyverno/policies/main/other/b-d/b-d/cordon-and-drain-node/cordon-and-drain-node.yaml
+  kubectl apply -f https://raw.githubusercontent.com/kyverno/policies/main/other/b-d/cordon-and-drain-node/cordon-and-drain-node.yaml
   ```
 keywords:
   - kyverno

other/b-d/create-pod-antiaffinity/artifacthub-pkg.yml

@@ -4,7 +4,7 @@ displayName: Add Pod Anti-Affinity
 createdAt: "2023-04-10T20:30:03.000Z"
 description: >-
   Applications may involve multiple replicas of the same Pod for availability as well as scale purposes, yet Kubernetes does not by default provide a solution for availability. This policy sets a Pod anti-affinity configuration on Deployments which contain an `app` label if it is not already present.
-install: |- 
+install: |-
   ```shell
   kubectl apply -f https://raw.githubusercontent.com/kyverno/policies/main/other/b-d/create-pod-antiaffinity/create-pod-antiaffinity.yaml
   ```

other/b-d/deny-commands-in-exec-probe/artifacthub-pkg.yml

@@ -5,7 +5,7 @@ createdAt: "2023-05-01T00:00:00.000Z"
 description: >-
   Developers may feel compelled to use simple shell commands as a workaround to creating "proper" liveness or readiness probes for a Pod. Such a practice can be discouraged via detection of those commands. This policy prevents the use of certain commands `jcmd`, `ps`, or `ls` if found in a Pod's liveness exec probe.
 
-install: |- 
+install: |-
   ```shell
   kubectl apply -f https://raw.githubusercontent.com/kyverno/policies/main/other/b-d/deny-commands-in-exec-probe/deny-commands-in-exec-probe.yaml
   ```

other/e-l/forbid-cpu-limits/artifacthub-pkg.yml

@@ -6,7 +6,7 @@ description: >-
   Setting of CPU limits is a debatable poor practice as it can result, when defined, in potentially starving applications of much-needed CPU cycles even when they are available. Ensuring that CPU limits are not set may ensure apps run more effectively. This policy forbids any container in a Pod from defining CPU limits.
 install: |-
   ```shell
-  kubectl apply -f https://raw.githubusercontent.com/kyverno/policies/main/other/e-l/e-l/forbid-cpu-limits/forbid-cpu-limits.yaml
+  kubectl apply -f https://raw.githubusercontent.com/kyverno/policies/main/other/e-l/forbid-cpu-limits/forbid-cpu-limits.yaml
   ```
 keywords:
   - kyverno

other/e-l/generate-networkpolicy-existing/artifacthub-pkg.yml

@@ -4,7 +4,7 @@ displayName: Generate NetworkPolicy to Existing Namespaces
 createdAt: "2023-04-10T20:30:04.000Z"
 description: >-
   A NetworkPolicy is often a critical piece when provisioning new Namespaces, but there may be existing Namespaces which also need the same resource. Creating each one individually or manipulating each Namespace in order to trigger creation is additional overhead. This policy creates a new NetworkPolicy for existing Namespaces which results in a default deny behavior and labels it with created-by=kyverno.
-install: |- 
+install: |-
   ```shell
   kubectl apply -f https://raw.githubusercontent.com/kyverno/policies/main/other/e-l/generate-networkpolicy-existing/generate-networkpolicy-existing.yaml
   ```

other/e-l/inject-sidecar-deployment/artifacthub-pkg.yml

@@ -4,7 +4,7 @@ displayName: Inject Sidecar Container
 createdAt: "2023-04-10T20:30:04.000Z"
 description: >-
   The sidecar pattern is very common in Kubernetes whereby other applications can insert components via tacit modification of a submitted resource. This is, for example, often how service meshes and secrets applications are able to function transparently. This policy injects a sidecar container, initContainer, and volume into Pods that match an annotation called `vault.hashicorp.com/agent-inject: true`.
-install: |- 
+install: |-
   ```shell
   kubectl apply -f https://raw.githubusercontent.com/kyverno/policies/main/other/e-l/inject-sidecar-deployment/inject-sidecar-deployment.yaml
   ```

other/e-l/inspect-csr/artifacthub-pkg.yml

@@ -4,7 +4,7 @@ displayName: Inspect CertificateSigningRequest
 createdAt: "2023-04-25T00:00:00.000Z"
 description: >-
   The Kubernetes API includes a CertificateSigningRequest resource which can be used to generate a certificate for an entity. Because this API can be abused to create a long-lived credential, it is important to be able to audit this API to understand who/what is creating these CSRs and for what actors they are being created. This policy, intended to always be run in Audit mode and produce failure results in a Policy Report, inspects all incoming CertificateSigningRequests and writes out into the Policy Report information on who/what requested it and parsing the CSR to show the Subject information of that CSR resource.
-install: |- 
+install: |-
   ```shell
   kubectl apply -f https://raw.githubusercontent.com/kyverno/policies/main/other/e-l/inspect-csr/inspect-csr.yaml
   ```

other/e-l/label-existing-namespaces/artifacthub-pkg.yml

@@ -4,7 +4,7 @@ displayName: Label Existing Namespaces
 createdAt: "2023-04-10T20:30:04.000Z"
 description: >-
   Namespaces which preexist may need to be labeled after the fact and it is time consuming to identify which ones should be labeled and either doing so manually or with a scripted approach. This policy, which triggers on any AdmissionReview request to any Namespace, will result in applying the label `mykey=myvalue` to all existing Namespaces. If this policy is updated to change the desired label key or value, it will cause another mutation which updates all Namespaces.
-install: |- 
+install: |-
   ```shell
   kubectl apply -f https://raw.githubusercontent.com/kyverno/policies/main/other/e-l/label-existing-namespaces/label-existing-namespaces.yaml
   ```

other/e-l/limit-hostpath-vols/artifacthub-pkg.yml

@@ -7,7 +7,6 @@ description: >-
 install: |-
   ```shell
   kubectl apply -f https://raw.githubusercontent.com/kyverno/policies/main/other/e-l/limit-hostpath-vols/limit-hostpath-vols.yaml
-  ``
   ```
 keywords:
   - kyverno

other/m-q/mitigate-log4shell/artifacthub-pkg.yml

@@ -4,7 +4,7 @@ displayName: Log4Shell Mitigation
 createdAt: "2023-04-10T20:30:04.000Z"
 description: >-
   In response to CVE-2021-44228 referred to as Log4Shell, a RCE vulnerability in the Log4j library, a partial yet incomplete workaround for versions 2.10 to 2.14.1 of the library is to set the environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS to "true". While this does provide some benefit by limiting exposure, there are still code paths which can exploit this vulnerability. It is highly recommended to upgrade log4j as soon as possible. See https://logging.apache.org/log4j/2.x/security.html for more details. This policy will mutate all initContainers and containers in an incoming Pod to add this environment variable automatically.
-install: |- 
+install: |-
   ```shell
   kubectl apply -f https://raw.githubusercontent.com/kyverno/policies/main/other/m-q/mitigate-log4shell/mitigate-log4shell.yaml
   ```

other/m-q/namespace-protection/artifacthub-pkg.yml

@@ -4,7 +4,7 @@ displayName: Namespace Protection
 createdAt: "2023-04-10T20:30:04.000Z"
 description: >-
   Cases where RBAC may be applied at a higher level and where Namespace-level protections may be necessary can be accomplished with a separate policy. For example, one may want to protect creates, updates, and deletes on only a single Namespace. This policy will block creates, updates, and deletes to any Namespace labeled with `freeze=true`. Caution should be exercised when using rules which match on all kinds (`"*"`) as this will involve, for larger clusters, a substantial amount of processing on Kyverno's part. Additional resource requests and/or limits may be required.
-install: |- 
+install: |-
   ```shell
   kubectl apply -f https://raw.githubusercontent.com/kyverno/policies/main/other/m-q/namespace-protection/namespace-protection.yaml
   ```

other/res/restrict-node-affinity/artifacthub-pkg.yml

@@ -4,7 +4,7 @@ displayName: Restrict Node Affinity
 createdAt: "2023-04-10T20:30:06.000Z"
 description: >-
   Pods may use several mechanisms to prefer scheduling on a set of nodes, and nodeAffinity is one of them. nodeAffinity uses expressions to select eligible nodes for scheduling decisions and may override intended placement options by cluster administrators. This policy ensures that nodeAffinity is not used in a Pod spec.
-install: |- 
+install: |-
   ```shell
   kubectl apply -f https://raw.githubusercontent.com/kyverno/policies/main/other/res/restrict-node-affinity/restrict-node-affinity.yaml
   ```

other/s-z/verify-manifest-integrity/artifacthub-pkg.yml

@@ -6,7 +6,7 @@ description: >-
   Verifying the integrity of resources is important to ensure no tampering has occurred, and in some cases this may need to be extended to certain YAML manifests deployed to Kubernetes. Starting in Kyverno 1.8, these manifests may be signed with Sigstore and the signature(s) validated to prevent this tampering while still allowing some exceptions on a per-field basis. This policy verifies Deployments are signed with the expected key but ignores the `spec.replicas` field allowing other teams to change just this value.
 install: |-
   ```shell
-     kubectl apply -f https://raw.githubusercontent.com/kyverno/policies/main/other/s-z/verify-manifest-integrity/verify-manifest-integrity.yaml
+  kubectl apply -f https://raw.githubusercontent.com/kyverno/policies/main/other/s-z/verify-manifest-integrity/verify-manifest-integrity.yaml
   ```
 keywords:
   - kyverno

pod-security/restricted/disallow-capabilities-strict/artifacthub-pkg.yml

@@ -6,7 +6,7 @@ description: >-
   Adding capabilities other than `NET_BIND_SERVICE` is disallowed. In addition, all containers must explicitly drop `ALL` capabilities.
 install: |-
   ```shell
-  kubectl apply -f https://raw.githubusercontent.com/kyverno/policies/main/pod-security/strict/disallow-capabilities-strict/disallow-capabilities-strict.yaml
+  kubectl apply -f https://raw.githubusercontent.com/kyverno/policies/main/pod-security/restricted/disallow-capabilities-strict/disallow-capabilities-strict.yaml
   ```
 keywords:
   - kyverno

pod-security/restricted/require-run-as-nonroot/artifacthub-pkg.yml

@@ -4,7 +4,7 @@ displayName: Require runAsNonRoot
 createdAt: "2023-04-10T23:16:53.000Z"
 description: >-
   Containers must be required to run as non-root users. This policy ensures `runAsNonRoot` is set to `true`. A known issue prevents a policy such as this using `anyPattern` from being persisted properly in Kubernetes 1.23.0-1.23.2.
-install: |- 
+install: |-
   ```shell
   kubectl apply -f https://raw.githubusercontent.com/kyverno/policies/main/pod-security/restricted/require-run-as-nonroot/require-run-as-nonroot.yaml
   ```

pod-security/subrule/restricted/restricted-exclude-capabilities/artifacthub-pkg.yml

@@ -4,7 +4,7 @@ displayName: Restricted Pod Security Standards with Container-Level Control Exem
 createdAt: "2023-04-10T23:19:50.000Z"
 description: >-
   The restricted profile of the Pod Security Standards, which is inclusive of the baseline profile, is a collection of all the most common configurations that can be taken to secure Pods. Beginning with Kyverno 1.8, an entire profile may be assigned to the cluster through a single rule. In some cases, specific exemptions must be made on a per-control basis. This policy configures the restricted profile through the latest version of the Pod Security Standards cluster wide while exempting `nginx` and `redis` container images from the Capabilities control check.
-install: |- 
+install: |-
   ```shell
   kubectl apply -f https://raw.githubusercontent.com/kyverno/policies/main/pod-security/subrule/restricted/restricted-exclude-capabilities/restricted-exclude-capabilities.yaml
   ```

velero/backup-all-volumes/artifacthub-pkg.yml

@@ -11,9 +11,9 @@ description: >-
       all volumes are listed in the aforementioned annotation if a Namespace with the label
       `velero-backup-pvc=true`.
 install: |-
-    ```shell
-    kubectl apply -f https://raw.githubusercontent.com/kyverno/policies/main/velero/backup-all-volumes/backup-all-volumes.yaml
-     ```
+  ```shell
+  kubectl apply -f https://raw.githubusercontent.com/kyverno/policies/main/velero/backup-all-volumes/backup-all-volumes.yaml
+  ```
 keywords:
   - velero
   - kyverno

velero/block-velero-restore/artifacthub-pkg.yml

@@ -10,9 +10,9 @@ description: >-
       It checks the Restore CRD object and its namespaceMapping field. If destination match protected namespace
       then operation fails and warning message is throw.
 install: |-
-    ```shell
-    kubectl apply -f https://raw.githubusercontent.com/kyverno/policies/main/velero/block-velero-restore/block-velero-restore.yaml
-    ```
+  ```shell
+  kubectl apply -f https://raw.githubusercontent.com/kyverno/policies/main/velero/block-velero-restore/block-velero-restore.yaml
+  ```
 keywords:
   - velero
   - kyverno