feat: update architecture

Signed-off-by: ShutingZhao <[email protected]>

community/assessments/projects/kyverno/self-assessment.md

@@ -74,8 +74,8 @@ Kyverno's security, where to find existing security documentation, Kyverno plans
 security, and general overview of Kyverno security practices, both for development of
 Kyverno as well as security of Kyverno.
 
-This document provides the CNCF SIG-Security with an initial understanding of Kyverno
-to assist in a joint-review, necessary for projects under incubation.  Taken
+This document provides the CNCF TAG-Security with an initial understanding of Kyverno
+to assist in a joint-review, necessary for projects under incubation. Taken
 together, this document and the joint-review serve as a cornerstone for if and when
 Kyverno seeks graduation and is preparing for a security audit.
 
@@ -86,51 +86,70 @@ The following diagram shows the logical architecture for Kyverno. Each major com
 
 ![Kyverno Logical Architecture](images/kyverno-architecture.png)
 
-### Webhook
+### Admission Controller
 
-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.
+The `Admission Controller` 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.
 
-The `Webhook` also creates and updates `GenerateRequest` and `PolicyChangeRequest` resources to trigger updates via other Kyverno controllers.
+The `Admission Controller` also creates and updates `UpdateRequest`, `ClusterEphemeralReport` and `EphemeralReport` resources to trigger updates via other Kyverno controllers.
 
-### Webhook Monitor
+### Cert Renewer
 
-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.
+On startup, Kyverno's `Cert Renewer` component generates a self-signed certificate (or uses a user-provided certificate) and stores it in Kyverno managed secret. The component also renews the generated certificate 15 days before it becomes invalid.
 
-### Generate Controller
+### Webhook Controller
 
-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.
+On startup, Kyverno's `Webhook Controller` component auto-creates the webhook configurations required to register Kyverno as an admission webhook with the certificate fetched from Kyverno managed secret. The component also periodically monitors if Kyverno is receiving webhook events and recreates the certificate and webhook configurations if needed.
 
-### Policy Controller
+### Background Controller
 
-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.
+The `Background Controller` watches `UpdateRequest` resources and creates, updates, and deletes Kubernetes resources based on Kyverno [generate rules](https://kyverno.io/docs/writing-policies/generate/), or mutate existing Kubernetes resources based on [mutate exsiting rules](https://kyverno.io/docs/writing-policies/mutate/#mutate-existing-resources). The `Background Controller` also watches for changes in policy definitions to update generated resources.
+
+### Report Controllers
+
+The `Report Controller` merges `ClusterEphemeralReport` and `EphemeralReport` generated by `Admission Controller` to Kyverno [Policy Report](https://kyverno.io/docs/policy-reports/). The component performs periodic background scans on existing configurations and creates or updates policy reports based on changes and background scans. The `Report Controller` watches `ClusterEphemeralReport` and `EphemeralReport` resources and creates, updates, and delete Kyverno `Policy Report` resources. The `Policy Controller` also watches for changes in policies definitions to update policy reports.
 
 ## Physical Architecture
 
 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/)).  
 
 The Kyverno application consists of a:
-1. Service
-2. Deployment
-3. Roles
-4. Role Bindings
-5. Custom Resource Definitions
-6. Service account
+1. Deployments
+  - 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.
+  - Background controller (optional): The component responsible for processing of generate and mutate-existing rules.
+  - Reports controller (optional): The component responsible for handling of Policy Reports.
+  - Cleanup controller (optional): The component responsible for processing of Cleanup Policies.
+2. Services
+  - Services needed to receive webhook requests.
+  - Services needed for monitoring of metrics.
+3. ServiceAccounts
+  - One ServiceAccount per controller to segregate and confine the permissions needed for each controller to operate on the resources for which it is responsible.
+4. ConfigMaps
+  - ConfigMap for holding the main Kyverno configuration.
+  - ConfigMap for holding the metrics configuration.
+5. Secrets
+  - Secrets for webhook registration and authentication with the API server.
+6. Roles and Bindings
+  - Roles and ClusterRoles, Bindings and ClusterRoleBindings authorizing the various ServiceAccounts to act on the resources in their scope.
+7. Webhooks
+  - ValidatingWebhookConfigurations for receiving both policy and resource validation requests.
+  - MutatingWebhookConfigurations for receiving both policy and resource mutating requests.
+8. CustomResourceDefinitions
+  - CRDs which define the custom resources corresponding to policies, reports, and their intermediary resources.
+
 
 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.
 
 The diagram below shows the Kyverno physical architecture:
 
 ![Kyverno Physical Architecture](images/kyverno-physical-architecture.png)
 
-**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.
-
 ## Security functions and features
 
 Kyverno operates as an webhook admission controller. 
 
 ### Threat Modeling
 
-A threat model for admission controllers is published and maintained by the Kubernetes SIG Security:
+A threat model for admission controllers is published and maintained by the Kubernetes TAG Security:
   * [Kubernetes Admission Controller Threat Model](https://github.com/kubernetes/sig-security/blob/main/sig-security-docs/papers/admission-control/kubernetes-admission-control-threat-model.md)
   * [Blog post](https://kubernetes.io/blog/2022/01/19/secure-your-admission-controllers-and-webhooks/)
 
@@ -161,7 +180,7 @@ The [Kyverno installation YAMLs](https://github.com/kyverno/kyverno/blob/main/de
 
 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).
 
-### Communication Channels. 
+### Communication Channels
 
   * Internal: [GitHub Discussions](https://github.com/kyverno/kyverno/discussions)
   * Inbound: [#kyverno slack channel](https://kubernetes.slack.com/archives/CLGR9BJU9), [mailing list](https://groups.google.com/g/kyverno)