HackTricks
Search…
Pentesting
Powered By GitBook
Pentesting Kubernetes
The original author of this page is Jorge (read his original post here)

Architecture & Basics

What does Kubernetes do?

    Allows running container/s in a container engine.
    Schedule allows containers mission efficient.
    Keep containers alive.
    Allows container communications.
    Allows deployment techniques.
    Handle volumes of information.

Architecture

    Node: operating system with pod or pods.
      Pod: Wrapper around a container or multiple containers with. A pod should only contain one application (so usually, a pod run just 1 container). The pod is the way kubernetes abstracts the container technology running.
        Service: Each pod has 1 internal IP address from the internal range of the node. However, it can be also exposed via a service. The service has also an IP address and its goal is to maintain the communication between pods so if one dies the new replacement (with a different internal IP) will be accessible exposed in the same IP of the service. It can be configured as internal or external. The service also actuates as a load balancer when 2 pods are connected to the same service. When a service is created you can find the endpoints of each service running kubectl get endpoints
    Kubelet: Primary node agent. The component that establishes communication between node and kubectl, and only can run pods (through API server). The kubelet doesn’t manage containers that were not created by Kubernetes.
    Kube-proxy: is the service in charge of the communications (services) between the apiserver and the node. The base is an IPtables for nodes. Most experienced users could install other kube-proxies from other vendors.
    Sidecar container: Sidecar containers are the containers that should run along with the main container in the pod. This sidecar pattern extends and enhances the functionality of current containers without changing them. Nowadays, We know that we use container technology to wrap all the dependencies for the application to run anywhere. A container does only one thing and does that thing very well.
    Master process:
      Api Server: Is the way the users and the pods use to communicate with the master process. Only authenticated request should be allowed.
      Scheduler: Scheduling refers to making sure that Pods are matched to Nodes so that Kubelet can run them. It has enough intelligence to decide which node has more available resources the assign the new pod to it. Note that the scheduler doesn't start new pods, it just communicate with the Kubelet process running inside the node, which will launch the new pod.
      Kube Controller manager: It checks resources like replica sets or deployments to check if, for example, the correct number of pods or nodes are running. In case a pod is missing, it will communicate with the scheduler to start a new one. It controls replication, tokens, and account services to the API.
      etcd: Data storage, persistent, consistent, and distributed. Is Kubernetes’s database and the key-value storage where it keeps the complete state of the clusters (each change is logged here). Components like the Scheduler or the Controller manager depends on this date to know which changes have occurred (available resourced of the nodes, number of pods running...)
    Cloud controller manager: Is the specific controller for flow controls and applications, i.e: if you have clusters in AWS or OpenStack.
Note that as the might be several nodes (running several pods), there might also be several master processes which their access to the Api server load balanced and their etcd synchronized.

Volumes:

When a pod creates data that shouldn't be lost when the pod disappear it should be stored in a physical volume. Kubernetes allow to attach a volume to a pod to persist the data. The volume can be in the local machine or in a remote storage. If you are running pods in different physical nodes you should use a remote storage so all the pods can access it.

Other configurations:

    ConfigMap: You can configure URLs to access services. The pod will obtain data from here to know how to communicate with the rest of the services (pods). Note that this is not the recommended place to save credentials!
    Secret: This is the place to store secret data like passwords, API keys... encoded in B64. The pod will be able to access this data to use the required credentials.
    Deployments: This is where the components to be run by kubernetes are indicated. A user usually won't work directly with pods, pods are abstracted in ReplicaSets (number of same pods replicated), which are run via deployments. Note that deployments are for stateless applications. The minimum configuration for a deployment is the name and the image to run.
    StatefulSet: This component is meant specifically for applications like databases which needs to access the same storage.
    Ingress: This is the configuration that is use to expose the application publicly with an URL. Note that this can also be done using external services, but this is the correct way to expose the application.
      If you implement an Ingress you will need to create Ingress Controllers. The Ingress Controller is a pod that will be the endpoint that will receive the requests and check and will load balance them to the services. the ingress controller will send the request based on the ingress rules configured. Note that the ingress rules can point to different paths or even subdomains to different internal kubernetes services.
        A better security practice would be to use a cloud load balancer or a proxy server as entrypoint to don't have any part of the Kubernetes cluster exposed.
        When request that doesn't match any ingress rule is received, the ingress controller will direct it to the "Default backend". You can describe the ingress controller to get the address of this parameter.
        minikube addons enable ingress

