Hackers are often hoping to achieve one of three things:<ul><li class="ql-align-justify">To steal data from inside the cluster.</li><li class="ql-align-justify">To harness the computational power of the cluster (e.g. cryptocurrency mining).</li><li class="ql-align-justify">To cause a distributed denial of service (DDoS) attack.</li></ul>

Understanding the Attacker's Objectives

Improve the general security of the pod by adding relevant security context configs in the pod deployment. This can include things like:<ul><li class="ql-align-justify">Disallowing Privilege Escalation</li><li class="ql-align-justify">Requiring the Pod/Container to Run as a Non-Root User</li><li class="ql-align-justify">Requiring Read-Only File System Access on the Local Node</li></ul>

Harden the Pod by Including Security Context Configs in the Pod

Enough said. Using third-party tools to regularly scan the security and integrity of the environment is very helpful. This can include things like checking YAML manifests for exposures.

Use Third-Party Tools to Regularly Scan and Monitor the Kubernet

This is an essential part of any cybersecurity process. Kubernetes, like any other platform and software, requires regular maintenance. Pay attention to updates and patch accordingly.

Regularly maintain and update the Kubernetes environment itself

K8 security is a very broad/deep topic but here are some general best practices and considerations.

Kubernetes Security Basics 

A lot of examples and lab exercises in K8 focus on stateless applications. That's cool, but in this deepstash, we'll explore two options for data storage:<ul><li class="ql-align-justify">Database Storage</li><li class="ql-align-justify">Kubernetes Persistent Volumes</li></ul>

Data storage options in Kubernetes

One approach would be to store the data in a database independent of your cluster.Example: A MySQL or PostgreSQL database running on a server that is separate from your cluster. Alternatively, you could leverage a managed database service like Azure SQL, Amazon RDS, etc.

Technique #1: Database

Another approach would be to use Kubernetes Persistent Volumes. This is a type of data storage that exists in the cluster and remains even after a pod is destroyed. You can use a Kubernetes object called a "stateful set" to ensure that your updated application can communicate with the same volume as the previous pod.

Technique #2: Kubernetes Persistent Volumes

A quick primer on popular data storage techniques for kubernetes applications

Popular data storage options for Kubernetes

Remember the previous analogy about the Kubernetes control plane being like an air traffic control tower? Think of a worker node as an airport terminal where planes park and passengers board.

Think of a Worker Node as an Airport Terminal

This is to help ensure that the cluster is highly available and resilient to issues/outages.

Most Kubernetes clusters run with a minimum of three worker nodes.

<ul><li class="ql-align-justify">Kubelet</li><li class="ql-align-justify">Container Runtime</li><li class="ql-align-justify">Kube-proxy</li></ul>

Each worker node has three components

The Kubelet is responsible for making sure that containers in a pod are running and healthy.The Kubelet communicates directly with the API server in the control plane.

The Kubelet is an agent that runs on every worker node.

The Container Runtime Interface (CRI) can create containers with the engines: <ul><li class="ql-align-justify">Containerd</li><li class="ql-align-justify">CRI-O</li><li class="ql-align-justify">Kata Containers</li><li class="ql-align-justify">AWS Firecracker</li></ul>

The container runtime enables the kublet to create containers locally.

It makes sure pods and services can communicate with other pods and services on nodes and in the control plane. Each kube-proxy communicates directly with the Kube-apiserver.

The kube proxy helps the worker node communicate with peers

A brief walk-through of the Kubernetes worker node architecture.

Kubernetes Worker Node Overview

Each cluster has a control plane and at least one worker node.

An instance of Kubernetes is called a "cluster"

The control plane helps with overlooking the cluster to make sure nodes and pods are created, modified, and deleted without any issues.

Think of the "control plane" like air traffic control at a busy airport.

<ul><li class="ql-align-justify">API Server</li><li class="ql-align-justify">etcd</li><li class="ql-align-justify">Kube scheduler</li><li class="ql-align-justify">Kube controller manager</li><li class="ql-align-justify">Cloud controller manager</li></ul>

The control plane consists of several components

The API Server component exposes the Kubernetes API. kubectl and kubeadm are CLI tools used to communicate with the Kubernetes API via HTTP requests.

API Server

The etcd component saves all data about the state of the cluster. Only the Kube API server can communicate directly with etcd.

etcd

The Kube scheduler component identifies newly created pods that have not been assigned a worker node and then chooses a node for the pod to run on.

Kube Scheduler

The Kubernetes Controller Manager component is a loop that runs continuously and checks the status of a cluster to make sure everything is running properly.

Kubernetes Controller Manager

The Cloud Controller Manager component allows the cluster to connect with a cloud provider's API, allowing you to use cloud resources from AWS, GCP, Azure, or any public cloud.

Cloud Controller Manager

A brief walk-through of the components that make up the Kubernetes control plane. 

Kubernetes Security Basics

Popular data storage options for Kubernetes

Kubernetes Worker Node Overview

Kubernetes Control Plane Components

Mike Berggren