Kubernetes

Securing a Kubernetes cluster is not an easy task, but it is not more complicated than securing any cloud environment or even dedicated servers.

As this series of articles is coming to its end, you will find here a security cheat sheet with a simple purpose of listing best practices and advice to protect your production environment when running it on a Kubernetes cluster.

In episode 4, we detailed some of the main security issues that are found into software, and it is no surprise that information leakage is one of the most frequent security flaw.

As you secured your Kubernetes cluster, you defined users, roles, and permissions, making it safer one restriction after the other. Along with user accesses, you also need to control what is being authorized by the services you did not create yourself, and that you depend upon: third parties.

Interactions between software are key to product security. As we are able to isolate components depending on their communication with each other, we can take a step back and think about how we want to design.

Our goal is not to dissect a k8s cluster but to understand what needs to be secured and, most importantly, how.

In this series of articles, we intend to highlight the best practices that any Kubernetes user can put in place by demystifying Kubernetes clusters architecture and security. We will also provide clear guidelines and basic configurations to apply to your clusters to be safer and more secure.