9 Kubernetes Security Best Practices

Today I was reading an interesting article about the 9 Kubernetes Security Best Practices everyone must follow.

In that article they basically enumerate and briefly describe how to follow and accomplish those 9 security recommendations. I’ve extracted them here for you to simply go quickly through them.

1. Upgrade to the Latest Version

In the article they don’t specify if the order of this list is important, but for me the most obvious things must come first.

Keeping your cluster upgraded is always the first thing you should do.

2. Enable Role-Based Access Control (RBAC)

RBAC is the new access control they introduced in Kubernetes 1.6 and basically allows you to control who can access your API in a more secure and improved way.

Specially after discovering the security issue CVE-2018-1002105

3. Use Namespaces to Establish Security Boundaries

I’ve been using namespaces from my first cluster setup and they’re great to isolate components and even the logic of your different cluster parts.

DevOps guys immediately understand the namespaces and when working with the cluster the can easily focus on the part they want to work with avoiding making mistakes in other namespaces. Deleting a pod for another system part could be a good example of this 😉

Related to security it’s also really handy to be able to apply different security controls based on namespaces.

4. Separate Sensitive Workloads

Sensitive workloads should be ran in dedicated machines, this reduces the risk of an non authorised app accessing that sensitive info.

By using namespaces you can achieve this.

5. Secure Cloud Metadata Access

I thing this recommendation is more focused for GKE environments and any other cloud services, a recent Shopify bug bounty disclosure detailed how a user was able to escalate privileges by confusing a microservice into leaking information from the cloud provider’s metadata service.

They’re still working in a more robust & permanent solution for this.

6. Create and Define Cluster Network Policies

This is something that is purely related with cloud services that allows you to configure network policies for controlling network access into and out of your containerized applications.

However you can always apply same concept in your private cluster, by running them in isolated networks and stablish direct communications only when needed.

7. Run a Cluster-wide Pod Security Policy

A Pod Security Policy sets defaults for how workloads are allowed to run in your cluster. Consider defining a policy and enabling the Pod Security Policy admission controller — instructions vary depending on your cloud provider or deployment model. As a start, you could require that deployments drop the NET_RAW capability to defeat certain classes of network spoofing attacks.

8. Harden Node Security

They put this point at 8th position in their list. In my humble opinion should come at 1st position in this list.

At the end a cluster is a set of nodes orchestrated by Kubernetes, those nodes are just machines and they live in a network environment so hardening your machines should be the most important and the very first thing you must do.

  • Uninstall non required software that is included in the operating system
  • Keep all the software up to date
  • Disable root SSH connections
  • Reduce as much as possible sudo users
  • Install firewall
  • Only expose required ports, close the rest
  • Install tools to track unauthorised login attempts and block them immediately
  • logging, logging, logging ! You need to know what’s happening in your machines, logs all the actions to discover misconfiguration issues, security problems, etc.

Those are some personal recommendations I make for you, of course, depending on your needs, you need to apply more.
Please read this guide to understand server hardening.

9. Turn on Audit Logging

logging, logging, logging !

I told you 😉 the more you know about what’s happening under the hood, the more control you’ll have on your system.

Enable audit log to discover unauthorised API calls or any kind of authorization failures.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Create a website or blog at WordPress.com

Up ↑

%d bloggers like this: