feat: add ESO threat model (#2308)

* feat: add ESO threat model

Signed-off-by: Moritz Johner <beller.moritz@googlemail.com>

* Update docs/guides/threat-model.md

Co-authored-by: Gustavo Fernandes de Carvalho <gusfcarvalho@gmail.com>
Signed-off-by: Moritz Johner <moolen@users.noreply.github.com>

* feat: add controls to disable CRDs C05

Signed-off-by: Moritz Johner <beller.moritz@googlemail.com>

---------

Signed-off-by: Moritz Johner <beller.moritz@googlemail.com>
Signed-off-by: Moritz Johner <moolen@users.noreply.github.com>
Co-authored-by: Gustavo Fernandes de Carvalho <gusfcarvalho@gmail.com>

docs/api/components.md

@@ -16,3 +16,10 @@ These features are optional but highly recommended. You can disable them with he
 
 <br/>
 ![Component Overview](../pictures/diagrams-component-overview.png)
+
+
+### TLS Bootstrap
+
+Cert-controller is responsible for (1) generating TLS credentials which will be used by the webhook component and (2) injecting the certificate as `caBundle` into `Kind=CustomResourceDefinition` for conversion webhooks and `Kind=ValidatingWebhookConfiguration` for validating admission webhook. The TLS credentials are stored in a `Kind=Secret` which is consumed by the webhook.
+
+![](../pictures/eso-threat-model-TLS%20Bootstrap.drawio.png){: style="width:70%;"}

docs/guides/security-best-practices.md

@@ -1,33 +1,100 @@
 # Security Best Practices
 
-The purpose of this document is to provide a set of best practices for securing External Secrets Operator. These best practices are designed to reduce the risk of a successful attack against the operator or the Kubernetes cluster it integrates with.
+The purpose of this document is to outline a set of best practices for securing the External Secrets Operator (ESO). These practices aim to mitigate the risk of successful attacks against ESO and the Kubernetes cluster it integrates with.
+
+## Security Functions and Features
+
+### 1. Namespace Isolation
+
+To maintain security boundaries, ESO ensures that namespaced resources like `SecretStore` and `ExternalSecret` are limited to their respective namespaces. The following rules apply:
+
+1. `ExternalSecret` resources must not have cross-namespace references of `Kind=SecretStore` or `Kind=Secret` resources
+2. `SecretStore` resources must not have cross-namespace references of `Kind=Secret` or others
+
+For cluster-wide resources like `ClusterSecretStore` and `ClusterExternalSecret`, exercise caution since they have access to Secret resources across all namespaces. Minimize RBAC permissions for administrators and developers to the necessary minimum. If cluster-wide resources are not required, it is recommended to disable them.
+
+### 2. Configure ClusterSecretStore match conditions
+
+Utilize the ClusterSecretStore resource to define specific match conditions using `namespaceSelector` or an explicit namespaces list. This restricts the usage of the `ClusterSecretStore` to a predetermined list of namespaces or a namespace that matches a predefined label. Here's an example:
+
+```yaml
+apiVersion: external-secrets.io/v1beta1
+kind: ClusterSecretStore
+metadata:
+  name: fake
+spec:
+  conditions:
+    namespaceSelector:
+      app: frontend
+```
+
+### 3. Selectively Disable Reconciliation of Cluster-Wide Resources
+
+ESO allows you to selectively disable the reconciliation of cluster-wide resources such as `ClusterSecretStore`, `ClusterExternalSecret`, and `PushSecret`. You can disable the installation of CRDs in the Helm chart or disable reconciliation in the core-controller using the following options:
+
+To disable CRD installation:
+
+```yaml
+# disable cluster-wide resources & push secret
+crds:
+  createClusterExternalSecret: false
+  createClusterSecretStore: false
+  createPushSecret: false
+```
+
+To disable reconciliation in the core-controller:
+
+```
+--enable-cluster-external-secret-reconciler
+--enable-cluster-store-reconciler
+```
+
+### 4. Implement Namespace-Scoped Installation
+
+To further enhance security, consider installing ESO into a specific namespace with restricted access to only that namespace's resources. This prevents access to cluster-wide secrets. Use the following Helm values to scope the controller to a specific namespace:
+
+```yaml
+# If set to true, create scoped RBAC roles under the scoped namespace
+# and implicitly disable cluster stores and cluster external secrets
+scopedRBAC: true
+
+# Specify the namespace where external secrets should be reconciled
+scopedNamespace: my-namespace
+```
 
 ## Pod Security
 
-The External Secrets Operator Pods have been configured to adhere to [Pod Security Standards](https://kubernetes.io/docs/concepts/security/pod-security-standards/) `restricted` profile which establish a great security posture by following current Pod hardening best practices such as the [NSA Kubernetes Hardening Guide](https://media.defense.gov/2022/Aug/29/2003066362/-1/-1/0/CTR_KUBERNETES_HARDENING_GUIDANCE_1.2_20220829.PDF).
+The Pods of the External Secrets Operator have been configured to meet the [Pod Security Standards](https://kubernetes.io/docs/concepts/security/pod-security-standards/), specifically the restricted profile. This configuration ensures a strong security posture by implementing recommended best practices for hardening Pods, including those outlined in the [NSA Kubernetes Hardening Guide](https://media.defense.gov/2022/Aug/29/2003066362/-1/-1/0/CTR_KUBERNETES_HARDENING_GUIDANCE_1.2_20220829.PDF).
 
-These measures provide a secure and robust environment for the External Secrets Operator to operate within. They have been set as default since `v0.8.2` and should not be changed to conform with the principle of least privilege.
+By adhering to these standards, the External Secrets Operator benefits from a secure and resilient operating environment. The restricted profile has been set as the default configuration since version `v0.8.2`, and it is recommended to maintain this setting to align with the principle of least privilege.
 
-## RBAC
+## Role-Based Access Control (RBAC)
 
-The External Secrets Operator runs with highly privileged access to your Kubernetes cluster. Due to it's purpose it is able to read and write to all secrets across all namespaces.
+The External Secrets Operator operates with elevated privileges within your Kubernetes cluster, allowing it to read and write to all secrets across all namespaces. It is crucial to properly restrict access to ESO resources such as `ExternalSecret` and `SecretStore` where necessary. This is particularly important for cluster-scoped resources like `ClusterExternalSecret` and `ClusterSecretStore`. Unauthorized tampering with these resources by an attacker could lead to unauthorized access to secrets or potential data exfiltration from your system.
 
-Make sure to restrict access to ESO resources like `ExternalSecret`, `SecretStore` etc. where appropriate. This is particularly important for cluster-scoped resources like `ClusterExternalSecret` and `ClusterSecretStore`. If an attacker is able to tamper with these resources he could potentially get unauthorized access to secrets or may be able to exfiltrate data out of your system.
+In most scenarios, the External Secrets Operator is deployed cluster-wide. However, if you prefer to run it on a per-namespace basis, you can scope it to a specific namespace using the `scopedRBAC` and `scopedNamespace` options in the helm chart.
 
-In most scenarios the External Secrets Operator runs cluster-wide. If this is not desired and you want to run it per-namespace, you can scope it to a particular namespace, see `scopedRBAC` and `scopedNamespace` in the helm chart.
+To ensure a secure RBAC configuration, consider the following checklist:
 
-A short checklist for you to walk through:
+* Restrict access to execute shell commands (pods/exec) within the External Secrets Operator Pod.
+* Restrict access to (Cluster)ExternalSecret and (Cluster)SecretStore resources.
+* Limit access to aggregated ClusterRoles (view/edit/admin) as needed.
+* If necessary, deploy ESO with scoped RBAC or within a specific namespace.
 
-* restrict access to execute a shell `pods/exec` in External Secrets Operator Pod
-* restrict access to `(Cluster)ExternalSecret` and `(Cluster)SecretStore`
-* restrict access to [aggregated ClusterRoles](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#aggregated-clusterroles) `view/edit/admin` where needed
-* run ESO with scoped RBAC/Namespace if needed
+By carefully managing RBAC permissions and scoping the External Secrets Operator appropriately, you can enhance the security of your Kubernetes cluster.
 
+## Network Traffic and Security
 
-## Network Policy
+To ensure a secure network environment, it is recommended to restrict network traffic to and from the External Secrets Operator using `NetworkPolicies` or similar mechanisms. By default, the External Secrets Operator does not include pre-defined Network Policies.
 
-Network Traffic from/to the operator should be restricted using `NetworkPolicies` or similar. By default, External Secrets Operator does not provide Network Policies for you.
+To implement network restrictions effectively, consider the following steps:
 
+* Define and apply appropriate NetworkPolicies to limit inbound and outbound traffic for the External Secrets Operator.
+* Specify a "deny all" policy by default and selectively permit necessary communication based on your specific requirements.
+* Restrict access to only the required endpoints and protocols for the External Secrets Operator, such as communication with the Kubernetes API server or external secret providers.
+* Regularly review and update the Network Policies to align with changes in your network infrastructure and security requirements.
+
+It is the responsibility of the user to define and configure Network Policies tailored to their specific environment and security needs. By implementing proper network restrictions, you can enhance the overall security posture of the External Secrets Operator within your Kubernetes cluster.
 
 !!! danger "Data Exfiltration Risk"
 
@@ -35,43 +102,59 @@ Network Traffic from/to the operator should be restricted using `NetworkPolicies
     It is advised to create tight NetworkPolicies and use a policy engine such as kyverno to prevent data exfiltration.
 
 
-You should restrict access in **egress** direction:
+### Outbound Traffic Restrictions
+
+#### Core Controller
+
+Restrict outbound traffic from the core controller component to the following destinations:
+
+* `kube-apiserver`: The Kubernetes API server.
+* Secret provider (e.g., AWS, GCP): Whenever possible, use private endpoints to establish secure and private communication.
+
+#### Webhook
+
+* Restrict outbound traffic from the webhook component to the `kube-apiserver`.
+
+#### Cert Controller
 
-* controller
-    * kube-apiserver
-    * secret provider (AWS, GCP, ...), where possible use private endpoints.
-* webhook
-    * kube-apiserver
-* cert-controller
-    * kube-apiserver
+* Restrict outbound traffic from the cert controller component to the `kube-apiserver`.
 
-Further, you also should restrict **ingress** traffic to ESO Pods:
 
-* controller
-    * `:8080` from you monitoring agent
-* cert-controller:
-    * `:8080` from you monitoring agent
-    * `:8081` from kubelet (healthz/readyz)
-* webhook:
-    * `:10250` from the kube-apiserver
-    * `:8080` from you monitoring agent
-    * `:8081` from kubelet (healthz/readyz)
+### Inbound Traffic Restrictions
+
+#### Core Controller
+
+* Restrict inbound traffic to the core controller component by allowing communication on port `8080` from your monitoring agent.
+
+#### Cert Controller
+
+* Restrict inbound traffic to the cert controller component by allowing communication on port `8080` from your monitoring agent.
+* Additionally, permit inbound traffic on port `8081` from the kubelet for health check endpoints (healthz/readyz).
+
+#### Webhook
+
+Restrict inbound traffic to the webhook component as follows:
+
+* Allow communication on port `10250` from the kube-apiserver.
+* Allow communication on port `8080` from your monitoring agent.
+* Permit inbound traffic on port `8081` from the kubelet for health check endpoints (healthz/readyz).
 
 ## Policy Engine Best Practices
 
-You should use a policy engine like [kyverno](http://kyverno.io/) or [OPA Gatekeeper](https://github.com/open-policy-agent/gatekeeper) to restrict changes made to ESO resources like `SecretStore` and `ExternalSecret`.
+To enhance the security and enforce specific policies for External Secrets Operator (ESO) resources such as SecretStore and ExternalSecret, it is recommended to utilize a policy engine like [Kyverno](http://kyverno.io/) or [OPA Gatekeeper](https://github.com/open-policy-agent/gatekeeper). These policy engines provide a way to define and enforce custom policies that restrict changes made to ESO resources.
 
 !!! danger "Data Exfiltration Risk"
 
     ESO could be used to exfiltrate data out of your cluster. You should disable all providers you don't need.
     Further, you should implement `NetworkPolicies` to restrict network access to known entities (see above), to prevent data exfiltration.
 
+Here are some recommendations to consider when configuring your policies:
 
-Here a couple of recommendations for you to consider:
+1. **Explicitly Deny Unused Providers**: Create policies that explicitly deny the usage of secret providers that are not required in your environment. This prevents unauthorized access to unnecessary providers and reduces the attack surface.
+2. **Restrict Access to Secrets**: Implement policies that restrict access to secrets based on specific conditions. For example, you can define policies to allow access to secrets only if they have a particular prefix in the `.spec.data[].remoteRef.key` field. This helps ensure that only authorized entities can access sensitive information.
+3. **Restrict `ClusterSecretStore` References**: Define policies to restrict the usage of ClusterSecretStore references within ExternalSecret resources. This ensures that the resources are properly scoped and prevent potential unauthorized access to secrets across namespaces.
 
-* explicitly deny usage of the providers you don't need
-* restrict access to secrets with/without a particular prefix in `.spec.data[].remoteRef.key`
-* restrict usage of a `(Cluster)SecretStore` reference in an ExternalSecret
+By leveraging a policy engine, you can implement these recommendations and enforce custom policies that align with your organization's security requirements. Please refer to the documentation of the chosen policy engine (e.g., Kyverno or OPA Gatekeeper) for detailed instructions on how to define and enforce policies for ESO resources.
 
 
 !!! note "Provider Validation Example Policy"
@@ -86,20 +169,27 @@ Here a couple of recommendations for you to consider:
 
 ## Regular Patches
 
-Regularly patch and update all software components of ESO and the cluster to ensure that known vulnerabilities are addressed. Use automated patching and updating tools to ensure that all components are kept up-to-date.
+To maintain a secure environment, it is crucial to regularly patch and update all software components of External Secrets Operator and the underlying cluster. By doing so, known vulnerabilities can be addressed, and the overall system's security can be improved. Here are some recommended practices for ensuring timely updates:
+
+1. **Automated Patching and Updating**: Utilize automated patching and updating tools to streamline the process of keeping software components up-to-date
+2. **Regular Update ESO**: Stay informed about the latest updates and releases provided for ESO. The development team regularly releases updates to improve stability, performance, and security. Please refer to the [Stability and Support](../../introduction/stability-support.md) documentation for more information on the available updates
+3. **Cluster-wide Updates**: Apart from ESO, ensure that all other software components within your cluster, such as the operating system, container runtime, and Kubernetes itself, are regularly patched and updated.
 
-We provide regular updates to ESO, see [Stability and Support](../../introduction/stability-support.md).
+By adhering to a regular patching and updating schedule, you can proactively mitigate security risks associated with known vulnerabilities and ensure the overall stability and security of your ESO deployment.
 
 ## Verify Artefacts
 
 ### Verify Container Images
 
-External Secrets Operator container images are signed using Cosign and the keyless signing feature. To verify the container image, follow the steps below.
+The container images of External Secrets Operator are signed using Cosign and the keyless signing feature. To ensure the authenticity and integrity of the container image, you can follow the steps outlined below:
+
 
 ```sh
+# Retrieve Image Signature
 $ crane digest ghcr.io/external-secrets/external-secrets:v0.8.1
 sha256:36e606279dbebac51b4b9300b9fa85e8c08c1c673ba3ecc38af1402a0b035554
 
+# verify signature
 $ COSIGN_EXPERIMENTAL=1 cosign verify ghcr.io/external-secrets/external-secrets@sha256:36e606279dbebac51b4b9300b9fa85e8c08c1c673ba3ecc38af1402a0b035554 | jq
 
 # ...
@@ -137,12 +227,14 @@ $ COSIGN_EXPERIMENTAL=1 cosign verify ghcr.io/external-secrets/external-secrets@
 ]
 ```
 
-Note that the important fields to verify in the output are `optional.Issuer` and `optional.Subject`. If Issuer and Subject do not match the values shown above, the image is not legit and should not be used.
+In the output of the verification process, pay close attention to the `optional.Issuer` and `optional.Subject` fields. These fields contain important information about the image's authenticity. Verify that the values of Issuer and Subject match the expected values for the ESO container image. If they do not match, it indicates that the image is not legitimate and should not be used.
+
+By following these steps and confirming that the Issuer and Subject fields align with the expected values for the ESO container image, you can ensure that the image has not been tampered with and is safe to use.
 
 
-### Verify Provenance
+### Verifying Provenance
 
-External Secrets Operator creates and attests to the provenance of its builds using the [SLSA standard](https://slsa.dev/provenance/v0.1). The attested provenance may be verified using the cosign tool.
+The External Secrets Operator employs the [SLSA](https://slsa.dev/provenance/v0.1) (Supply Chain Levels for Software Artifacts) standard to create and attest to the provenance of its builds. Provenance verification is essential to ensure the integrity and trustworthiness of the software supply chain. This outlines the process of verifying the attested provenance of External Secrets Operator builds using the cosign tool.
 
 ```sh
 $ COSIGN_EXPERIMENTAL=1 cosign verify-attestation --type slsaprovenance ghcr.io/external-secrets/external-secrets:v0.8.1 | jq .payload -r | base64 --decode | jq
@@ -194,7 +286,7 @@ GitHub Workflow Ref: refs/heads/main
 
 ### Fetching SBOM
 
-An SBOM (Software Bill of Materials) in Software Package Data Exchange (SPDX) JSON format is attached to every External Secrets Operator image.  To download and verify the SBOM for a specific version, install Cosign and run:
+Every External Secrets Operator image is accompanied by an SBOM (Software Bill of Materials) in SPDX JSON format. The SBOM provides detailed information about the software components and dependencies used in the image. This technical documentation explains the process of downloading and verifying the SBOM for a specific version of External Secrets Operator using the Cosign tool.
 
 ```sh
 $ crane digest ghcr.io/external-secrets/external-secrets:v0.8.1

docs/guides/threat-model.md

@@ -0,0 +1,127 @@
+---
+hide:
+  - toc
+---
+
+## Background
+
+The External Secrets Operator is a Kubernetes Operator that seamlessly incorporates external secret management systems into Kubernetes. This Operator retrieves data from the external API and generates Kubernetes Secret resources using the corresponding secret values. This process occurs continuously in the background through regular polling of the external API. Consequently, whenever a secret undergoes changes in the external API, the corresponding Kubernetes Secret will also be updated accordingly.
+
+### Summary
+
+| Purpose             | Description                  |
+| ------------------- | ---------------------------- |
+| Intended Usage      | Sync Secrets into Kubernetes |
+| Data Classifiation  | Critical                     |
+| Highest Risk Impact | Organisation takeover        |
+
+### Components
+
+ESO comprises three main components: `webhook`, `cert controller` and a `core controller`. For more detailed information, please refer to the documentation on [components](../api/components.md).
+
+## Overview
+
+This section provides an overview of the security aspects of the External Secrets Operator (ESO) and includes information on assets, threats, and controls involved in its operation.
+
+The following diagram illustrates the security perspective of how ESO functions, highlighting the assets (items to protect), threats (potential risks), and controls (measures to mitigate threats).
+
+![Overview](../pictures/eso-threat-model-overview.drawio.png)
+
+### Scope
+
+For the purpose of this threat model, we assume an ESO installation using helm and default settings on a public cloud provider. It is important to note that the [Kubernetes SIG Security](https://github.com/kubernetes/community/tree/master/sig-security) team has defined an [Admission Control Threat Model](https://github.com/kubernetes/sig-security/blob/main/sig-security-docs/papers/admission-control/kubernetes-admission-control-threat-model.md), which is recommended reading for a better understanding of the security aspects that partially apply to External Secrets Operator.
+
+
+ESO utilizes the `ValidatingWebhookConfiguration` mechanism to validate `(Cluster)SecretStore` and `(Cluster)ExternalSecret` resources. However, it is essential to understand that this validation process does not serve as a security control mechanism. Instead, ESO performs validation by enforcing additional rules that go beyond the [CustomResourceDefinition OpenAPI v3 Validation schema](https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#validation).
+
+### Assets
+
+#### A01: Cluster-Level access to secrets
+
+The controller possesses privileged access to the `kube-apiserver` and is authorized to read and write secret resources across all namespaces within a cluster.
+
+#### A02: CRD and Webhook Write access
+
+The cert-controller component has read/write access to `ValidatingWebhookConfigurations` and `CustomResourceDefinitions` resources. This access is necessary to inject/modify the caBundle property.
+
+#### A03: secret provider access
+
+The `core-controller` component accesses a secret provider using user-supplied credentials. These credentials can be derived from environment variables, mounted service account tokens, files within the controller container, or fetched from the Kubernetes API (e.g., `Kind=Secret`). The scope of these credentials may vary, potentially providing full access to a cloud provider.
+
+#### A04: capability to modify resources
+
+The webhook component validates and converts ExternalSecret and SecretStore resources. The conversion webhook is essential for migrating resources from the old version `v1alpha1` to the new version `v1beta1`. The webhook component possesses the ability to modify resources during runtime.
+
+### Threats
+
+#### T01: Tampering with resources through MITM
+
+An adversary could launch a Man-in-the-Middle (MITM) attack to hijack the webhook pod, enabling them to manipulate the data of the conversion webhook. This could involve injecting malicious resources or causing a Denial-of-Service (DoS) attack. To mitigate this threat, a mutual authentication mechanism should be enforced for the connection between the Kubernetes API server and the webhook service to ensure that only authenticated endpoints can communicate.
+
+#### T02: Webhook DOS
+
+Currently, ESO generates an X.509 certificate for webhook registration without authenticating the kube-apiserver. Consequently, if an attacker gains network access to the webhook Pod, they can overload the webhook server and initiate a DoS attack. As a result, modifications to ESO resources may fail, and the ESO core controller may be impacted due to the unavailability of the conversion webhook.
+
+#### T03: Unauthorized access to cluster secrets
+
+An attacker can gain unauthorized access to secrets by utilizing the service account token of the ESO core controller Pod or exploiting software vulnerabilities. This unauthorized access allows the attacker to read secrets within the cluster, potentially leading to a cluster takeover.
+
+#### T04: unauthorized access to secret provider credentials
+
+An attacker can gain unauthorized access to credentials that provide access to external APIs storing secrets. If the credentials have overly broad permissions, this could result in an organization takeover.
+
+#### T05: data exfiltration through malicious resources
+
+An attacker can exfiltrate data from the cluster by utilizing maliciously crafted resources. Multiple attack vectors can be employed, e.g.:
+
+1. copying data from a namespace to an unauthorized namespace
+2. exfiltrating data to an unauthorized secret provider
+3. exfiltrating data through an authorized secret provider to a malicious provider account
+
+Successful data exfiltration can lead to intellectual property loss, information misuse, loss of customer trust, and damage to the brand or reputation.
+
+#### T06: supply chain attacks
+
+An attack can infiltrate the ESO container through various attack vectors. The following are some potential entry points, although this is not an exhaustive list. For a comprehensive analysis, refer to [SLSA Threats and mitigations](https://slsa.dev/spec/v0.1/threats) or [GCP software supply chain threats](https://cloud.google.com/software-supply-chain-security/docs/attack-vectors).
+
+1. Source Threats: Unauthorized changes or inclusion of vulnerable code in ESO through code submissions.
+2. Build Threats: Creation and distribution of malicious builds of ESO, such as in container registries, Artifact Hub, or Operator Hub.
+3. Dependency Threats: Introduction of vulnerable code into ESO dependencies.
+4. Deployment and Runtime Threats: Injection of malicious code through compromised deployment processes.
+
+#### T07: malicious workloads in eso namespace
+
+An attacker can deploy malicious workloads within the external-secrets namespace, taking advantage of the ESO service account with potentially cluster-wide privileges.
+
+
+### Controls
+
+#### C01: Network Security Policy
+
+Implement a NetworkPolicy to restrict traffic in both inbound and outbound directions on all networks. Employ a "deny all" / "permit by exception" approach for inbound and outbound network traffic. The specific network policies for the core-controller depend on the chosen provider. The webhook and cert-controller have well-defined sets of endpoints they communicate with. Refer to the [Security Best Practices](./security-best-practices.md) documentation for inbound and outbound network requirements.
+
+Please note that ESO does not provide pre-packaged network policies, and it is the user's responsibility to implement the necessary security controls.
+
+#### C02: Least Privilege RBAC
+
+Adhere to the principle of least privilege by configuring Role-Based Access Control (RBAC) permissions not only for the ESO workload but also for all users interacting with it. Ensure that RBAC permissions on provider side are appropriate according to your setup, by for example limiting which sensitive information a given credential can have access to. Ensure that  kubernetes RBAC are set up to grant access to ESO resources only where necessary. For example, allowing write access to `ClusterSecretStore`/`ExternalSecret` may be sufficient for a threat to become a reality.
+
+#### C03: Policy Enforcement
+
+Implement a Policy Engine such as Kyverno or OPA to enforce restrictions on changes to ESO resources. The specific policies to be enforced depend on the environment. Here are a few suggestions:
+
+1. (Cluster)SecretStore: Restrict the allowed secret providers, disallowing unused or undesired providers (e.g. Webhook).
+2. (Cluster)SecretStore: Restrict the permitted authentication mechanisms (e.g. prevent usage of `secretRef`).
+3. (Cluster)SecretStore: Enforce limitations on modifications to provider-specific fields relevant for security, such as `caBundle`, `caProvider`, `region`, `role`, `url`, `environmentType`, `identityId`, and `others`.
+4. ClusterSecretStore: Control the usage of `namespaceSelector`, such as forbidding or mandating the usage of the `kube-system` namespace.
+5. ClusterExternalSecret: Restrict the usage of `namespaceSelector`.
+
+Please note that ESO does not provide pre-packaged policies, and it is the user's responsibility to implement the necessary security controls.
+
+#### C04: Provider Access Policy
+
+Configure fine-grained access control on the HTTP endpoint of the secret provider to prevent data exfiltration across accounts or organizations. Consult the documentation of your specific provider (e.g.: [AWS Secrets Manager VPC Endpoint Policies](https://docs.aws.amazon.com/secretsmanager/latest/userguide/vpc-endpoint-overview.html), [GCP Private Service Connect](https://cloud.google.com/vpc/docs/private-service-connect), or [Azure Private Link](https://learn.microsoft.com/en-us/azure/key-vault/general/private-link-service)) for guidance on setting up access policies.
+
+#### C05: Entirely disable CRDs
+
+You should disable unused CRDs to narrow down your attack surface. Not all users require the use of `PushSecret`, `ClusterSecretStore` or `ClusterExternalSecret` resources.

docs/pictures/eso-threat-model.drawio

@@ -0,0 +1,209 @@
+<mxfile host="app.diagrams.net" modified="2023-06-08T07:50:48.059Z" agent="Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/113.0.0.0 Safari/537.36" etag="rknZ4nRD0hLUAzhrPp6X" version="21.3.7" type="device" pages="2">
+  <diagram name="Overview" id="Bc-KUSc10sxP7uZ9etOK">
+    <mxGraphModel dx="1388" dy="702" grid="1" gridSize="10" guides="1" tooltips="1" connect="1" arrows="1" fold="1" page="1" pageScale="1" pageWidth="827" pageHeight="1169" math="0" shadow="0">
+      <root>
+        <mxCell id="0" />
+        <mxCell id="1" parent="0" />
+        <mxCell id="-eq3P-sCqOfjKJ7X8hlF-10" value="" style="rounded=0;whiteSpace=wrap;html=1;fillColor=none;dashed=1;" parent="1" vertex="1">
+          <mxGeometry x="540" y="381.26" width="180" height="100" as="geometry" />
+        </mxCell>
+        <mxCell id="-eq3P-sCqOfjKJ7X8hlF-8" value="" style="rounded=0;whiteSpace=wrap;html=1;fillColor=none;dashed=1;" parent="1" vertex="1">
+          <mxGeometry x="200" y="740" width="320" height="100" as="geometry" />
+        </mxCell>
+        <mxCell id="-eq3P-sCqOfjKJ7X8hlF-7" value="" style="rounded=0;whiteSpace=wrap;html=1;fillColor=#dae8fc;dashed=1;strokeColor=#6c8ebf;" parent="1" vertex="1">
+          <mxGeometry x="110" y="550" width="700" height="100" as="geometry" />
+        </mxCell>
+        <mxCell id="-eq3P-sCqOfjKJ7X8hlF-14" value="conversion/&lt;br&gt;validating webhook" style="edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;exitX=0.164;exitY=-0.031;exitDx=0;exitDy=0;entryX=0.5;entryY=1;entryDx=0;entryDy=0;exitPerimeter=0;labelBackgroundColor=none;" parent="1" source="-eq3P-sCqOfjKJ7X8hlF-1" target="-eq3P-sCqOfjKJ7X8hlF-2" edge="1">
+          <mxGeometry x="0.1204" y="47" relative="1" as="geometry">
+            <mxPoint x="7" y="25" as="offset" />
+          </mxGeometry>
+        </mxCell>
+        <mxCell id="KWlXfnC0i22sAb0q6HPk-8" style="edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;exitX=1;exitY=0.5;exitDx=0;exitDy=0;entryX=0;entryY=0.5;entryDx=0;entryDy=0;" parent="1" source="-eq3P-sCqOfjKJ7X8hlF-1" target="-eq3P-sCqOfjKJ7X8hlF-11" edge="1">
+          <mxGeometry relative="1" as="geometry" />
+        </mxCell>
+        <mxCell id="-eq3P-sCqOfjKJ7X8hlF-1" value="kube-apiserver" style="rounded=0;whiteSpace=wrap;html=1;" parent="1" vertex="1">
+          <mxGeometry x="220" y="760" width="120" height="60" as="geometry" />
+        </mxCell>
+        <mxCell id="-eq3P-sCqOfjKJ7X8hlF-2" value="webhook" style="rounded=0;whiteSpace=wrap;html=1;" parent="1" vertex="1">
+          <mxGeometry x="160" y="570" width="120" height="60" as="geometry" />
+        </mxCell>
+        <mxCell id="-eq3P-sCqOfjKJ7X8hlF-15" value="TLS bootstrap &lt;br&gt;&amp;amp; init webhook" style="edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;exitX=0.25;exitY=1;exitDx=0;exitDy=0;entryX=0.5;entryY=0;entryDx=0;entryDy=0;" parent="1" source="-eq3P-sCqOfjKJ7X8hlF-3" target="-eq3P-sCqOfjKJ7X8hlF-1" edge="1">
+          <mxGeometry x="-0.32" y="18" relative="1" as="geometry">
+            <Array as="points">
+              <mxPoint x="390" y="670" />
+              <mxPoint x="280" y="670" />
+            </Array>
+            <mxPoint as="offset" />
+          </mxGeometry>
+        </mxCell>
+        <mxCell id="-eq3P-sCqOfjKJ7X8hlF-3" value="cert-controller" style="rounded=0;whiteSpace=wrap;html=1;" parent="1" vertex="1">
+          <mxGeometry x="360" y="570" width="120" height="60" as="geometry" />
+        </mxCell>
+        <mxCell id="-eq3P-sCqOfjKJ7X8hlF-12" value="read / write secrets" style="edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;exitX=0.5;exitY=0;exitDx=0;exitDy=0;entryX=0.5;entryY=1;entryDx=0;entryDy=0;" parent="1" source="-eq3P-sCqOfjKJ7X8hlF-4" target="-eq3P-sCqOfjKJ7X8hlF-9" edge="1">
+          <mxGeometry relative="1" as="geometry" />
+        </mxCell>
+        <mxCell id="-eq3P-sCqOfjKJ7X8hlF-13" value="reconcile state" style="edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;exitX=0.5;exitY=1;exitDx=0;exitDy=0;entryX=0.75;entryY=0;entryDx=0;entryDy=0;" parent="1" source="-eq3P-sCqOfjKJ7X8hlF-4" target="-eq3P-sCqOfjKJ7X8hlF-1" edge="1">
+          <mxGeometry x="0.0068" y="-8" relative="1" as="geometry">
+            <mxPoint x="420" y="759.9999999999998" as="targetPoint" />
+            <Array as="points">
+              <mxPoint x="612" y="721" />
+              <mxPoint x="310" y="721" />
+            </Array>
+            <mxPoint as="offset" />
+          </mxGeometry>
+        </mxCell>
+        <mxCell id="-eq3P-sCqOfjKJ7X8hlF-4" value="core controller" style="rounded=0;whiteSpace=wrap;html=1;" parent="1" vertex="1">
+          <mxGeometry x="560" y="570" width="120" height="60" as="geometry" />
+        </mxCell>
+        <mxCell id="-eq3P-sCqOfjKJ7X8hlF-6" style="edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;entryX=0.5;entryY=1;entryDx=0;entryDy=0;" parent="1" source="-eq3P-sCqOfjKJ7X8hlF-5" target="-eq3P-sCqOfjKJ7X8hlF-1" edge="1">
+          <mxGeometry relative="1" as="geometry" />
+        </mxCell>
+        <mxCell id="-eq3P-sCqOfjKJ7X8hlF-5" value="Developer/&lt;br&gt;Admin" style="shape=umlActor;verticalLabelPosition=bottom;verticalAlign=top;html=1;outlineConnect=0;" parent="1" vertex="1">
+          <mxGeometry x="265" y="890" width="30" height="60" as="geometry" />
+        </mxCell>
+        <mxCell id="-eq3P-sCqOfjKJ7X8hlF-9" value="Secret Provider" style="rounded=0;whiteSpace=wrap;html=1;" parent="1" vertex="1">
+          <mxGeometry x="560" y="401.26" width="120" height="60" as="geometry" />
+        </mxCell>
+        <mxCell id="-eq3P-sCqOfjKJ7X8hlF-11" value="etcd" style="rounded=0;whiteSpace=wrap;html=1;" parent="1" vertex="1">
+          <mxGeometry x="380" y="760" width="120" height="60" as="geometry" />
+        </mxCell>
+        <mxCell id="KWlXfnC0i22sAb0q6HPk-1" value="Security Assets&lt;br&gt;&lt;br&gt;&lt;table cellpadding=&quot;4&quot; style=&quot;border: 1px solid rgb(102, 102, 102); border-collapse: collapse; background-color: rgb(255, 229, 153);&quot; border=&quot;1&quot;&gt;&lt;tbody&gt;&lt;tr&gt;&lt;td style=&quot;border-collapse: collapse;&quot; border=&quot;1&quot;&gt;&lt;b&gt;ID&lt;/b&gt;&lt;/td&gt;&lt;td&gt;&lt;b&gt;Description&lt;/b&gt;&lt;/td&gt;&lt;/tr&gt;&lt;tr&gt;&lt;td&gt;A01&lt;/td&gt;&lt;td&gt;cluster-level secret read/write access&lt;/td&gt;&lt;/tr&gt;&lt;tr&gt;&lt;td&gt;A02&lt;/td&gt;&lt;td&gt;CRD &amp;amp; webhook write access&lt;/td&gt;&lt;/tr&gt;&lt;tr&gt;&lt;td&gt;A03&lt;/td&gt;&lt;td&gt;secret provider access&lt;/td&gt;&lt;/tr&gt;&lt;tr&gt;&lt;td&gt;A04&lt;/td&gt;&lt;td&gt;capability to modify resources (conversion)&lt;/td&gt;&lt;/tr&gt;&lt;/tbody&gt;&lt;/table&gt;" style="text;html=1;align=center;verticalAlign=middle;resizable=0;points=[];autosize=1;strokeColor=none;fillColor=none;" parent="1" vertex="1">
+          <mxGeometry x="845" y="550" width="290" height="160" as="geometry" />
+        </mxCell>
+        <mxCell id="KWlXfnC0i22sAb0q6HPk-2" value="Security Controls&lt;br&gt;&lt;br&gt;&lt;table cellpadding=&quot;4&quot; style=&quot;border: 1px solid rgb(102, 102, 102); border-collapse: collapse; background-color: rgb(185, 224, 165);&quot; border=&quot;1&quot;&gt;&lt;tbody&gt;&lt;tr&gt;&lt;td style=&quot;border-collapse: collapse;&quot; border=&quot;1&quot;&gt;&lt;b&gt;ID&lt;/b&gt;&lt;/td&gt;&lt;td&gt;&lt;b&gt;Description&lt;/b&gt;&lt;/td&gt;&lt;/tr&gt;&lt;tr&gt;&lt;td&gt;C01&lt;/td&gt;&lt;td&gt;Network Security Policy (*)&lt;/td&gt;&lt;/tr&gt;&lt;tr&gt;&lt;td&gt;C02&lt;/td&gt;&lt;td&gt;Least Privilege RBAC&lt;/td&gt;&lt;/tr&gt;&lt;tr&gt;&lt;td&gt;C03&lt;/td&gt;&lt;td&gt;Policy Enforcement (*)&lt;/td&gt;&lt;/tr&gt;&lt;tr&gt;&lt;td&gt;C04&lt;/td&gt;&lt;td&gt;Provider Access Policy&lt;/td&gt;&lt;/tr&gt;&lt;tr&gt;&lt;td&gt;C05&lt;/td&gt;&lt;td&gt;disable CRDs&lt;/td&gt;&lt;/tr&gt;&lt;/tbody&gt;&lt;/table&gt;&lt;span style=&quot;white-space: pre;&quot;&gt;&#x9;&lt;/span&gt;" style="text;html=1;align=center;verticalAlign=middle;resizable=0;points=[];autosize=1;strokeColor=none;fillColor=none;" parent="1" vertex="1">
+          <mxGeometry x="885" y="710" width="210" height="200" as="geometry" />
+        </mxCell>
+        <mxCell id="KWlXfnC0i22sAb0q6HPk-3" value="Security Threats&lt;br&gt;&lt;br&gt;&lt;table cellpadding=&quot;4&quot; style=&quot;border: 1px solid rgb(102, 102, 102); border-collapse: collapse; background-color: rgb(248, 206, 204);&quot; border=&quot;1&quot;&gt;&lt;tbody&gt;&lt;tr&gt;&lt;td style=&quot;border-collapse: collapse;&quot; border=&quot;1&quot;&gt;&lt;b&gt;ID&lt;/b&gt;&lt;/td&gt;&lt;td&gt;&lt;b&gt;Description&lt;/b&gt;&lt;/td&gt;&lt;/tr&gt;&lt;tr&gt;&lt;td&gt;T01&lt;/td&gt;&lt;td&gt;tampering with resources through MITM&lt;/td&gt;&lt;/tr&gt;&lt;tr&gt;&lt;td&gt;T02&lt;/td&gt;&lt;td&gt;Webhook DOS&lt;/td&gt;&lt;/tr&gt;&lt;tr&gt;&lt;td&gt;T03&lt;/td&gt;&lt;td&gt;unauthorised access to cluster secrets&lt;/td&gt;&lt;/tr&gt;&lt;tr&gt;&lt;td&gt;T04&lt;/td&gt;&lt;td&gt;unauthorised access to provider secrets&lt;/td&gt;&lt;/tr&gt;&lt;tr&gt;&lt;td&gt;T05&lt;/td&gt;&lt;td&gt;data exfiltration through malicious resources&amp;nbsp;&lt;/td&gt;&lt;/tr&gt;&lt;tr&gt;&lt;td&gt;T06&lt;/td&gt;&lt;td&gt;supply chain attacks&lt;/td&gt;&lt;/tr&gt;&lt;tr&gt;&lt;td&gt;T07&lt;/td&gt;&lt;td&gt;malicious workloads in eso namespace&lt;/td&gt;&lt;/tr&gt;&lt;/tbody&gt;&lt;/table&gt;" style="text;html=1;align=center;verticalAlign=middle;resizable=0;points=[];autosize=1;strokeColor=none;fillColor=none;" parent="1" vertex="1">
+          <mxGeometry x="840" y="305" width="300" height="230" as="geometry" />
+        </mxCell>
+        <mxCell id="KWlXfnC0i22sAb0q6HPk-4" value="A01" style="rounded=0;whiteSpace=wrap;html=1;fillColor=#fff2cc;strokeColor=#d6b656;" parent="1" vertex="1">
+          <mxGeometry x="680" y="570" width="30" height="20" as="geometry" />
+        </mxCell>
+        <mxCell id="KWlXfnC0i22sAb0q6HPk-6" value="A02" style="rounded=0;whiteSpace=wrap;html=1;fillColor=#fff2cc;strokeColor=#d6b656;" parent="1" vertex="1">
+          <mxGeometry x="480" y="570" width="30" height="20" as="geometry" />
+        </mxCell>
+        <mxCell id="KWlXfnC0i22sAb0q6HPk-7" value="A03" style="rounded=0;whiteSpace=wrap;html=1;fillColor=#fff2cc;strokeColor=#d6b656;" parent="1" vertex="1">
+          <mxGeometry x="710" y="570" width="30" height="20" as="geometry" />
+        </mxCell>
+        <mxCell id="KWlXfnC0i22sAb0q6HPk-9" value="C01" style="rounded=0;whiteSpace=wrap;html=1;fillColor=#d5e8d4;strokeColor=#82b366;" parent="1" vertex="1">
+          <mxGeometry x="680" y="590" width="30" height="20" as="geometry" />
+        </mxCell>
+        <mxCell id="KWlXfnC0i22sAb0q6HPk-10" value="C01" style="rounded=0;whiteSpace=wrap;html=1;fillColor=#d5e8d4;strokeColor=#82b366;" parent="1" vertex="1">
+          <mxGeometry x="480" y="590" width="30" height="20" as="geometry" />
+        </mxCell>
+        <mxCell id="KWlXfnC0i22sAb0q6HPk-11" value="C01" style="rounded=0;whiteSpace=wrap;html=1;fillColor=#d5e8d4;strokeColor=#82b366;" parent="1" vertex="1">
+          <mxGeometry x="280" y="590" width="30" height="20" as="geometry" />
+        </mxCell>
+        <mxCell id="KWlXfnC0i22sAb0q6HPk-12" value="A04" style="rounded=0;whiteSpace=wrap;html=1;fillColor=#fff2cc;strokeColor=#d6b656;" parent="1" vertex="1">
+          <mxGeometry x="280" y="570" width="30" height="20" as="geometry" />
+        </mxCell>
+        <mxCell id="KWlXfnC0i22sAb0q6HPk-13" value="T01" style="rounded=0;whiteSpace=wrap;html=1;fillColor=#F8CECC;strokeColor=#b85450;" parent="1" vertex="1">
+          <mxGeometry x="280" y="610" width="30" height="20" as="geometry" />
+        </mxCell>
+        <mxCell id="KWlXfnC0i22sAb0q6HPk-15" value="T02" style="rounded=0;whiteSpace=wrap;html=1;fillColor=#F8CECC;strokeColor=#b85450;" parent="1" vertex="1">
+          <mxGeometry x="480" y="610" width="30" height="20" as="geometry" />
+        </mxCell>
+        <mxCell id="KWlXfnC0i22sAb0q6HPk-17" value="T03" style="rounded=0;whiteSpace=wrap;html=1;fillColor=#F8CECC;strokeColor=#b85450;" parent="1" vertex="1">
+          <mxGeometry x="680" y="610" width="30" height="20" as="geometry" />
+        </mxCell>
+        <mxCell id="KWlXfnC0i22sAb0q6HPk-19" value="C02" style="rounded=0;whiteSpace=wrap;html=1;fillColor=#d5e8d4;strokeColor=#82b366;" parent="1" vertex="1">
+          <mxGeometry x="710" y="590" width="30" height="20" as="geometry" />
+        </mxCell>
+        <mxCell id="KWlXfnC0i22sAb0q6HPk-20" value="C02" style="rounded=0;whiteSpace=wrap;html=1;fillColor=#d5e8d4;strokeColor=#82b366;" parent="1" vertex="1">
+          <mxGeometry x="510" y="590" width="30" height="20" as="geometry" />
+        </mxCell>
+        <mxCell id="KWlXfnC0i22sAb0q6HPk-21" value="C02" style="rounded=0;whiteSpace=wrap;html=1;fillColor=#d5e8d4;strokeColor=#82b366;" parent="1" vertex="1">
+          <mxGeometry x="310" y="590" width="30" height="20" as="geometry" />
+        </mxCell>
+        <mxCell id="KWlXfnC0i22sAb0q6HPk-18" value="T04" style="rounded=0;whiteSpace=wrap;html=1;fillColor=#F8CECC;strokeColor=#b85450;" parent="1" vertex="1">
+          <mxGeometry x="710" y="610" width="30" height="20" as="geometry" />
+        </mxCell>
+        <mxCell id="Ww5IvjzXZUh7UzVtdnaJ-2" value="C03" style="rounded=0;whiteSpace=wrap;html=1;fillColor=#d5e8d4;strokeColor=#82b366;" parent="1" vertex="1">
+          <mxGeometry x="740" y="590" width="30" height="20" as="geometry" />
+        </mxCell>
+        <mxCell id="dCErDjv6PzuvUg3lQw2a-1" value="T06" style="rounded=0;whiteSpace=wrap;html=1;fillColor=#F8CECC;strokeColor=#b85450;" parent="1" vertex="1">
+          <mxGeometry x="110" y="550" width="30" height="20" as="geometry" />
+        </mxCell>
+        <mxCell id="dCErDjv6PzuvUg3lQw2a-2" value="T07" style="rounded=0;whiteSpace=wrap;html=1;fillColor=#F8CECC;strokeColor=#b85450;" parent="1" vertex="1">
+          <mxGeometry x="110" y="570" width="30" height="20" as="geometry" />
+        </mxCell>
+        <mxCell id="dCErDjv6PzuvUg3lQw2a-4" value="C04" style="rounded=0;whiteSpace=wrap;html=1;fillColor=#d5e8d4;strokeColor=#82b366;" parent="1" vertex="1">
+          <mxGeometry x="680" y="421.26" width="30" height="20" as="geometry" />
+        </mxCell>
+        <mxCell id="KWlXfnC0i22sAb0q6HPk-14" value="T02" style="rounded=0;whiteSpace=wrap;html=1;fillColor=#F8CECC;strokeColor=#b85450;" parent="1" vertex="1">
+          <mxGeometry x="310" y="610" width="30" height="20" as="geometry" />
+        </mxCell>
+        <mxCell id="Ww5IvjzXZUh7UzVtdnaJ-1" value="T05" style="rounded=0;whiteSpace=wrap;html=1;fillColor=#F8CECC;strokeColor=#b85450;" parent="1" vertex="1">
+          <mxGeometry x="740" y="610" width="30" height="20" as="geometry" />
+        </mxCell>
+        <mxCell id="dCErDjv6PzuvUg3lQw2a-3" value="T05" style="rounded=0;whiteSpace=wrap;html=1;fillColor=#F8CECC;strokeColor=#b85450;" parent="1" vertex="1">
+          <mxGeometry x="680" y="441.26" width="30" height="20" as="geometry" />
+        </mxCell>
+        <mxCell id="pWq7YGlfomeq9d_JThvH-1" value="C05" style="rounded=0;whiteSpace=wrap;html=1;fillColor=#d5e8d4;strokeColor=#82b366;" vertex="1" parent="1">
+          <mxGeometry x="770" y="590" width="30" height="20" as="geometry" />
+        </mxCell>
+      </root>
+    </mxGraphModel>
+  </diagram>
+  <diagram id="cfY7S7NFl4qge9Uy_So4" name="TLS Bootstrap">
+    <mxGraphModel dx="844" dy="489" grid="1" gridSize="10" guides="1" tooltips="1" connect="1" arrows="1" fold="1" page="1" pageScale="1" pageWidth="827" pageHeight="1169" math="0" shadow="0">
+      <root>
+        <mxCell id="0" />
+        <mxCell id="1" parent="0" />
+        <mxCell id="adGjIOf3ydgdso1pvlvY-2" value="" style="rounded=0;whiteSpace=wrap;html=1;fillColor=none;dashed=1;" vertex="1" parent="1">
+          <mxGeometry x="200" y="740" width="300" height="100" as="geometry" />
+        </mxCell>
+        <mxCell id="adGjIOf3ydgdso1pvlvY-3" value="" style="rounded=0;whiteSpace=wrap;html=1;fillColor=#dae8fc;dashed=1;strokeColor=#6c8ebf;" vertex="1" parent="1">
+          <mxGeometry x="160" y="550" width="440" height="100" as="geometry" />
+        </mxCell>
+        <mxCell id="adGjIOf3ydgdso1pvlvY-4" value="5. send conversion/validating&lt;br&gt;&amp;nbsp;webhook" style="edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;exitX=0.164;exitY=-0.031;exitDx=0;exitDy=0;entryX=0.5;entryY=1;entryDx=0;entryDy=0;exitPerimeter=0;" edge="1" parent="1" source="adGjIOf3ydgdso1pvlvY-5" target="adGjIOf3ydgdso1pvlvY-6">
+          <mxGeometry x="-0.0951" y="80" relative="1" as="geometry">
+            <mxPoint as="offset" />
+          </mxGeometry>
+        </mxCell>
+        <mxCell id="adGjIOf3ydgdso1pvlvY-5" value="kube-apiserver" style="rounded=0;whiteSpace=wrap;html=1;" vertex="1" parent="1">
+          <mxGeometry x="220" y="760" width="120" height="60" as="geometry" />
+        </mxCell>
+        <mxCell id="adGjIOf3ydgdso1pvlvY-6" value="webhook" style="rounded=0;whiteSpace=wrap;html=1;" vertex="1" parent="1">
+          <mxGeometry x="180" y="570" width="120" height="60" as="geometry" />
+        </mxCell>
+        <mxCell id="adGjIOf3ydgdso1pvlvY-7" value="2. write TLS secret&lt;br&gt;3. update caBundle in CRD/Webhook" style="edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;exitX=0.25;exitY=1;exitDx=0;exitDy=0;entryX=0.5;entryY=0;entryDx=0;entryDy=0;align=left;" edge="1" parent="1" source="adGjIOf3ydgdso1pvlvY-8" target="adGjIOf3ydgdso1pvlvY-5">
+          <mxGeometry x="0.4" y="10" relative="1" as="geometry">
+            <Array as="points">
+              <mxPoint x="350" y="670" />
+              <mxPoint x="280" y="670" />
+            </Array>
+            <mxPoint as="offset" />
+          </mxGeometry>
+        </mxCell>
+        <mxCell id="adGjIOf3ydgdso1pvlvY-8" value="cert-controller" style="rounded=0;whiteSpace=wrap;html=1;" vertex="1" parent="1">
+          <mxGeometry x="320" y="570" width="120" height="60" as="geometry" />
+        </mxCell>
+        <mxCell id="adGjIOf3ydgdso1pvlvY-11" value="core controller" style="rounded=0;whiteSpace=wrap;html=1;" vertex="1" parent="1">
+          <mxGeometry x="460" y="570" width="120" height="60" as="geometry" />
+        </mxCell>
+        <mxCell id="adGjIOf3ydgdso1pvlvY-15" value="etcd" style="rounded=0;whiteSpace=wrap;html=1;" vertex="1" parent="1">
+          <mxGeometry x="360" y="760" width="120" height="60" as="geometry" />
+        </mxCell>
+        <mxCell id="qu5wcJP0yzF1II28N2AH-1" value="1. gen private key / self-signed cert" style="edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;exitX=0.25;exitY=0;exitDx=0;exitDy=0;entryX=0.75;entryY=0;entryDx=0;entryDy=0;" edge="1" parent="1" source="adGjIOf3ydgdso1pvlvY-8" target="adGjIOf3ydgdso1pvlvY-8">
+          <mxGeometry y="10" relative="1" as="geometry">
+            <Array as="points">
+              <mxPoint x="350" y="530" />
+              <mxPoint x="410" y="530" />
+            </Array>
+            <mxPoint as="offset" />
+          </mxGeometry>
+        </mxCell>
+        <mxCell id="qu5wcJP0yzF1II28N2AH-2" value="4. configure TLS" style="edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;exitX=0.25;exitY=0;exitDx=0;exitDy=0;entryX=0.5;entryY=0;entryDx=0;entryDy=0;" edge="1" parent="1" source="adGjIOf3ydgdso1pvlvY-6" target="adGjIOf3ydgdso1pvlvY-6">
+          <mxGeometry x="-0.0182" y="12" relative="1" as="geometry">
+            <Array as="points">
+              <mxPoint x="210" y="530" />
+              <mxPoint x="240" y="530" />
+            </Array>
+            <mxPoint as="offset" />
+          </mxGeometry>
+        </mxCell>
+      </root>
+    </mxGraphModel>
+  </diagram>
+</mxfile>

hack/api-docs/mkdocs.yml

@@ -13,6 +13,7 @@ theme:
     - navigation.expand
   custom_dir: ../../overrides
 markdown_extensions:
+  - attr_list
   - pymdownx.highlight
   - pymdownx.superfences
   - admonition
@@ -79,6 +80,7 @@ nav:
     - Operations:
       - Multi Tenancy: guides/multi-tenancy.md
       - Security Best Practices: guides/security-best-practices.md
+      - Threat Model: guides/threat-model.md
       - Upgrading to v1beta1: guides/v1beta1.md
       - Using Latest Image: guides/using-latest-image.md
       - Disable Cluster Features: guides/disable-cluster-features.md