fixup! Kubernetes High Security setup (#415)

Signed-off-by: Hannes Baum <[email protected]>

Standards/scs-0216-v1-high-security-setup.md

@@ -105,24 +105,6 @@ authorization to the API server by:
 
 After that, the Kubelet calls the `SubjectAccessReview` API in order to determine the authorization of a request.
 
-### Control workload and user capabilities
-
-Multiple policies can be setup to limit and control the capabilities of workloads and users,
-especially in order to prevent malicious actors from exploiting obvious faults or even to
-just prevent incorrectly configured workloads from overusing resources.
-
-An easy way to do this would be Resource Limiting on a cluster. This can be done on a per-namespace
-basis and can prevent the overuse of resources or even prevent the creation of too many pods, services or volumes.
-
-It is also possible to change the security context of a pod, which changes different settings of a pod, like
-its underlying Linux user, the access to the host network or different other controls that
-are related to the host.
-A `Pod Security Admission` can enforce a certain standard in a namespace, since most application
-workloads need only limited access to host information.
-Similarly, `Network Policies` restrict which pods may access which pods and ports in which namespaces.
-Another interesting approach is to prevent the loading of specific (or all) kernel modules, if they
-shouldn't be used by pods.
-
 ## Decision
 
 This standard tries to increase security for a Kubernetes cluster and harden it in order
@@ -145,13 +127,6 @@ This whole process also MUST be applied to the Kubelet, which in its default con
 doesn't enable authentication or authorization. A way to do this can be found in the
 section [Authentication and Authorization].
 
-The capabilities of workloads and its users MUST be limited in order to prevent malicious
-actors or unintentional problems. The following actions COULD be undertaken to do this:
-
-- Resource Limiting in namespaces of a cluster
-- change Security context of a pod to use non-root users or disable access to specific host resources
-- disallow loading of kernel modules by pods
-
 ## Related Documents
 
 [Managing TLS in a cluster](https://kubernetes.io/docs/tasks/tls/managing-tls-in-a-cluster/)