Add answers to open questions from proposal 2

malexmave · malexmave · commit 77e54cd3354c · 2022-08-31T10:21:21.000+02:00
Signed-off-by: Max Maass &lt;max.maass@iteratec.com&gt;
diff --git a/docs/adr/adr_0012.md b/docs/adr/adr_0012.md
@@ -127,13 +127,11 @@ This alternative proposal uses the same cluster-wide CRDs mentioned above, but a
 
 The `ClusterScan` is almost identical to the `Scan` type, however, it includes an additional field called `executionNamespace` that controls in which namespace it is scheduled. The operator will schedule it in to the namespace, or throw an error if the namespace does not exist or the operator cannot schedule into it for any reason. They will only trigger a `ClusterScanCompletionHook`, only respect `ClusterCascadingRule`, and in all other ways be kept separate from non-Cluster-resources, with one major exception: access to namespace-specific ConfigMaps and Secrets. Here, this access is desireable, as it allows teams to customize the behavior of cluster-managed scans to their own situation (e.g., provide a cluster-wide ZAP scan with a namespace-specific authentication configuration for the microservice). The same consideration from the other proposal apply for ensuring that the secrets and configMaps are available.
 
-**OPEN QUESTION:** From a threat perspective (what happens if an unauthorized user can create cluster-wide scans and schedule them into other teams' namespaces?), it may be desireable to create a specific label or annotation for secrets and configmaps that has to be present for them to be accessible to cluster-wide scans, and to hide other such resources from them for security reasons, as a defense-in-depth measure against incorrectly configured clusters (we really need to threat model this feature). Is this something that is feasible with a k8s operator?
-=> This is possible, either in the operator, or using a validating webhook (the former being preferred).
+To avoid exposing secrets and ConfigMaps to cluster users who can create cluster-wide scans, we could implement a restriction in the operator (or using a validating webhook) that checks which secrets and ConfigMaps are being mounted by such a scan, and reject the scan if any of the secrets or ConfigMaps does not have a special label or annotation that marks them as being exposed to this feature.
 
 These CRDs will likely not be used a lot by human operators, but they are helpful for use with the autodiscovery feature, which can use them to schedule scans into namespaces without interfering with any scans, hooks or other features the owners of the namespace are using. Pods scheduled from scans like this should also receive a distinct label or annotation from regular scans in that namespace, to allow for fine-grained network policies (e.g., "Cluster scans are allowed to access this specific server that caches nuclei templates for them, but regular scans are not").
 
-**OPEN QUESTION:** Can people with rights on their own namespace, but not other namespaces, see ClusterScans that are scheduled in their namespace? Should they be able to?
-=> This should be blocked.
+By default `ClusterScan`s cannot be seen by users that only have access to their own namespace.
 
 #### `ClusterScanType`
 
