Protecting Important Directories in a Kubernetes Cluster

Kubernetes configuration files such as Kubeconfig, Kubeletconfig, and Kubeadmconfig are fundamental to the operation and security of a Kubernetes cluster. These files contain sensitive information that governs how the cluster operates, how nodes communicate, and how administrators manage resources. Unauthorized access or modification of these configurations can have catastrophic effects, from service disruptions to complete cluster paralysis. Therefore, it is vital to implement strict security measures to protect these files and the directories they reside in. This document details the critical directories that store configuration files, the potential consequences of unauthorized access, and best practices for securing these essential components.

Key Directories Containing Critical Information

By default, the following directories contain important information about the cluster:

/etc/kubernetes/
/var/lib/kubelet/
/etc/sysconfig/kubelet
$HOME/.kube/config.yaml

These directories should be highly restricted as they are only relevant for troubleshooting by administrators.

Consequences of Unauthorized Access or Modification

Cluster Paralysis: Modifying configuration files can disrupt the entire Kubernetes control plane. Changes to Kubeadmconfig can affect cluster initialization, upgrades, and version compatibility.

Service Disruption: Unauthorized modifications to Kubeletconfig can impact the operation of the Kubelet, which is responsible for managing the lifecycle of pods on nodes. This can lead to node failures and service disruptions.

Security Breaches: Accessing Kubeconfig can provide unauthorized users with cluster admin credentials, leading to potential security breaches. This can result in unauthorized deployments, data theft, and loss of control over the cluster.

Configuration Leakage: Exposure of these configuration files can reveal sensitive cluster information, including cluster endpoints, certificates, and API server details. This information can be exploited to perform targeted attacks.

Stricter Access Controls

To mitigate the risks associated with unauthorized access, it is crucial to enforce strict access controls:

Restrict Directory Access:

Ensure that only cluster administrators have read and write permissions to the following directories:

```
chmod -R 700 /etc/kubernetes/
```
```
chmod -R 700 /var/lib/kubelet/
```
```
chmod -R 700 /etc/sysconfig/kubelet
```
```
chmod 700 $HOME/.kube/config.yaml
```

Limit systemctl Access:

The systemctl command can reveal configuration paths using

systemctl cat kubelet

. Limit access to systemctl so that only cluster administrators can execute it:

```
chmod 700 /bin/systemctl
```

Restrict ConfigMap Access:

Configuration files are often mounted in pods via ConfigMaps in the kube-system namespace. Restrict access to these ConfigMaps:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: kube-system
  name: configmap-reader
rules:
- apiGroups: [""]
  resources: ["configmaps"]
  verbs: ["get", "list", "watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  namespace: kube-system
  name: configmap-reader-binding
subjects:
- kind: User
  name: <admin-username>
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: configmap-reader
  apiGroup: rbac.authorization.k8s.io

Use Role-Based Access Control (RBAC):

Implement RBAC to manage access to resources based on user roles. Ensure that non-admin users have minimal permissions:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: view-only
rules:
- apiGroups: [""]
  resources: ["pods", "services"]
  verbs: ["get", "list", "watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: view-only-binding
subjects:
- kind: User
  name: <non-admin-username>
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: view-only
  apiGroup: rbac.authorization.k8s.io

Risks