Simplify instllation (#1382)

* add shallow substitution docs Signed-off-by: Jim Bugwadia <[email protected]> * update installation instructions Signed-off-by: Jim Bugwadia <[email protected]> * fix link Signed-off-by: Jim Bugwadia <[email protected]> --------- Signed-off-by: Jim Bugwadia <[email protected]> Co-authored-by: shuting <[email protected]>
kyverno · Oct 14, 2024 · a29e175 · a29e175
1 parent 69c4d1b
commit a29e175
Show file tree

Hide file tree

Showing 4 changed files with 51 additions and 91 deletions.
diff --git a/content/en/docs/high-availability/_index.md b/content/en/docs/high-availability/_index.md
@@ -77,4 +77,4 @@ Multiple replicas configured for the cleanup controller can be used for both ava
 
 ## Installing Kyverno in HA mode
 
-The Helm chart is the recommended method of installing Kyverno in a production-grade, highly-available fashion as it provides all the necessary Kubernetes resources and configuration options to meet most production needs. For more information on installation of Kyverno in high availability, see the corresponding [installation section](../installation/methods.md#high-availability).
+The Helm chart is the recommended method of installing Kyverno in a production-grade, highly-available fashion as it provides all the necessary Kubernetes resources and configuration options to meet most production needs. For more information on installation of Kyverno in high availability, see the corresponding [installation section](../installation/methods.md#high-availability-installation).
diff --git a/content/en/docs/installation/_index.md b/content/en/docs/installation/_index.md
@@ -40,24 +40,19 @@ A standard Kyverno installation consists of a number of different components, so
 
 ## Compatibility Matrix
 
-Kyverno follows the same support policy as the Kubernetes project (N-2 policy) in which the current release and the previous two minor versions are maintained. Although previous versions may work, they are not tested and therefore no guarantees are made as to their full compatibility. The below table shows the compatibility matrix.
+Kyverno follows the same support policy as the Kubernetes project (N-2 policy) in which the current release and the previous two minor versions are maintained. Although prior versions may work, they are not tested and therefore no guarantees are made as to their full compatibility. The below table shows the compatibility matrix.
 
 | Kyverno Version                | Kubernetes Min | Kubernetes Max |
 |--------------------------------|----------------|----------------|
-| 1.8.x                          | 1.23           | 1.25           |
-| 1.9.x                          | 1.24           | 1.26           |
-| 1.10.x                         | 1.24           | 1.26           |
 | 1.11.x                         | 1.25           | 1.28           |
 | 1.12.x                         | 1.26           | 1.29           |
 | 1.13.x                         | 1.28           | 1.31           |
 
-\* Due to a known issue with Kubernetes 1.23.0-1.23.2, support for 1.23 begins at 1.23.3.
-
-**NOTE:** The [Enterprise Kyverno](https://nirmata.com/nirmata-enterprise-for-kyverno/) by Nirmata supports a wide range of Kubernetes versions for any Kyverno version. Refer to the Release Compatibility Matrix for the Enterprise Kyverno [here](https://docs.nirmata.io/docs/n4k/release-compatibility-matrix/) or contact [Nirmata support](mailto:[email protected]) for assistance.
+**NOTE:** For long term compatibility Support select a [commercially supported Kyverno distribution](https://kyverno.io/support/nirmata).
 
 ## Security vs Operability
 
-For a production installation, Kyverno should be installed in [high availability mode](../installation/methods.md#high-availability). Regardless of the installation method used for Kyverno, it is important to understand the risks associated with any webhook and how it may impact cluster operations and security especially in production environments. Kyverno configures its resource webhooks by default (but [configurable](../writing-policies/policy-settings.md)) in [fail closed mode](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/#failure-policy). This means if the API server cannot reach Kyverno in its attempt to send an AdmissionReview request for a resource that matches a policy, the request will fail. For example, a validation policy exists which checks that all Pods must run as non-root. A new Pod creation request is submitted to the API server and the API server cannot reach Kyverno. Because the policy cannot be evaluated, the request to create the Pod will fail. Care must therefore be taken to ensure that Kyverno is always available or else configured appropriately to exclude certain key Namespaces, specifically that of Kyverno's, to ensure it can receive those API requests. There is a tradeoff between security by default and operability regardless of which option is chosen.
+For a production installation, Kyverno should be installed in [high availability mode](../installation/methods.md#high-availability-installation). Regardless of the installation method used for Kyverno, it is important to understand the risks associated with any webhook and how it may impact cluster operations and security especially in production environments. Kyverno configures its resource webhooks by default (but [configurable](../writing-policies/policy-settings.md)) in [fail closed mode](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/#failure-policy). This means if the API server cannot reach Kyverno in its attempt to send an AdmissionReview request for a resource that matches a policy, the request will fail. For example, a validation policy exists which checks that all Pods must run as non-root. A new Pod creation request is submitted to the API server and the API server cannot reach Kyverno. Because the policy cannot be evaluated, the request to create the Pod will fail. Care must therefore be taken to ensure that Kyverno is always available or else configured appropriately to exclude certain key Namespaces, specifically that of Kyverno's, to ensure it can receive those API requests. There is a tradeoff between security by default and operability regardless of which option is chosen.
 
 The following combination may result in cluster inoperability if the Kyverno Namespace is not excluded:
 

diff --git a/content/en/docs/installation/methods.md b/content/en/docs/installation/methods.md
@@ -6,44 +6,36 @@ weight: 15
 
 ## Install Kyverno using Helm
 
+The Helm chart is the recommended method of installing Kyverno in a production-grade, highly-available fashion as it provides all the necessary Kubernetes resources and configuration options to meet most production needs including platform-specific controls.
+
 Kyverno can be deployed via a Helm chart--the recommended and preferred method for a production install--which is accessible either through the Kyverno repository or on [Artifact Hub](https://artifacthub.io/). Both generally available and pre-releases are available with Helm.
 
-In order to install Kyverno with Helm, first add the Kyverno Helm repository.
+Choose one of the installation configuration options based upon your environment type and availability needs.
+- For a production installation, see below [High Availability](#high-availability-installation) section.
+- For a non-production installation, see below [Standalone Installation](#standalone-installation) section..
 
-```sh
-helm repo add kyverno https://kyverno.github.io/kyverno/
-```
+### Standalone Installation
 
-Scan the new repository for charts.
+To install Kyverno using Helm in a non-production environment use:
 
 ```sh
+helm repo add kyverno https://kyverno.github.io/kyverno/
 helm repo update
+helm install kyverno kyverno/kyverno -n kyverno --create-namespace
 ```
 
-Optionally, show all available chart versions for Kyverno.
-
-```sh
-helm search repo kyverno -l
-```
-
-Choose one of the installation configuration options based upon your environment type and availability needs.
-- For a production installation, see below [High Availability](#high-availability) section.
-- For a non-production installation, see below [Standalone](#standalone) section for additional details.
-
-{{% alert title="Note" color="warning" %}}
-When deploying Kyverno to certain Kubernetes platforms such as EKS, AKS, or OpenShift; or when using certain GitOps tools such as ArgoCD, additional configuration options may be needed or recommended. See the [Platform-Specific Notes](platform-notes.md) section for additional details.
-{{% /alert %}}
+### High Availability Installation
 
-After Kyverno is installed, you may choose to also install the Kyverno [Pod Security Standard policies](../../pod-security.md), an optional chart containing the full set of Kyverno policies which implement the Kubernetes [Pod Security Standards](https://kubernetes.io/docs/concepts/security/pod-security-standards/).
+Use Helm to create a Namespace and install Kyverno in a highly-available configuration.
 
 ```sh
-helm install kyverno-policies kyverno/kyverno-policies -n kyverno
+helm install kyverno kyverno/kyverno -n kyverno --create-namespace \
+--set admissionController.replicas=3 \
+--set backgroundController.replicas=2 \
+--set cleanupController.replicas=2 \
+--set reportsController.replicas=2
 ```
 
-### High Availability
-
-The Helm chart is the recommended method of installing Kyverno in a production-grade, highly-available fashion as it provides all the necessary Kubernetes resources and configuration options to meet most production needs including platform-specific controls.
-
 Since Kyverno is comprised of different controllers where each is contained in separate Kubernetes Deployments, high availability is achieved on a per-controller basis. A default installation of Kyverno provides four separate Deployments each with a single replica. Configure high availability on the controllers where you need the additional availability. Be aware that multiple replicas do not necessarily equate to higher scale or performance across all controllers. Please see the [high availability page](../high-availability/_index.md) for more complete details.
 
 The Helm chart offers parameters to configure multiple replicas for each controller. For example, a highly-available, complete deployment of Kyverno would consist of the following values.
@@ -52,12 +44,11 @@ The Helm chart offers parameters to configure multiple replicas for each control
 admissionController:
   replicas: 3
 backgroundController:
-  replicas: 2
+  replicas: 3
 cleanupController:
-  replicas: 2
+  replicas: 3
 reportsController:
-  replicas: 2
-
+  replicas: 3
 ```
 
 For all of the available values and their defaults, please see the Helm chart [README](https://github.com/kyverno/kyverno/tree/release-1.10/charts/kyverno). You should carefully inspect all available chart values and their defaults to determine what overrides, if any, are necessary to meet the particular needs of your production environment.
@@ -70,30 +61,24 @@ By default, the Kyverno Namespace will be excluded using a namespaceSelector con
 
 See also the [Namespace selectors](customization.md#namespace-selectors) section and especially the [Security vs Operability](_index.md#security-vs-operability) section.
 
-Use Helm to create a Namespace and install Kyverno in a highly-available configuration.
-
-```sh
-helm install kyverno kyverno/kyverno -n kyverno --create-namespace \
---set admissionController.replicas=3 \
---set backgroundController.replicas=2 \
---set cleanupController.replicas=2 \
---set reportsController.replicas=2
-```
+## Platform Specific Settings
 
-### Standalone
+When deploying Kyverno to certain Kubernetes platforms such as EKS, AKS, or OpenShift; or when using certain GitOps tools such as ArgoCD, additional configuration options may be needed or recommended. See the [Platform-Specific Notes](platform-notes.md) section for additional details.
 
-A standalone installation of Kyverno is suitable for lab, test/dev, or small environments typically associated with non-production. It configures a single replica for each Kyverno Deployment and omits many of the production-grade components.
+### Pre-Release Installations (RC)
 
-Use Helm to create a Namespace and install Kyverno.
+To install pre-release versions, such as `alpha`, `beta`, and `rc` (release candidates) versions, add the `--devel` switch to Helm:
 
 ```sh
-helm install kyverno kyverno/kyverno -n kyverno --create-namespace
+helm install kyverno kyverno/kyverno -n kyverno --create-namespace --devel
 ```
 
-To install pre-releases, add the `--devel` switch to Helm.
+## Install Pod Security Policies via Helm
+
+After Kyverno is installed, you may choose to also install the Kyverno [Pod Security Standard policies](../../pod-security.md), an optional chart containing the full set of Kyverno policies which implement the Kubernetes [Pod Security Standards](https://kubernetes.io/docs/concepts/security/pod-security-standards/).
 
 ```sh
-helm install kyverno kyverno/kyverno -n kyverno --create-namespace --devel
+helm install kyverno-policies kyverno/kyverno-policies -n kyverno
 ```
 
 ## Install Kyverno using YAMLs

diff --git a/content/en/support/nirmata/_index.md b/content/en/support/nirmata/_index.md
@@ -5,33 +5,19 @@ description: "Kubernetes Policy and Governance from the creators of Kyverno"
 type: docs
 ---
 
-
 [Nirmata](https://nirmata.com/) is the creator of Kyverno and offers several commercial solutions for Kubernetes policy and governance for platform and operations teams.
 
-### Nirmata for Kyverno Open Source
-
-[Nirmata for Kyverno Open Source](https://info.nirmata.com/hubfs/product/nirmata-kyverno-oss-consulting.pdf) is ideal for open source savvy users looking to protect and grow their investment in Kyverno. It includes:
-
-* Use Kyverno OSS or your own fork
-* Get 24x7 emergency support
-* Collaborate via email or a private messaging channel
-* 24 consulting hours per quarter for
-  * Best practices assessment
-  * Policy authoring
-  * Policy optimizations
-  * Upgrade assistance
-  * Custom trainings & workshops
-
-### Nirmata Enterprise for Kyverno
+### Nirmata Enterprise for Kyverno (N4K)
 
 [Nirmata Enterprise for Kyverno](https://nirmata.com/nirmata-enterprise-for-kyverno/) is designed for savvy platform engineering teams who are looking to save time and costs, and for peace of mind for operating Kyverno. It includes:
 
-* Kyverno LTS for long term support with compatibility testing, CVE and critical fix SLAs
-* Kyverno engine health and lifecycle management
-* Policy data adapters for fast in-cluster processing
-* Curated policy sets covering all major security concerns
+* Drop-in compatibility with Kyverno OSS
+* Long Term compatibility Support (LTS) across Kyverno and Kubernetes ([support matrix](shttps://docs.nirmata.io/docs/n4k/release-compatibility-matrix/)).
+* SLAs for CVE and critical fixes
+* etcd offload for improved performance
+* Curated policy sets covering security and operations needs
 * Quarterly trainings, assessments, and upgrade assist
-* Custom policy workshops
+* Custom policy authoring support & workshops
 
 {{% videos %}}
 {{< youtube id="LvZ66a9UUNM" start="0" class="video" >}}
@@ -41,23 +27,17 @@ type: docs
 
 [Nirmata Policy Manager](https://nirmata.com/nirmata-cloud-native-policy-manager/) provides centralized visibility and governance across fleets of clusters. It includes:
 
-* All Nirmata Enterprise for Kyverno features
-* Intuitive dashboards for policy reports
-* Role-based access controls for teams
-* Assign ownership of violations
-* OIDC and SAML integration
+* All N4K features
+* Centralized reporting across clusters and clouds
+* Role-based access controls for teams with OIDC and SAML
+* Auto-assign ownership of violations to teams
 * Customizable alerting and notifications
+* DevSecOps Collaboration Workflows e.g., exception management
+* Auto-remediation with GitOps integrations
+* Pipeline scanning and integrations
+* Continuous Compliance
 * CIS Kubernetes Benchmarks
-* Built-in compliance standards for:
-  * Pod Security Standards
-  * Workload Security
-  * Best practices
-  * RBAC configuration
-  * Multi-tenancy
-  * Supply Chain Security
-* Custom compliance standards with policy mappings
-* Continuous Compliance reporting
-
-### Kyverno Training
-
-Nirmata offers expert training and custom workshops for teams looking at accelerating their cloud-native journey. Reach out at: https://nirmata.com/contact-us/.
+
+### Kyverno Training & Support
+
+Nirmata offers expert training and custom workshops for custom support for teams looking at accelerating their cloud-native journey. Reach out at: https://nirmata.com/contact-us/.
Original file line number	Diff line number	Diff line change
Expand Up		@@ -77,4 +77,4 @@ Multiple replicas configured for the cleanup controller can be used for both ava

		## Installing Kyverno in HA mode

		The Helm chart is the recommended method of installing Kyverno in a production-grade, highly-available fashion as it provides all the necessary Kubernetes resources and configuration options to meet most production needs. For more information on installation of Kyverno in high availability, see the corresponding [installation section](../installation/methods.md#high-availability).
		The Helm chart is the recommended method of installing Kyverno in a production-grade, highly-available fashion as it provides all the necessary Kubernetes resources and configuration options to meet most production needs. For more information on installation of Kyverno in high availability, see the corresponding [installation section](../installation/methods.md#high-availability-installation).