You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Kyverno helps secure and automates Kubernetes configurations using policies defined as Kubernetes custom resources. It operates as an Kubernetes admission controller and a command-line for off-cluster use.
47
+
Kyverno helps secure and automates configurations using policies defined as Kubernetes custom resources. It operates as a Kubernetes admission controller and provides command-line tools for off-cluster use. Additionally, Kyverno has been extended with new policy types (`ValidatingPolicy`, `ImageValidatingPolicy`, `MutatingPolicy`) that utilize CommonExpressionLanguage (CEL) to support non-Kubernetes resources, enabling policy validation for any JSON or YAML payload including Terraform files, Dockerfiles, cloud configurations, and service authorization requests.
48
48
49
49
### Background
50
50
@@ -55,28 +55,28 @@ While this is powerful, it also creates a few challenges:
55
55
2. Kubernetes configurations are not secure by default. Security and best practices need to be configured for workloads.
56
56
3. A resource's configurations is shared across organizational roles (dev-sec-ops) and chances of misconfigurations, or lack of proper configuration, increase as there is no clear ownership. Whether developers, operators, or security engineers are responsible for more `advanced` configuration settings may not be obvious.
57
57
58
-
### Goal
58
+
### Goals
59
59
60
-
The goal of the Kyverno project is to simplify Kubernetes configuration security and automate processes that otherwise require manual handoffs and coordination across Kubernetes cluster operators and developers.
60
+
The goal is to enforce security policies across Kubernetes resources to prevent insecure configurations and ensure compliance. User-defined YAML and CEL policies are enforced through admission control to prevent non-compliant Kubernetes resources from being created or modified, providing immediate feedback to users. If the admission controller is unavailable, CLI tools and background scanning provide alternative enforcement mechanisms to maintain security posture. Kyverno also provides automation through mutation and generation capabilities to automatically fix configurations and create required resources, simplifying security management. CLI tools extend this enforcement to non-Kubernetes resources like Terraform files and Dockerfiles.
61
61
62
62
### Non-goals
63
63
64
-
Kyverno is not a general purpose policy engine i.e. it is not designed for use outside of Kubernetes.
64
+
Kyverno is NOT designed to address Kubernetes security flaws, as it cannot protect against vulnerabilities in the Kubernetes API server or underlying infrastructure and Kyverno's policy enforcement may be bypassed if Kubernetes has a security flaw. Kyverno does not enforce security requirements that weren't explicitly defined, it enforces only the policies that users define. Kyverno does not replace Kubernetes RBAC, as RBAC controls access while Kyverno enforces policy compliance. Kyverno also does not replace Kubernetes' built-in policy controls like ValidatingAdmissionPolicies and MutatingAdmissionPolicies, but complements these native controls with additional features such as comprehensive reporting, exception management, and periodic scanning.
65
65
66
66
## Self-assessment use
67
67
68
-
This self-assessment is created by the Kyverno team to perform an internal analysis of the
69
-
project's security. It is not intended to provide a security audit of Kyverno, or
68
+
This self-assessment is created by the Kyverno team to perform an internal analysis of the
69
+
project's security. It is not intended to provide a security audit of Kyverno, or
70
70
function as an independent assessment or attestation of Kyverno's security health.
71
71
72
-
This document serves to provide Kyverno users with an initial understanding of
73
-
Kyverno's security, where to find existing security documentation, Kyverno plans for
74
-
security, and general overview of Kyverno security practices, both for development of
72
+
This document serves to provide Kyverno users with an initial understanding of Kyverno's
73
+
security, where to find existing security documentation, Kyverno plans for
74
+
security, and general overview of Kyverno security practices, both for development of
75
75
Kyverno as well as security of Kyverno.
76
76
77
-
This document provides the CNCF SIG-Security with an initial understanding of Kyverno
78
-
to assist in a joint-review, necessary for projects under incubation. Taken
79
-
together, this document and the joint-review serve as a cornerstone for if and when
77
+
This document provides the CNCF TAG-Security with an initial understanding of Kyverno
78
+
to assist in a joint-review, necessary for projects under incubation. Taken
79
+
together, this document and the joint-review serve as a cornerstone for if and when
80
80
Kyverno seeks graduation and is preparing for a security audit.
81
81
82
82
@@ -86,43 +86,79 @@ The following diagram shows the logical architecture for Kyverno. Each major com
Kyverno consists of four main controllers that work together to provide comprehensive policy management capabilities. Each controller handles specific aspects of policy processing, from admission control to background operations and cleanup tasks.
90
90
91
-
The `Webhook` component registers as a validating and mutating admission webhook and receives `AdmissionReview` requests from the API server to validate and mutate configuration changes, based on policies. Users can configure which namespaces and resources the webhooks will receive via command line options or the ConfigMap.
91
+
### Admission Controller
92
92
93
-
The `Webhook` also creates and updates `GenerateRequest` and `PolicyChangeRequest` resources to trigger updates via other Kyverno controllers.
93
+
* Receives AdmissionReview requests from the Kubernetes API server through validating and mutating webhooks.
94
+
* Processes validate, mutate, and image validating rules.
95
+
* Manages and renews certificates as Kubernetes Secrets for webhook use through the embedded Cert Renewer.
96
+
* Manages and configures webhook rules dynamically based on installed policies through the embedded Webhook Controller.
97
+
* Performs policy validation for the `Policy`, `ClusterPolicy`, `ValidatingPolicy`, `ImageValidatingPolicy`, `MutatingPolicy`, `GeneratingPolicy`, `DeletingPolicy`, and `PolicyException` custom resources.
98
+
* Processes Policy Exceptions.
99
+
* Generates `EphemeralReport` and `ClusterEphemeralReport` intermediary resources for further processing by the Reports Controller.
100
+
* Generates `UpdateRequest` intermediary resources for further processing by the Background Controller.
94
101
95
-
### Webhook Monitor
102
+
### Reports Controller
96
103
97
-
On startup, Kyverno's `Webhook Monitor` component generates a self-signed certificate (or uses a user-provided certificate) and auto-creates the webhook configurations required to register Kyverno as an admission webhook. The component also periodically monitors if Kyverno is receiving webhook events and recreates the certificate and webhook configurations if needed.
104
+
* Responsible for creation and reconciliation of the final `PolicyReport` and `ClusterPolicyReport` custom resources.
105
+
* Performs background scans and generates, processes, and converts `EphemeralReport` and `ClusterEphemeralReport` intermediary resources into the final policy report resources.
98
106
99
-
### Generate Controller
107
+
### Background Controller
100
108
101
-
The `Generate Controller` watches `GenerateRequest` resources and creates, updates, and deletes Kubernetes resources based on Kyverno [generate rules](https://kyverno.io/docs/writing-policies/generate/). The `Generate Controller` also watches for changes in policy definitions to update generated resources.
109
+
* Processes generate and mutate-existing rules of the `Policy` or `ClusterPolicy`, and the mutate-existing functionality of the `MutatingPolicy` and `GeneratingPolicy`.
110
+
* Processes policy add, update, and delete events.
111
+
* Processes and generates `UpdateRequest` intermediary resources to generate or mutate the final resource.
112
+
* Generates `EphemeralReport` and `ClusterEphemeralReport` intermediary resources for further processing by the Reports Controller.
102
113
103
-
### Policy Controller
114
+
### Cleanup Controller
104
115
105
-
The `Policy Controller` performs periodic background scans on existing configurations and creates or updates policy reports based on changes and background scans. The `Policy Controller` watches `ReportChangeRequest` resources and creates, updates, and delete Kyverno [Policy Report](https://kyverno.io/docs/policy-reports/) resources. The `Policy Controller` also watches for changes in policies definitions to update policy reports.
116
+
* Processes `CleanupPolicy` and `DeletingPolicy` resources.
117
+
* Performs policy validation for the CleanupPolicy and ClusterCleanupPolicy custom resources through a webhook server.
118
+
* Reconciles its webhook through a webhook controller.
119
+
* Manages and renews certificates as Kubernetes Secrets for use in the webhook.
120
+
* Creates and reconciles CronJobs used as the mechanism to trigger cleanup.
121
+
* Handles the cleanup by deleting resources from the Kubernetes API.
106
122
107
123
## Physical Architecture
108
124
109
-
Kyverno can be installed using a [Helm chart](https://artifacthub.io/packages/helm/kyverno/kyverno) or YAML files (see [installation doc](https://kyverno.io/docs/installation/)).
110
-
111
-
The Kyverno application consists of a:
112
-
1. Service
113
-
2. Deployment
114
-
3. Roles
115
-
4. Role Bindings
116
-
5. Custom Resource Definitions
117
-
6. Service account
118
-
119
-
When Kyverno runs, it will check for a named `Secret` with a certificate to use for webhook registration. If the secret does not exist, Kyverno will generate a self-signed certificate and store it in the secret. Kyverno will then generate or update the mutating and validating webhook configurations.
125
+
Kyverno can be installed using a [Helm chart](https://artifacthub.io/packages/helm/kyverno/kyverno) or YAML files (see [installation doc](https://kyverno.io/docs/installation/)).
120
126
121
127
The diagram below shows the Kyverno physical architecture:
**NOTE:** Currently Kyverno runs as one multi-instance (HA) `Pod` managed by a single `Deployment`. In the future the different controllers may be packaged in separate deployments to allow flexibility in scaling and tuning each component.
131
+
A standard Kyverno installation consists of a number of different components, some of which are optional:
132
+
133
+
**Deployments**
134
+
* Admission controller (required): The main component of Kyverno which handles webhook callbacks from the API server for verification, mutation, Policy Exceptions, and the processing engine.
135
+
* Background controller (optional): The component responsible for processing of generate and mutate-existing rules.
136
+
* Reports controller (optional): The component responsible for handling of Policy Reports.
137
+
* Cleanup controller (optional): The component responsible for processing of Cleanup Policies and Deleting Policies.
138
+
139
+
**Services**
140
+
* Services needed to receive webhook requests.
141
+
* Services needed for monitoring of metrics.
142
+
143
+
**ServiceAccounts**
144
+
* One ServiceAccount per controller to segregate and confine the permissions needed for each controller to operate on the resources for which it is responsible.
145
+
146
+
**ConfigMaps**
147
+
* ConfigMap for holding the main Kyverno configuration.
148
+
* ConfigMap for holding the metrics configuration.
149
+
150
+
**Secrets**
151
+
* Secrets for webhook registration and authentication with the API server.
152
+
153
+
**Roles and Bindings**
154
+
* Roles and ClusterRoles, Bindings and ClusterRoleBindings authorizing the various ServiceAccounts to act on the resources in their scope.
155
+
156
+
**Webhooks**
157
+
* ValidatingWebhookConfigurations for receiving both policy and resource validation requests.
158
+
* MutatingWebhookConfigurations for receiving both policy and resource mutating requests.
159
+
160
+
**CustomResourceDefinitions**
161
+
* CRDs which define the custom resources corresponding to policies, reports, and their intermediary resources.
126
162
127
163
## Security functions and features
128
164
@@ -145,7 +181,7 @@ Kyverno does not currently document meeting particular compliance standards.
145
181
146
182
## Secure development practices
147
183
148
-
The Kyverno project follows established CNCF and OSS best practices for code development and delivery:
184
+
The Kyverno project follows established CNCF and OSS best practices for code development and delivery.
149
185
150
186
### Development Pipeline
151
187
@@ -157,7 +193,7 @@ The [Kyverno container images](https://github.com/orgs/kyverno/packages) are hos
157
193
158
194
The [Kyverno Helm chart](https://artifacthub.io/packages/helm/kyverno/kyverno) is hosted in ArtifactHub. There is a pending issue to to sign the Helm Chart using Sigstore Cosign (https://github.com/kyverno/kyverno/issues/2758).
159
195
160
-
The [Kyverno installation YAMLs](https://github.com/kyverno/kyverno/blob/main/definitions/install.yaml) are hosted in the GitHub repository.
196
+
The [Kyverno installation YAMLs](https://github.com/kyverno/kyverno/blob/main/config/install-latest-testing.yaml) are hosted in the GitHub repository.
161
197
162
198
A Software Bill of Materials (SBOM) is produced and made available for each release (https://main.kyverno.io/docs/security/#fetching-the-sbom-for-kyverno).
163
199
@@ -187,9 +223,9 @@ All Kyverno security related issues (both fixes and enhancements) are labeled wi
### [CII Best Practices](https://www.coreinfrastructure.org/programs/best-practices-program/)
226
+
### [CII Best Practices](https://www.bestpractices.dev/)
191
227
192
-
The Kyverno project has adopted the OSSF/Scorecard and is tracking progress in [issue #2617](https://github.com/kyverno/kyverno/issues/2617).
228
+
The Kyverno project has passed the OpenSSF Scorecard check and is actively working towards achieving silver/gold level certification. Progress is being tracked via [issue 10908](https://github.com/kyverno/kyverno/issues/10908).
Security reviewers: Justin Cappos @JustinCappos, Marina Moore @mnm678, Constanze Röedig @entlein, Camila Vilarinho @camilaavilarinho, and Victor Lu @victorjunlu
7
+
8
+
Project security lead: Hung-Ying Tai @hydai
9
+
10
+
Project team: Hung-Ying Tai @hydai, Meng-Han Lee @dm4
The project has built a reasonably secure system with appropriate security controls. However, the security limitations, testing requirements, and benefits could be better communicated to users. Additional focus on going above common recommendations would strengthen the project's security posture. The assessment team appreciates WasmEdge's cooperation in answering questions and clarifying the self-assessment document.
18
+
19
+
## Recommendations
20
+
21
+
### CNCF recommendations
22
+
23
+
* Improve documentation translation across languages, especially into English
24
+
* Consider adopting CNCF security best practices for software supply chain attestations (in-toto/SLSA)
25
+
* Explore integration with CNCF security projects like SPIFFE/SPIRE for workload identity
26
+
27
+
### Project recommendations
28
+
29
+
1. The document needs to clearly say about whether you add a formal verifier for your runtime. What do other runtimes provide to validate they are correctly implementing the WASM spec?
30
+
2. Have you done validation of how you’re using WASI, what interfaces you are providing, their security, etc.? For example, as an illustrative example, can you explain how you’ve validated that your \--dir interface doesn’t have path traversal vulnerabilities? What is the guidance you give to users who want to use this interface to make sure they do so securely? Are they free to add symlinks / mount file systems, etc. into that part of the directory namespace, etc.?
31
+
3. Does the fact that WASI isn’t portable and has a lot of undefined behavior give users any security concerns?
32
+
4. Secure the process of distributing updates of your core functionality on the device. [https://uptane.org/](https://uptane.org/)
33
+
or [https://theupdateframework.com/](https://theupdateframework.com/)
34
+
5. Create attestations for the software running on the edge device using best practices. This should include software supply chain attestations (in-toto / SLSA, etc.). [https://github.com/in-toto/in-toto](https://github.com/in-toto/in-toto)[https://datatracker.ietf.org/group/scitt/about/](https://datatracker.ietf.org/group/scitt/about/)[https://slsa.dev/](https://slsa.dev/)
35
+
6. Please explain clearly about how one would use things like non-human identities, monitoring, security filtering, etc. Is everything completely compatible with SPIFFE/SPIRE? Are there any differences in use in comparison to e.g.: [https://wasmcloud.com/blog/2025-03-04-why-were-adopting-spiffe-for-webassembly-workload-identity/](https://wasmcloud.com/blog/2025-03-04-why-were-adopting-spiffe-for-webassembly-workload-identity/)
36
+
7. What should users be thinking about with respect to data residency and jurisdictional constraints when processing sensitive data in WasmEdge? How does being at the edge change this equation?
37
+
8. Please, add to the main body of the document (and on github)
38
+
\- how you ensure continuous verification/testing of the WASM specification of all components (the Verifier, the Loader, the Engine \- every main component in scope of WasmEdge).
39
+
Example:
40
+
Where Side Channel Attacks are tested against and how the code verifiably written in “side-channel resistant” way. [https://github.com/WebAssembly/constant-time/blob/main/proposals/constant-time/Overview.md](https://github.com/WebAssembly/constant-time/blob/main/proposals/constant-time/Overview.md)
41
+
Can you add to the document for each major attack-class: how is it being tested/fuzzed and can you show in your repo/artifacts, and comment how you’d resolve any failures.
42
+
9. Ensure that it is clear why you are having failures on tests when building the code. Your code is being pushed to production regardless. Why is this appropriate?
43
+
10. The project could benefit from more effort to explain the security aspects of their design to their userbase.
44
+
11. The project would benefit from putting a link (and also a github-badge) in the main-README that goes directly to the security testing/definitions. Fixed by [https://github.com/WasmEdge/WasmEdge/pull/4216](https://github.com/WasmEdge/WasmEdge/pull/4216)
45
+
46
+
### Additional recommendations
47
+
48
+
* Provide clearer guidance on data residency and jurisdictional constraints for sensitive data processing
0 commit comments