PKI infrastructure - Certificate Authority CA:

    CA is the trusted root for all certificates inside the cluster.
    Allows components to validate to each other.
    All cluster certificates are signed by the CA.
    ETCd has its own certificate.
    types:
      apiserver cert.
      kubelet cert.
      scheduler cert.

Minikube

Minikube can be used to perform some quick tests on kubernetes without needing to deploy a whole kubernetes environment. It will run the master and node processes in one machine. Minikube will use virtualbox to run the node. See here how to install it.
1
$ minikube start
2
😄 minikube v1.19.0 on Ubuntu 20.04
3
✨ Automatically selected the virtualbox driver. Other choices: none, ssh
4
💿 Downloading VM boot image ...
5
> minikube-v1.19.0.iso.sha256: 65 B / 65 B [-------------] 100.00% ? p/s 0s
6
> minikube-v1.19.0.iso: 244.49 MiB / 244.49 MiB 100.00% 1.78 MiB p/s 2m17.
7
👍 Starting control plane node minikube in cluster minikube
8
💾 Downloading Kubernetes v1.20.2 preload ...
9
> preloaded-images-k8s-v10-v1...: 491.71 MiB / 491.71 MiB 100.00% 2.59 MiB
10
🔥 Creating virtualbox VM (CPUs=2, Memory=3900MB, Disk=20000MB) ...
11
🐳 Preparing Kubernetes v1.20.2 on Docker 20.10.4 ...
12
▪ Generating certificates and keys ...
13
▪ Booting up control plane ...
14
▪ Configuring RBAC rules ...
15
🔎 Verifying Kubernetes components...
16
▪ Using image gcr.io/k8s-minikube/storage-provisioner:v5
17
🌟 Enabled addons: storage-provisioner, default-storageclass
18
🏄 Done! kubectl is now configured to use "minikube" cluster and "default" namespace by defaul
19
​
20
$ minikube status
21
host: Running
22
kubelet: Running
23
apiserver: Running
24
kubeconfig: Configured
25
​
26
---- ONCE YOU HAVE A K8 SERVICE RUNNING WITH AN EXTERNAL SERVICE -----
27
$ minikube service mongo-express-service
28
(This will open your browser to access the service exposed port)
29
​
30
$ minikube delete
31
🔥 Deleting "minikube" in virtualbox ...
32
💀 Removed all traces of the "minikube" cluster
Copied!

Kubectl Basics

Kubectl is the command line tool fro kubernetes clusters. It communicates with the Api server of the master process to perform actions in kubernetes or to ask for data.
1
kubectl version #Get client and server version
2
kubectl get pod
3
kubectl get services
4
kubectl get deployment
5
kubectl get replicaset
6
kubectl get secret
7
kubectl get all
8
kubectl get ingress
9
kubectl get endpoints
10
​
11
#kubectl create deployment <deployment-name> --image=<docker image>
12
kubectl create deployment nginx-deployment --image=nginx
13
#Access the configuration of the deployment and modify it
14
#kubectl edit deployment <deployment-name>
15
kubectl edit deployment nginx-deployment
16
#Get the logs of the pod for debbugging (the output of the docker container running)
17
#kubectl logs <replicaset-id/pod-id>
18
kubectl logs nginx-deployment-84cd76b964
19
#kubectl describe pod <pod-id>
20
kubectl describe pod mongo-depl-5fd6b7d4b4-kkt9q
21
#kubectl exec -it <pod-id> -- bash
22
kubectl exec -it mongo-depl-5fd6b7d4b4-kkt9q -- bash
23
#kubectl describe service <service-name>
24
kubectl describe service mongodb-service
25
#kubectl delete deployment <deployment-name>
26
kubectl delete deployment mongo-depl
27
#Deploy from config file
28
kubectl apply -f deployment.yml
Copied!

