fixup! Update baseline cluster security (#475)

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

Standards/scs-0217-v1-cluster-hardening.md

@@ -177,42 +177,33 @@ be enabled and the [Kubernetes documentation][kubernetes-auth] recommends at lea
 including Service Account Tokens and another method. Methods directly provided by Kubernetes include
 the following (a more complete or up-to-date list may be found in the [Kubernetes authentication docs][kubernetes-auth]):
 
-<ul>
-<li>
-<p><i>Static Token Files</i></p>
-<p>This method reads bearer tokens from requests and checks them against a CSV file provided to Kubernetes containing
-three columns named `token`, `username` and `uid`. These tokens last indefinitely and the list cant be changed without a 
-restart of the API server. This makes this option unsuitable for productive clusters.</p>
-</li>
-</ul>
-
-<ul>
-<li>
-<p><i>Service Account Tokens</i></p>
-<p>A service account is an authenticator that uses signed bearer tokens for request verification.
-Service accounts can be given to the API server with a file containing PEM-encoded X509 RSA or
-ECDSA private or public keys that verify the Service Account Tokens.
-Service Accounts are normally created automatically by the API server and associated with the
-pods through the `ServiceAccount` admission controller. Tokens are signed JSON Web Tokens,
-that can be used as a Bearer Token or mounted into the pods for API server access.
-Since Service Account Tokens are mainly used to allow workloads accessing the API server,
-they're not really intended to authenticate users in productive clusters.</p>
-</li>
-</ul>
-
-<ul>
-<li>
-<p><i>X509 client certificates</i></p>
-<p>Client certificate authentication can be enabled by providing a `Certificate Authority`
-file to the API server via the `--client-ca-file=` option. The file contains one
-or more CAs that a presented client certificate is validated against.
-In this case the common subject name is used as the username for the request;
-additionally, a group membership can be indicated with the certificates organization field.
-These certificates are unsuitable for production use, because Kubernetes does not
-support certificate revocation. This means user credentials can't be modified or
-revoked without rotating the root CA and re-issuing all cluster certificates.</p>
-</li>
-</ul>
+- *Static Token Files*
+
+  This method reads bearer tokens from requests and checks them against a CSV file provided to Kubernetes containing
+  three columns named `token`, `username` and `uid`. These tokens last indefinitely and the list cant be changed without a 
+  restart of the API server. This makes this option unsuitable for productive clusters.
+
+- *Service Account Tokens*
+
+  A service account is an authenticator that uses signed bearer tokens for request verification.
+  Service accounts can be given to the API server with a file containing PEM-encoded X509 RSA or
+  ECDSA private or public keys that verify the Service Account Tokens.
+  Service Accounts are normally created automatically by the API server and associated with the
+  pods through the `ServiceAccount` admission controller. Tokens are signed JSON Web Tokens,
+  that can be used as a Bearer Token or mounted into the pods for API server access.
+  Since Service Account Tokens are mainly used to allow workloads accessing the API server,
+  they're not really intended to authenticate users in productive clusters.</p>
+
+- *X509 client certificates*
+
+  Client certificate authentication can be enabled by providing a `Certificate Authority`
+  file to the API server via the `--client-ca-file=` option. The file contains one
+  or more CAs that a presented client certificate is validated against.
+  In this case the common subject name is used as the username for the request;
+  additionally, a group membership can be indicated with the certificates organization field.
+  These certificates are unsuitable for production use, because Kubernetes does not
+  support certificate revocation. This means user credentials can't be modified or
+  revoked without rotating the root CA and re-issuing all cluster certificates.
 
 As outlined, most internal authentication mechanisms of Kubernetes aren't really
 usable in productive environments at the current time. Instead, external authentication
@@ -239,34 +230,35 @@ By default, a request would be denied.
 
 Kubernetes provides several authentication modes to authorize a request:
 
-* *Node*  
-The [Node authorization mode][node-authorization] grants permission to a Kubelet
-based on the scheduled pods running on them. It allows a Kubelet to perform specific
-API operations. The goal is to have a minimal set of permissions to ensure
-the Kubelet can operate correctly.
-Each Kubelet identifies with credentials belonging to the `system:nodes` group and
-a username `system:nodes:<node>` against this authorizer.
+- *Node*
 
+  The [Node authorization mode][node-authorization] grants permission to a Kubelet
+  based on the scheduled pods running on them. It allows a Kubelet to perform specific
+  API operations. The goal is to have a minimal set of permissions to ensure
+  the Kubelet can operate correctly.
+  Each Kubelet identifies with credentials belonging to the `system:nodes` group and
+  a username `system:nodes:<node>` against this authorizer.
 
-* *ABAC (Attribute-based access control)*  
-ABAC grants access rights based on policies dependent on attributes like
+- *ABAC (Attribute-based access control)*
+
+  ABAC grants access rights based on policies dependent on attributes like
 user attributes, resource attributes or environment attributes.
 An example would be the `resource` attribute, which could limit access for a user
 to only `Pod` resources.
 
+- *RBAC (Role-based access control)*
 
-* *RBAC (Role-based access control)*  
-RBAC is a method of regulating access to the resources based on the roles of
-individual users. A user therefore must have the ability to perform a specific set
-of tasks with a set of resources based on his role.
-Kubernetes implements `Role`s to accomplish this and binds these with `Role Binding`s
-to a user in order to specify his permission set.
+  RBAC is a method of regulating access to the resources based on the roles of
+  individual users. A user therefore must have the ability to perform a specific set
+  of tasks with a set of resources based on his role.
+  Kubernetes implements `Role`s to accomplish this and binds these with `Role Binding`s
+  to a user in order to specify his permission set.
 
+- *Webhook*
 
-* *Webhook*  
-Webhook authorization uses an HTTP callback to check the authorization of a user
-against a URL provided for this mode. This externalises the authorization part
-outside of Kubernetes.
+  Webhook authorization uses an HTTP callback to check the authorization of a user
+  against a URL provided for this mode. This externalises the authorization part
+  outside of Kubernetes.
 
 Most organizations and deployments work with RBAC, most often due to organizational or
 customer-owner-relationship-like structures in place.
@@ -340,16 +332,19 @@ in the form of three policies that try to cover the range of the security spectr
 These policies can be found in the following list and define a list of restricted fields that can only be
 changed to a set of allowed values. An up-to-date list of these values can be found [here][pod-security-standards].
 
-* *Privileged*  
-Unrestricted policy, providing the widest possible level of permissions.
-This policy allows for known privilege escalations.
+- *Privileged*
+
+  Unrestricted policy, providing the widest possible level of permissions.
+  This policy allows for known privilege escalations.
+
+- *Baseline*
+
+  Minimally restrictive policy which prevents known privilege escalations.
+  Allows the default (minimally specified) Pod configuration.
 
-* *Baseline*  
-Minimally restrictive policy which prevents known privilege escalations.
-Allows the default (minimally specified) Pod configuration.
+- *Restricted*
 
-* *Restricted*  
-Heavily restricted policy, following current Pod hardening best practices.
+  Heavily restricted policy, following current Pod hardening best practices.
 
 Kubernetes also offers the *Pod security* admission controller, which enforces
 the *Pod security standards* on a namespace level during pod creation.
@@ -358,15 +353,18 @@ The admission controller defines the standard to be used with the three levels
 a different control mode, which defines what action the control plane takes
 after a violation of the selected *Pod security* is detected.
 
-* `enforce`  
-Policy violations will cause the pod to be rejected.
+- `enforce`
+
+  Policy violations will cause the pod to be rejected.
+
+- `audit`
+
+  Policy violations will trigger the addition of an audit annotation to the event
+  recorded in the audit log, but are otherwise allowed.
 
-* `audit`  
-Policy violations will trigger the addition of an audit annotation to the event
-recorded in the audit log, but are otherwise allowed.
+- `warn`
 
-* `warn`  
-Policy violations will trigger a user-facing warning, but are otherwise allowed.
+  Policy violations will trigger a user-facing warning, but are otherwise allowed.
 
 Be aware, that `enforce` is not applied to workload resources, only to the pods created from their template.