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.
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.
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:
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.
This article overviews security objects & practices that everyone should know: all these layers of security, what they are called, and what they are used for to secure your cluster.
In this third episode of Kubernetes Security, we are going to think about our applications and software and their security before the production system, right from the start of the design process.
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 on: third parties.