YAML configuration files examples

Each configuration file has 3 parts: metadata, specification (what need to be launch), status (desired state). Inside the specification of the deployment configuration file you can find the template defined with a new configuration structure defining the image to run:

Example of Deployment + Service declared in the same configuration file (from here)

As a service usually is related to one deployment it's possible to declare both in the same configuration file (the service declared in this config is only accessible internally):
1
apiVersion: apps/v1
2
kind: Deployment
3
metadata:
4
name: mongodb-deployment
5
labels:
6
app: mongodb
7
spec:
8
replicas: 1
9
selector:
10
matchLabels:
11
app: mongodb
12
template:
13
metadata:
14
labels:
15
app: mongodb
16
spec:
17
containers:
18
- name: mongodb
19
image: mongo
20
ports:
21
- containerPort: 27017
22
env:
23
- name: MONGO_INITDB_ROOT_USERNAME
24
valueFrom:
25
secretKeyRef:
26
name: mongodb-secret
27
key: mongo-root-username
28
- name: MONGO_INITDB_ROOT_PASSWORD
29
valueFrom:
30
secretKeyRef:
31
name: mongodb-secret
32
key: mongo-root-password
33
---
34
apiVersion: v1
35
kind: Service
36
metadata:
37
name: mongodb-service
38
spec:
39
selector:
40
app: mongodb
41
ports:
42
- protocol: TCP
43
port: 27017
44
targetPort: 27017
Copied!

Example of external service config

This service will be accessible externally (check the nodePort and type: LoadBlancer attributes):
1
---
2
apiVersion: v1
3
kind: Service
4
metadata:
5
name: mongo-express-service
6
spec:
7
selector:
8
app: mongo-express
9
type: LoadBalancer
10
ports:
11
- protocol: TCP
12
port: 8081
13
targetPort: 8081
14
nodePort: 30000
Copied!
This is useful for testing but for production you should have only internal services and an Ingress to expose the application.

Example of Ingress config file

This will expose the application in http://dashboard.com.
1
apiVersion: networking.k8s.io/v1
2
kind: Ingress
3
metadata:
4
name: dashboard-ingress
5
namespace: kubernetes-dashboard
6
spec:
7
rules:
8
- host: dashboard.com
9
http:
10
paths:
11
- backend:
12
serviceName: kubernetes-dashboard
13
servicePort: 80
Copied!

Example of secrets config file

