Kubernetes Hardening Guide

Organisations all around us, large and small, are adopting or planning to move to Kubernetes. As number of Kubernetes installations grow, the security concerts are going as well.

Thankfully recently NSA published a guide to harden Kubernetes installations. This guide outlines a wide range of important security practices - and can easily be used as a reference for Kubernetes deployments. Here is the Hardening Guide if you're interested in the whole document.

However, the document is more than 50 pages long and depending on reading speed it may need few days to few weeks of reading.

In this post, I attempt to provide a gentle introduction to the paper. We'll take a look at some of the most important security concerns and their remedies, as per the document. Idea is to provide our readers a high level overview and perhaps a checklist of importants aspects to cover when looking at securing a Kubernetes cluster.

Introduction

The document talks about three broad areas for potential compromise in Kubernetes ecosystem - Supply Chain Risks, Malicious Threat Actors, and Insider Threats.

Supply chain risks essentially mean compromised components of the Kubernetes ecosystem, i.e. containers or underlying infrastructure components. Malicious threat actors are external agents or agencies that are interested in exploiting data or compute from your Kubernetes cluster. Finally insider threats are when access privileges given to an internal user is leveraged knowingly or unknowingly for malicious intents.

Supply chain risks are most tricky to mitigate, since the attack surface area is too wide. Attacker can compromise a single element in the entire ecosystem and be able to exploit the cluster. Typical entry points include third party software and  vendors used to create / manage the cluster.

It is important to note here that whatever be attacker's entry point - target is generally get access to critical data. So, fixing the data access points is the preferred approach.

Below is the high level list of patterns and fixes as recommended by the paper.

Recommendations

Kubernetes Pod security

• Use containers built to run applications as non-root users.
• Where possible, run containers with immutable file systems.
• Scan container images for possible vulnerabilities or misconfigurations.
• Use a Pod Security Policy to enforce a minimum level of security including:

1. Preventing privileged containers.
2. Denying container features frequently exploited to breakout, such as hostPID, hostIPC, hostNetwork, allowedHostPath.
3. Rejecting containers that execute as the root user or allow elevation to root
   hardening applications against exploitation using security services such as SELinux®, AppArmor®, and seccomp.

Network separation and hardening

• Lock down access to control plane nodes using a firewall and role-based access control (RBAC).
• Further limit access to the Kubernetes etcd server.
• Configure control plane components to use authenticated, encrypted communications using Transport Layer Security (TLS) certificates.
• Set up network policies to isolate resources. Pods and services in different namespaces can still communicate with each other unless additional separation is enforced, such as network policies.
• Place all credentials and sensitive information in Kubernetes Secrets rather than in configuration files. Encrypt Secrets using a strong encryption method.

Authentication and authorization

• Disable anonymous login (enabled by default).
• Use strong user authentication.
• Create RBAC policies to limit administrator, user, and service account activity.

Log auditing

• Enable audit logging (disabled by default).
• Persist logs to ensure availability in the case of node, Pod, or container level failure.
• Configure a metrics logger.

Upgrading and application security practices

• Immediately apply security patches and updates.
• Perform periodic vulnerability scans and penetration tests.
• Remove components from the environment when they are no longer needed.