K8s security - Episode 1: From the Cloud to your code

Managing security in a Kubernetes cluster is a high-stakes challenge for Cloud Solution Providers (CSP) and their customers. They share responsibilities across the CSP, DevOps, Developer teams, partners, and more.

As such, security should be a concern for every stakeholder. Each plays an important role to help protect their development and production environments, the applications running on them, as well as the data stored.

Unfortunately, most people are not aware of what is happening inside their clusters and don't often acknowledge that everyone has to collaborate to ensure the highest possible security levels.

Despite the risks, we often consider security a never-ending struggle that requires specific skills and experience. As a result, we often address security matters when it's already too late.

When you add up the complexity of understanding and using Kubernetes and security concerns, it quickly seems to be a nightmare to manage and too much to process. Besides, the large amount of documentation available makes it sometimes difficult to identify what is appropriate for your specific use case.

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 make them safer and more secure.

Even though these recommendations can appear a bit restrictive, remember that restriction does not allow you to get off-board. You can still dig into the various restrictions afterward to see if you want to remove some of them.

Itinerary through your cluster

Our journey will start from the Cloud to the code, from the initialization of a Kubernetes cluster to the code integration issues and vulnerabilities you might encounter.

Production environments have many layers and items which need to interact with each other in a complex way. This series will cover security issues and provide solutions for each of them. We will try to give you as many insights as possible as to what people should focus on.

The goal of these articles is to clarify each stakeholder's role and responsibilities working on an IT product.

As we do not intend to put you in boxes, we defined five imaginary personae to represent each company's role. These roles are intentionally vague so that you can identify yourself in one or multiple roles.

Even though security matters should concern everyone, we know that some people are more attracted to specific topics. As a result, these personae intend to identify, on each different topic, the affinity of a profile depending on the subject addressed.

How bad is it?

As nobody will deny that security in a production environment is vital, some might ask themselves: how many security issues are we dealing with daily?.

Without even knowing it, vulnerabilities are everywhere. In a straightforward production environment use case or tutorial follow-ups, we find ourselves with security breaches.

We have listed the most common issues we might encounter in a Kubernetes environment, without even noticing them, are as follow:

• The absence of Security Policies: thus not defining access rules to pods running within a cluster
• No Network Policies: Kubernetes namespaces can be protected on a network level by defining interaction rules
• Vulnerable packages: Libraries used in code are rarely up-to-date in terms of security. They often require maintenance to avoid breaches coming from code dependencies and not even our code.
• Data encryption: Even if the usage of Kubernetes is mainly stateless, data is often required, thus stored into remote storage (Block Storage or File Systems). How often are those data encrypted while stored, or even when routing between our network?

Of course, and unfortunately, there is much more to cover. We hope this series will take you on a safe journey from your Cloud to your code.