Note how the password are encoded in B64 (which isn't secure!)
1
apiVersion: v1
2
kind: Secret
3
metadata:
4
name: mongodb-secret
5
type: Opaque
6
data:
7
mongo-root-username: dXNlcm5hbWU=
8
mongo-root-password: cGFzc3dvcmQ=
Copied!

Example of ConfigMap

A ConfigMap is the configuration that is given to the pods so they know how to locate and access other services. In this case, each pod will know that the name mongodb-service is the address of a pod that they can communicate with (this pod will be executing a mongodb):
1
apiVersion: v1
2
kind: ConfigMap
3
metadata:
4
name: mongodb-configmap
5
data:
6
database_url: mongodb-service
Copied!
Then, inside a deployment config this address can be specified in the following way so it's loaded inside the env of the pod:
1
[...]
2
spec:
3
[...]
4
template:
5
[...]
6
spec:
7
containers:
8
- name: mongo-express
9
image: mongo-express
10
ports:
11
- containerPort: 8081
12
env:
13
- name: ME_CONFIG_MONGODB_SERVER
14
valueFrom:
15
configMapKeyRef:
16
name: mongodb-configmap
17
key: database_url
18
[...]
Copied!

Example of volume config

You can find different example of storage configuration yaml files in https://gitlab.com/nanuchi/youtube-tutorial-series/-/tree/master/kubernetes-volumes. Note that volumes aren't inside namespaces

Namespaces

Kubernetes supports multiple virtual clusters backed by the same physical cluster. These virtual clusters are called namespaces. These are intended for use in environments with many users spread across multiple teams, or projects. For clusters with a few to tens of users, you should not need to create or think about namespaces at all. You only should start using namespaces to have a better control and organization of each part of the application deployed in kubernetes.
Namespaces provide a scope for names. Names of resources need to be unique within a namespace, but not across namespaces. Namespaces cannot be nested inside one another and each Kubernetes resource can only be in one namespace.
There are 4 namespaces by default if you are using minikube:
1
kubectl get namespace
2
NAME STATUS AGE
3
default Active 1d
4
kube-node-lease Active 1d
5
kube-public Active 1d
6
kube-system Active 1d
Copied!
    kube-system: It's not meant or the users use and you shouldn't touch it. It's for master and kubectl processes.
    kube-public: Publicly accessible date. Contains a configmap which contains cluster information
    kube-node-lease: Determines the availability of a node
    default: The namespace the user will use to create resources
1
#Create namespace
2
kubectl create namespace my-namespace
Copied!
Note that most Kubernetes resources (e.g. pods, services, replication controllers, and others) are in some namespaces. However, other resources like namespace resources and low-level resources, such as nodes and persistenVolumes are not in a namespace. To see which Kubernetes resources are and aren’t in a namespace:
1
kubectl api-resources --namespaced=true #In a namespace
2
kubectl api-resources --namespaced=false #Not in a namespace
Copied!
You can save the namespace for all subsequent kubectl commands in that context.
1
kubectl config set-context --current --namespace=<insert-namespace-name-here>
Copied!

Helm

Helm is the package manager for Kubernetes. It allows to package YAML files and distribute them in public and private repositories. These packages are called Helm Charts.
1
helm search <keyword>
Copied!
Helm is also a template engine that allows to generate config files with variables:

Pentesting Kubernetes from the outside

Vulnerabilities and misconfigurations

Enumeration inside a Pod

If you manage to compromise a Pod read the following page to learn how to enumerate and try to escalate privileges/escape:

Kubernetes secrets

A Secret is an object that contains sensitive data such as a password, a token or a key. Such information might otherwise be put in a Pod specification or in an image. Users can create Secrets and the system also creates Secrets. The name of a Secret object must be a valid DNS subdomain name. Read here the official documentation.
Secrets might be things like:
    API, SSH Keys.
    OAuth tokens.
    Credentials, Passwords (plain text or b64 + encryption).
    Information or comments.
    Database connection code, strings… .
There are different types of secrets in Kubernetes
Builtin Type
Usage
Opaque
arbitrary user-defined data (Default)
kubernetes.io/service-account-token
service account token
kubernetes.io/dockercfg
serialized ~/.dockercfg file
kubernetes.io/dockerconfigjson
serialized ~/.docker/config.json file
kubernetes.io/basic-auth
credentials for basic authentication
kubernetes.io/ssh-auth
credentials for SSH authentication
kubernetes.io/tls
data for a TLS client or server
bootstrap.kubernetes.io/token
bootstrap token data
The Opaque type is the default one, the typical key-value pair defined by users.
How secrets works:
The following configuration file defines a secret called mysecret with 2 key-value pairs username: YWRtaW4= and password: MWYyZDFlMmU2N2Rm. It also defines a pod called secretpod that will have the username and password defined in mysecret exposed in the environment variables SECRET_USERNAME and SECRET_PASSWOR. It will also mount the username secret inside mysecret in the path /etc/foo/my-group/my-username with 0640 permissions.
secretpod.yaml
1
apiVersion: v1
2
kind: Secret
3
metadata:
4
name: mysecret
5
type: Opaque
6
data:
7
username: YWRtaW4=
8
password: MWYyZDFlMmU2N2Rm
9
---
10
apiVersion: v1
11
kind: Pod
12
metadata:
13
name: secretpod
14
spec:
15
containers:
16
- name: secretpod
17
image: nginx
18
env:
19
- name: SECRET_USERNAME
20
valueFrom:
21
secretKeyRef:
22
name: mysecret
23
key: username
24
- name: SECRET_PASSWORD
25
valueFrom:
26
secretKeyRef:
27
name: mysecret
28
key: password
29
volumeMounts:
30
- name: foo
31
mountPath: "/etc/foo"
32
restartPolicy: Never
33
volumes:
34
- name: foo
35
secret:
36
secretName: mysecret
37
items:
38
- key: username
39
path: my-group/my-username
40
mode: 0640
Copied!
1
kubectl apply -f <secretpod.yaml>
2
kubectl get pods #Wait until the pod secretpod is running
3
kubectl exec -it secretpod -- bash
4
env | grep SECRET && cat /etc/foo/my-group/my-username && echo
Copied!

Secrets in etcd

etcd is a consistent and highly-available key-value store used as Kubernetes backing store for all cluster data. Let’s access to the secrets stored in etcd:
1
cat /etc/kubernetes/manifests/kube-apiserver.yaml | grep etcd
Copied!
You will see certs, keys and url’s were are located in the FS. Once you get it, you would be able to connect to etcd.
1
#ETCDCTL_API=3 etcdctl --cert <path to client.crt> --key <path to client.ket> --cacert <path to CA.cert> endpoint=[<ip:port>] health
2
​
3
ETCDCTL_API=3 etcdctl --cert /etc/kubernetes/pki/apiserver-etcd-client.crt --key /etc/kubernetes/pki/apiserver-etcd-client.key --cacert /etc/kubernetes/pki/etcd/etcd/ca.cert endpoint=[127.0.0.1:1234] health
Copied!
Once you achieve establish communication you would be able to get the secrets:
1
#ETCDCTL_API=3 etcdctl --cert <path to client.crt> --key <path to client.ket> --cacert <path to CA.cert> endpoint=[<ip:port>] get <path/to/secret>
2
​
3
ETCDCTL_API=3 etcdctl --cert /etc/kubernetes/pki/apiserver-etcd-client.crt --key /etc/kubernetes/pki/apiserver-etcd-client.key --cacert /etc/kubernetes/pki/etcd/etcd/ca.cert endpoint=[127.0.0.1:1234] get /registry/secrets/default/secret_02
Copied!

Adding encryption to the ETCD

By default all the secrets are stored in plain text inside etcd unless you apply an encryption layer. The following example is based on https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/​
encryption.yaml
1
apiVersion: apiserver.config.k8s.io/v1
2
kind: EncryptionConfiguration
3
resources:
4
- resources:
5
- secrets
6
providers:
7
- aescbc:
8
keys:
9
- name: key1
10
secret: cjjPMcWpTPKhAdieVtd+KhG4NN+N6e3NmBPMXJvbfrY= #Any random key
11
- identity: {}
Copied!
After that, you need to set the --encryption-provider-config flag on the kube-apiserver to point to the location of the created config file. You can modify /etc/kubernetes/manifest/kube-apiserver.yaml and add the following lines:
1
containers:
2
- command:
3
- kube-apiserver
4
- --encriyption-provider-config=/etc/kubernetes/etcd/<configFile.yaml>
Copied!
Scroll down in the volumeMounts:
1
- mountPath: /etc/kubernetes/etcd
2
name: etcd
3
readOnly: true
Copied!
Scroll down in the volumeMounts to hostPath:
1
- hostPath:
2
path: /etc/kubernetes/etcd
3
type: DirectoryOrCreate
4
name: etcd
Copied!

Verifying that data is encrypted

Data is encrypted when written to etcd. After restarting your kube-apiserver, any newly created or updated secret should be encrypted when stored. To check, you can use the etcdctl command line program to retrieve the contents of your secret.
    1.
    Create a new secret called secret1 in the default namespace:
    1
    kubectl create secret generic secret1 -n default --from-literal=mykey=mydata
    Copied!
    2.
    Using the etcdctl commandline, read that secret out of etcd:
    ETCDCTL_API=3 etcdctl get /registry/secrets/default/secret1 [...] | hexdump -C
    where [...] must be the additional arguments for connecting to the etcd server.
    3.
    Verify the stored secret is prefixed with k8s:enc:aescbc:v1: which indicates the aescbc provider has encrypted the resulting data.
    4.
    Verify the secret is correctly decrypted when retrieved via the API:
    1
    kubectl describe secret secret1 -n default
    Copied!
    should match mykey: bXlkYXRh, mydata is encoded, check decoding a secret to completely decode the secret.
Since secrets are encrypted on write, performing an update on a secret will encrypt that content:
1
kubectl get secrets --all-namespaces -o json | kubectl replace -f -
Copied!

Final tips:

RBAC Hardening

Kubernetes has an authorization module named Role-Based Access Control (RBAC) that helps to set utilization permissions to the API server. The RBAC table is constructed from “Roles” and “ClusterRoles.” The difference between them is just where the role will be applied – a “Role” will grant access to only one specific namespace, while a “ClusterRole” can be used in all namespaces in the cluster. Moreover, ClusterRoles can also grant access to:
    cluster-scoped resources (like nodes).
    non-resource endpoints (like /healthz).
    namespaced resources (like Pods), across all namespaces.
Example of Role configuration:
1
apiVersion: rbac.authorization.k8s.io/v1
2
kind: Role
3
metadata:
4
namespace: defaultGreen
5
name: pod-and-pod-logs-reader
6
rules:
7
- apiGroups: [""]
8
resources: ["pods", "pods/log"]
9
verbs: ["get", "list", "watch"]
Copied!
Example of ClusterRole configuration:
For example you can use a ClusterRole to allow a particular user to run:
1
kubectl get pods --all-namespaces
Copied!
1
apiVersion: rbac.authorization.k8s.io/v1
2
kind: ClusterRole
3
metadata:
4
# "namespace" omitted since ClusterRoles are not namespaced
5
name: secret-reader
6
rules:
7
- apiGroups: [""]
8
resources: ["secrets"]
9
verbs: ["get", "watch", "list"]
Copied!
Role and ClusterRole Binding concept
A role binding grants the permissions defined in a role to a user or set of users. It holds a list of subjects (users, groups, or service accounts), and a reference to the role being granted. A RoleBinding grants permissions within a specific namespace whereas a ClusterRoleBinding grants that access cluster-wide.
RoleBinding example:
1
apiVersion: rbac.authorization.k8s.io/v1
2
# This role binding allows "jane" to read pods in the "default" namespace.
3
# You need to already have a Role named "pod-reader" in that namespace.
4
kind: RoleBinding
5
metadata:
6
name: read-pods
7
namespace: default
8
subjects:
9
# You can specify more than one "subject"
10
- kind: User
11
name: jane # "name" is case sensitive
12
apiGroup: rbac.authorization.k8s.io
13
roleRef:
14
# "roleRef" specifies the binding to a Role / ClusterRole
15
kind: Role #this must be Role or ClusterRole
16
name: pod-reader # this must match the name of the Role or ClusterRole you wish to bind to
17
apiGroup: rbac.authorization.k8s.io
Copied!
ClusterRoleBinding example:
1
apiVersion: rbac.authorization.k8s.io/v1
2
# This cluster role binding allows anyone in the "manager" group to read secrets in any namespace.
3
kind: ClusterRoleBinding
4
metadata:
5
name: read-secrets-global
6
subjects:
7
- kind: Group
8
name: manager # Name is case sensitive
9
apiGroup: rbac.authorization.k8s.io
10
roleRef:
11
kind: ClusterRole
12
name: secret-reader
13
apiGroup: rbac.authorization.k8s.io
Copied!
Permissions are additive so if you have a clusterRole with “list” and “delete” secrets you can add it with a Role with “get”. So be aware and test always your roles and permissions and specify what is ALLOWED, because everything is DENIED by default.

RBAC Structure

RBAC’s permission is built from three individual parts:
    1.
    Role\ClusterRole ­– The actual permission. It contains rules that represent a set of permissions. Each rule contains resources and verbs. The verb is the action that will apply on the resource.
    2.
    Subject (User, Group or ServiceAccount) – The object that will receive the permissions.
    3.
    RoleBinding\ClusterRoleBinding – The connection between Role\ClusterRole and the subject.
This is what it will look like in a real cluster:
“Fine-grained role bindings provide greater security, but require more effort to administrate."
From Kubernetes 1.6 onwards, RBAC policies are enabled by default. But to enable RBAC you can use something like:
1
kube-apiserver --authorization-mode=Example,RBAC --other-options --more-options
Copied!
This is enabled by default. RBAC functions:
    Restrict the access to the resources to users or ServiceAccounts.
    An RBAC Role or ClusterRole contains rules that represent a set of permissions.
    Permissions are purely additive (there are no “deny” rules).
    RBAC works with Roles and Bindings
When configuring roles and permissions it's highly important to always follow the principle of Least Privileges

Service Accounts Hardening

To learn about Service Accounts Hardenig read the page:

Kubernetes API Hardening

It's very important to protect the access to the Kubernetes Api Server as a malicious actor with enough privileges could be able to abuse it and damage in a lot of way the environment. It's important to secure both the access (whitelist origins to access the API Server and deny any otehr connection) and the authentication (following the principle of least privilege). And definitely never allow anonymous requests.
Common Request process: User or K8s ServiceAccount –> Authentication –> Authorization –> Admission Control.
Tips:
    Close ports.
    Avoid Anonymous access.
    NodeRestriction; No access from specific nodes to the API.
      Basically prevents kubelets from adding/removing/updating labels with a node-restriction.kubernetes.io/ prefix. This label prefix is reserved for administrators to label their Node objects for workload isolation purposes, and kubelets will not be allowed to modify labels with that prefix.
      And also, allows kubelets to add/remove/update these labels and label prefixes.
    Ensure with labels the secure workload isolation.
    Avoid specific pods from API access.
    Avoid ApiServer exposure to the internet.
    Avoid unauthorized access RBAC.
    ApiServer port with firewall and IP whitelisting.

SecurityContext Hardening

By default root user will be used when a Pod is started if no other user is specified. You can run your application inside a more secure context using a template similar to the following one:
1
apiVersion: v1
2
kind: Pod
3
metadata:
4
name: security-context-demo
5
spec:
6
securityContext:
7
runAsUser: 1000
8
runAsGroup: 3000
9
fsGroup: 2000
10
volumes:
11
- name: sec-ctx-vol
12
emptyDir: {}
13
containers:
14
- name: sec-ctx-demo
15
image: busybox
16
command: [ "sh", "-c", "sleep 1h" ]
17
securityContext:
18
runAsNonRoot: true
19
volumeMounts:
20
- name: sec-ctx-vol
21
mountPath: /data/demo
22
securityContext:
23
allowPrivilegeEscalation: true
Copied!

General Hardening

You should update your Kubernetes environment as frequently as necessary to have:
    Dependencies up to date.
    Bug and security patches.
​Release cycles: Each 3 months there is a new minor release -- 1.20.3 = 1(Major).20(Minor).3(patch)
The best way to update a Kubernetes Cluster is (from here):
    Upgrade the Master Node components following this sequence:
      etcd (all instances).
      kube-apiserver (all control plane hosts).
      kube-controller-manager.
      kube-scheduler.
      cloud controller manager, if you use one.
    Upgrade the Worker Node components such as kube-proxy, kubelet.

References

kubesectips v1
sickrov.github.io
​
Last modified 5mo ago