BLOGCloud Security

5 Things That Will Improve Your Kubernetes Security Posture

Category
Cloud Security
Time to read
Published
February 20, 2024
Author

Key Takeaways

Kubernetes offers a variety of security controls, but using a default configuration exposes a wide attack surface and leaves you open and vulnerable to potential risks.

In 2020, nearly 7 out of 10 companies reported a detected misconfiguration in their Kubernetes environment, making it by far the most common type of vulnerability.

2020 State of Containers and Kubernetes Report

Hope isn’t lost if you’re using a default configuration: There are plenty of simple best-practice changes you can make to quickly and easily improve the security posture of your platform.

Here are the top five changes you can make immediately that will have the biggest impact on your overall security posture…

1. Restrict access to the Kubernetes API

The Kubernetes API enables you to query and manipulate the state of all resources within your cluster, so restricting access to it is absolutely essential and where your ‘best-practice security’ should start.

What to do:

  • Enable Role Based Access Control (RBAC) and define least privilege policies per user or service requiring access
  • Externalise the identity (auth0) and authorisation (authn) roles, whilst retaining policy implementation within Kubernetes
  • Restrict access to the API endpoint and control plane Nodes
  • Disable the insecure API server port (Note: This has been disabled in Kubernetes v1.20 so it’ll only be applicable if you’re using an older version)

2. Encrypt data at rest

‘Data at rest’ is structured or unstructured data that is stored in databases, all in one place. It needs to be secured differently than data in motion, which is why Data At Rest Encryption (DARE) should quickly become one of your priorities to improve your overall Kubernetes security posture.

What to do:

3. Enforce least privileged pod security standards

Within a Pod specification, the SecurityContext has a collection of fields that specify security-relevant settings for a Pod. Without enforcement at a cluster level, these settings could be modified to allow a Pod to run under a privileged context, such as running as a root user, on the host network with access to sensitive service endpoints, and able to mount in file paths on the host which may contain secret data.

By using Pod Security Standards or Admission Controllers, you can enforce the use of least privilege SecurityContext settings for all workloads running in the cluster and reject the creation of any Pods that aren't adhering to defined policies.

What to do:

4. Container Image Policies

By default, Kubernetes can pull container images defined in your Pod specifications from any destination, as long as it's reachable from the Node. This introduces the risk that a user (authorised or not) could accidentally or maliciously specify an image to run from an untrusted source, which may cause direct harm to the platform and neighbouring services, resulting in data exfiltration, and increased hosting and auditing costs.

Employing cluster-level image policy controls significantly reduces this risk and can be achieved via the use of custom admission controllers (i.e. OpenPolicyAgent Gatekeeper).

What to do:

5. Implement default network policies

Kubernetes network policies control the traffic between pods and/or network endpoints. The labels you specify in your network policies determine the traffic that is or isn’t directed towards those rules, ensuring that you know exactly what is accessing your clusters.

Without creating any initial policies, by default your workloads can be accessed by anything within the cluster and can reach out to any internal or external endpoints, increasing the risk of data leaks in the event of a breach.

What to do:

  • Create default deny-all network policies for all ingress and egress traffic in all namespaces, and override with least privilege network policies where required for each service.
  • Protect sensitive cluster endpoints from normal workloads (i.e. via the use of global network policies, depending on your implementation and CNI choice), such as the cloud metadata service endpoint and etcd and prevent this being overridden or bypassed by users.
  • Monitor failures, these can be early indications that something is trying to move laterally.

Do you know where you're at risk?

The above recommendations are solid strategies to make your clusters more secure but, depending on the number of clusters involved, there’s potentially a mountain of work ahead of you.

We’ve developed a free 1-day assessment of your Kubernetes clusters to help you determine the relative robustness of your Kubernetes implementation.

After a single-day audit of your clusters carried out by one of our expert architects, you'll receive a PDF of the results along with actionable insights on how to harden your security posture.

Related Posts

Related Resources