Baseline cluster security (#414)

Renamed the file to better match its actual intention. Signed-off-by: Hannes Baum <[email protected]>
SovereignCloudStack · Feb 14, 2024 · 29ca23d · 29ca23d
1 parent 3e532bf
commit 29ca23d
Show file tree

Hide file tree

Showing 2 changed files with 34 additions and 32 deletions.
diff --git a/Standards/scs-0214-v1-k8s-node-distribution.md b/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
 

diff --git a/.../scs-0216-v1-cluster-baseline-security.md → .../scs-0217-v1-baseline-cluster-security.md b/.../scs-0216-v1-cluster-baseline-security.md → .../scs-0217-v1-baseline-cluster-security.md
@@ -7,25 +7,30 @@ track: KaaS
 
 ## Introduction
 
-A Kubernetes instance is provided as a cluster, which consists of a set of machines,
-so-called nodes. These clusters are configured depending on the needs of its users, which
-is possible due to the flexibility of Kubernetes.
-Due to the regular changes, there are always new security features to deploy and use in Kubernetes.
+Due to the regular changes and updates, there are always new security features to deploy and use in Kubernetes.
 Nevertheless, a provider (or even a customer) needs to take action in order to achieve a
 hardened, secure cluster due to the myriad of configurations possible. This is especially
 the case since Kubernetes ships with insecure features and configurations out of the box,
 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 +58,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
@@ -70,9 +75,10 @@ A list of the default service endpoints can be seen in the following table
 | TCP      | 10250       | Kubelet API             | -                                                                                       |
 | TCP      | 10251/10259 | kube-scheduler          | 10251 could be insecure before 1.13, after that only the secure port 10259 is available |
 | TCP      | 10252/10257 | kube-controller-manager | 10252 could be insecure before 1.13, after that only the secure port 10257 is available |
-| TCP      | 10255       | Read-Only Kubelet API   | HTTP port for GET requests                                                              |
 | TCP      | 30000-32767 | NodePort Services       | Service endpoints, could be HTTP                                                        |
 
+The usage of `readOnlyPort` (enabling a read-only Kubelet API port on 10255) by design neither provides authentication nor authorization. Its usage is strongly discouraged!
+
 #### Authentication and Authorization
 
 All API clients should authenticate and authorize in order to be able to access an API or even
@@ -83,7 +89,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,34 +113,30 @@ 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.
-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.
+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.
 
 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.
+enables operators to provide and revoke certificates according to their own requirements.
 
-All internal endpoints found in the section [TLS for all internal/API traffic] should be
+All internal endpoints found in the section [TLS for all internal/API traffic] MUST be
 encrypted with TLS in order to secure internal traffic.
 
 The Kubernetes API (kubeAPI) MUST be secured by authenticating and authorizing the users
 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].
+cluster and/or the wishes of the customer. Authorization MUST be done by providing fine-grained RBAC.
+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
 
-[Managing TLS in a cluster](https://kubernetes.io/docs/tasks/tls/managing-tls-in-a-cluster/)
-[Securing a cluster](https://kubernetes.io/docs/tasks/administer-cluster/securing-a-cluster/)
-[Controlling access](https://kubernetes.io/docs/concepts/security/controlling-access/)
-[Kubelet Authentication and Authorization](https://kubernetes.io/docs/reference/access-authn-authz/kubelet-authn-authz/)
-[Authentication](https://kubernetes.io/docs/reference/access-authn-authz/authentication/)
-[Kubernetes Security](https://cheatsheetseries.owasp.org/cheatsheets/Kubernetes_Security_Cheat_Sheet.html)
+- [Managing TLS in a cluster](https://kubernetes.io/docs/tasks/tls/managing-tls-in-a-cluster/)
+- [Securing a cluster](https://kubernetes.io/docs/tasks/administer-cluster/securing-a-cluster/)
+- [Controlling access](https://kubernetes.io/docs/concepts/security/controlling-access/)
+- [Kubernetes Security Checklist](https://kubernetes.io/docs/concepts/security/security-checklist/)
+- [Kubelet Authentication and Authorization](https://kubernetes.io/docs/reference/access-authn-authz/kubelet-authn-authz/)
+- [Authentication](https://kubernetes.io/docs/reference/access-authn-authz/authentication/)
+- [OWASP Kubernetes Security Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Kubernetes_Security_Cheat_Sheet.html)
 
 ## Conformance Tests