hacktricks/pentesting/pentesting-kubernetes/kubernetes-hardening

Kubernetes Hardening

Tools

Kube-bench

The tool kube-bench is a tool that checks whether Kubernetes is deployed securely by running the checks documented in the CIS Kubernetes Benchmark.
You can choose to:

• run kube-bench from inside a container (sharing PID namespace with the host)
• run a container that installs kube-bench on the host, and then run kube-bench directly on the host
• install the latest binaries from the Releases page,
• compile it from source.

Kubeaudit

The tool kubeaudit is a command line tool and a Go package to audit Kubernetes clusters for various different security concerns.

Kubeaudit can detect if it is running within a container in a cluster. If so, it will try to audit all Kubernetes resources in that cluster:

kubeaudit all

This tool also has the argument autofix to automatically fix detected issues.

Popeye

Popeye is a utility that scans live Kubernetes cluster and reports potential issues with deployed resources and configurations. It sanitizes your cluster based on what's deployed and not what's sitting on disk. By scanning your cluster, it detects misconfigurations and helps you to ensure that best practices are in place, thus preventing future headaches. It aims at reducing the cognitive _over_load one faces when operating a Kubernetes cluster in the wild. Furthermore, if your cluster employs a metric-server, it reports potential resources over/under allocations and attempts to warn you should your cluster run out of capacity.

Kicks

****KICS finds security vulnerabilities, compliance issues, and infrastructure misconfigurations in the following Infrastructure as Code solutions: Terraform, Kubernetes, Docker, AWS CloudFormation, Ansible, Helm, Microsoft ARM, and OpenAPI 3.0 specifications

Checkov

****Checkov is a static code analysis tool for infrastructure-as-code.

It scans cloud infrastructure provisioned using Terraform, Terraform plan, Cloudformation, AWS SAM, Kubernetes, Dockerfile, Serverless or ARM Templates and detects security and compliance misconfigurations using graph-based scanning.

Monitoring with Falco

{% content-ref url="monitoring-with-falco.md" %} monitoring-with-falco.md {% endcontent-ref %}

Tips

Kubernetes PodSecurityContext and SecurityContext

You can configure the security context of the Pods (with PodSecurityContext) and of the containers that are going to be run (with SecurityContext). For more information read:

{% content-ref url="kubernetes-securitycontext-s.md" %} kubernetes-securitycontext-s.md {% endcontent-ref %}

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 other 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.
  • https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#noderestriction
  • 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:

apiVersion: v1
kind: Pod
metadata:
  name: security-context-demo
spec:
  securityContext:
    runAsUser: 1000
    runAsGroup: 3000
    fsGroup: 2000
  volumes:
  - name: sec-ctx-vol
    emptyDir: {}
  containers:
  - name: sec-ctx-demo
    image: busybox
    command: [ "sh", "-c", "sleep 1h" ]
   securityContext:
    runAsNonRoot: true
    volumeMounts:
    - name: sec-ctx-vol
      mountPath: /data/demo
    securityContext:
      allowPrivilegeEscalation: true

• https://kubernetes.io/docs/tasks/configure-pod-container/security-context/
• https://kubernetes.io/docs/concepts/policy/pod-security-policy/

Kubernetes NetworkPolicies

{% content-ref url="kubernetes-networkpolicies.md" %} kubernetes-networkpolicies.md {% endcontent-ref %}

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.