Baseline cluster security (#414)

Renamed the file to better match its actual intention.

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

Standards/scs-0214-v1-k8s-node-distribution.md

@@ -8,7 +8,7 @@ track: KaaS
 ## Introduction
 
 A Kubernetes instance is provided as a cluster, which consists of a set of machines,
-so called nodes. A cluster is composed of a control plane and at least one worker node.
+so-called nodes. A cluster is composed of a control plane and at least one worker node.
 The control plane manages the worker nodes and therefore the pods in the cluster by making
 decisions about scheduling, event detection and rights management. Inside the control plane,
 multiple components exist, which can be duplicated and distributed over multiple nodes
@@ -19,11 +19,11 @@ separate the controller component from user workloads, which could pose a securi
 
 The following terms are used throughout this document:
 
-| Term | Meaning |
-|---|---|
-| Worker | Virtual or bare-metal machine, which hosts workloads of customers |
+| Term          | Meaning                                                                                                                                                                     |
+|---------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
+| Worker        | Virtual or bare-metal machine, which hosts workloads of customers                                                                                                           |
 | Control Plane | Virtual or bare-metal machine, which hosts the container orchestration layer that exposes the API and interfaces to define, deploy, and manage the lifecycle of containers. |
-| Machine | Virtual or bare-metal entity with computational capabilities |
+| Machine       | Virtual or bare-metal entity with computational capabilities                                                                                                                |
 
 ## Motivation
 

Standards/scs-0216-v1-cluster-baseline-security.md → Standards/scs-0217-v1-baseline-cluster-security.md

@@ -18,14 +18,22 @@ which will need to be mitigated by an administrator with the proper knowledge.
 Hardened, secure Kubernetes clusters are desirable regardless of the possible threat model,
 since higher security doesn't necessarily mean higher complexity in this case.
 
+## Terminology
+
+| Term | Meaning                     |
+|------|-----------------------------|
+| TLS  | Transport Layer Security    |
+| CA   | Certificate Authority       |
+| CSR  | Certificate Signing Request |
+
 ## Motivation
 
 Kubernetes clusters are highly configurable, which also gives rise to different security
 problems, if the configuration isn't done properly.
 These security risks can potentially be exposed in many different parts of a cluster, e.g.
 different APIs, authorization and authentication procedures or even Pod privilege mechanisms.
-In order to mitigate these problems, different hardening and prevention steps and mechanisms
-could be used to increase the security of a Kubernetes setup.
+In order to mitigate these problems, different steps and mechanisms could be used to increase
+the security of a Kubernetes setup.
 
 ## Design Considerations
 
@@ -53,7 +61,7 @@ a reference to the CA keypair, which was used in the previous example to sign a
 
 ### Protected Kubernetes endpoints
 
-In order to secure a Kubernetes cluster, the protection and hardening of endpoints is important.
+In order to secure a Kubernetes cluster, the protection of endpoints is important.
 To do this, different approaches can be taken.
 
 #### TLS for all internal/API traffic
@@ -83,7 +91,7 @@ x509 certificates, which will normally be created automatically during the setup
 External users can authenticate via an access pattern of choice, which is typically decided by
 the cluster provider.
 
-Authorization is (normally) done by he Role-Based Access Control (RBAC), which matches a request
+Authorization is (normally) done by the Role-Based Access Control (RBAC), which matches a request
 by a user with a set of permissions, also called a role. Kubernetes deploys some roles out-of-the-box;
 additional roles need to be carefully checked, since some permissions for specific resources allow
 modification of other resources.
@@ -107,11 +115,11 @@ After that, the Kubelet calls the `SubjectAccessReview` API in order to determin
 
 ## Decision
 
-This standard tries to increase security for a Kubernetes cluster and harden it in order
-to provide a high security setup. For this to work, multiple measures need to be undertaken.
+This standard tries to increase security for a Kubernetes cluster in order to provide a
+solid baseline setup with regard to security. For this to work, multiple measures need to be undertaken.
 It is important to note that this standard is not REQUIRED for all clusters,
-but instead gives best practices for increasing security. Nevertheless, if a cluster is
-provided on the basis of high security, this standard MUST be applied.
+but instead gives best practices for increasing security. Nevertheless, if a cluster is claiming
+to be secure, this standard must be applied.
 
 A self-controlled CA SHOULD be used in order to be in control of the TLS certificates, which
 enables the operator to provide and revoke certificates according to the requirements.
@@ -123,9 +131,8 @@ The Kubernetes API (kubeAPI) MUST be secured by authenticating and authorizing t
 trying to access its endpoints. How a user is authenticated is up to the provider of the
 cluster and/or the wishes of the customer. Authorization MUST be done by providing
 fine-grained RBAC.
-This whole process also MUST be applied to the Kubelet, which in its default configuration
-doesn't enable authentication or authorization. A way to do this can be found in the
-section [Authentication and Authorization].
+The authentication and authorization steps MUST also be applied to the Kubelet, which in its default configuration
+doesn't enable them. A way to do this can be found in the section [Authentication and Authorization].
 
 ## Related Documents