Apply suggestions from code review

Co-authored-by: Víctor Cuadrado Juan <[email protected]>

rfc/0006-threat-model.md

@@ -14,7 +14,7 @@ and the possible mitigations.
 # Motivation
 [motivation]: #motivation
 
-The goal of this is turn Kubewarden mode secure to operate.
+The goal of this is turn Kubewarden more secure to operate.
 
 ## Examples / User Stories
 [examples]: #examples
@@ -37,7 +37,7 @@ If more details about each threat is needed, go to the original document here:
 https://github.com/kubernetes/sig-security/tree/main/sig-security-docs/papers/admission-control
 
 
-## Threat 1 - Attacker floods webhook with traffic preventing its
+## Threat 1 - Attacker floods webhook with traffic preventing its operation
 
 An attacker who has access to the Webhook endpoint, at the network level, could
 send large  quantities of traffic, causing an effective denial of service to the
@@ -65,10 +65,6 @@ a mis-configuration to bypass the intended security control
 **Mitigation**
 Regular reviews of webhook configuration catch issues.
 
-**To do**
-We may provide some mechanism to notify operators when a webhook is changed.
-Maybe the controller can watch its webhooks, fix when the configuration is
-changed and notify the operator.
 
 ### Threat 4 - Attacker has rights to delete or modify the k8s webhook  object
 
@@ -153,7 +149,7 @@ from the  admission controller configuration.
 RBAC rights are strictly controlled
 
 **To do**
-I think most of the RBAC is not responsability. But we can help our users if we:
+I think most of the RBAC is not Kubewarden responsability. But we can help our users if we:
 - Warning them in our docs and *suggest* some minimum RBAC to be used.
 - Provide a policy which detect RBAC changes and **maybe** block them. Is this possible?
 
@@ -202,11 +198,8 @@ a privileged  container on the cluster node where the admission controller webho
 Admission controller uses restrictive policies to prevent privileged  workloads
 
 **To do**
-We have a policy to prevent privileged workloads in the recommended policies in
-the `kubewarden-default` helm chart. But we can improve by:
-- We may need to define all the API versions cover by the recommended policies
-- We can create a configuration to reject by default requests where the API version not cover by the policy.
-- We should warning policies developers to cover all the supported API version in theirs tests and reject all of others.
+I do not know if Kuberwarden can help on this. Kubewarden does not have access to
+containers running in the cluster node.
 
 
 ## Threat ID 16 - Attacker mounts a privileged node hostpath allowing  modification of Webhook controller configuration
@@ -238,25 +231,23 @@ Strictly control external access for webhook
 **To do**
 We may define some network configuration to block external access from the Kubewarden pods.
 
+## Threat Kubewarden ID 1 - Bootstrapping of trust for admission controller
+Assuming a trusted but fresh Kubernetes cluster, an attacker is able to compromise the Kubewarden stack before any of the policies securing it is deployed and enforcing. For example, by using unsigned and malicious images for kubewarden-controller, policy-server, or any of the Kubewarden dependencies (cert-manager) or optional dependencies (grafana, prometheus..), or by compromising the Helm charts payload.
+
+** Mitigation **
+1. Kubewarden provides a Software Bill Of Materials, which lists all images needed. This aids with Zero-Trust.
+  The Kubernetes Administrator must verify the Kubewarden images (and its dependencies' images and charts) out of the Kubernetes cluster, in a trusted environment. This can be done with `cosign`, for example.
+  Incidentally, this is part of the implementation needed for air-gapped installations.
+ 2. Use signed Helm charts, and verified digests (instead of tags) for Kubewarden images in those Helm charts. This doesn't secure dependencies though.
 
 # Drawbacks
 [drawbacks]: #drawbacks
 
-Why should we **not** do this?
-
-  * obscure corner cases
-  * will it impact performance?
-  * what other parts of the product will be affected?
-  * will the solution be hard to maintain in the future?
 
 # Alternatives
 [alternatives]: #alternatives
 
-- What other designs/options have been considered?
-- What is the impact of not doing this?
 
 # Unresolved questions
 [unresolved]: #unresolved-questions
 
-- What are the unknowns?
-- What can happen if Murphy's law holds true?