Kubernetes is the dominant container orchestration solution. The genius of Kubernetes is its ability to provide you with a framework to run distributed systems resiliently. However, it introduces a level of complexity that can be overwhelming. By following Kubernetes best practices for security, reliability, efficiency and monitoring, teams can set themselves up for a successful transition. In a series of blog posts, we’ll cover each of these topics, starting with security.
Let’s look at three common security challenges, and how to overcome them.
Kubernetes responds well to bursts in traffic – whether good or bad. In the event you see a legitimate burst of traffic, Kubernetes will scale up to meet the increase in demand. Your application will consume more resources in your cluster without any degradation of performance. That’s a major benefit. However, in the event of a denial-of-service (DoS) attack, Kubernetes will do exactly the same thing, and you’ll pay for that traffic overload.
The easiest way to deploy a new application or provision a new user is to give away admin permissions. But it’s also the most dangerous way - if an attacker gains access to that account, they’ll have access to everything.
RBAC allows you to grant users granular access to Kubernetes API resources. You should define access profiles usingRolesorClusterRoles.UsingRoles,you’ll grant access to a single namespace. WithClusterRoles,you can grant access to resources without namespaces, likeNodesandPersistentVolumesas well as all namespaced resources.
While RBAC configuration can be confusing and verbose, tools like rbac-manager can help simplify the syntax. This helps prevent mistakes and provides a clearer sense for who has access to what.
The end result? By only granting workloads the permissions they need to do their job, you’ll limit the amount of damage an attacker can do to your Kubernetes environment.
If you are using Kubernetes infrastructure-as-code (IaC) patterns, you benefit from having a completely reproducible environment. But there's a catch - part of your infrastructure likely includes KubernetesSecrets,which store and manage sensitive information, such as passwords, OAuth tokens, and ssh keys. And you shouldn't be addingSecretsto your IaC repository.
It's tempting to check your KubernetesSecretsinto your infrastructure-as-code repository so that your builds are 100% reproducible. But if you care about security, don't. Once checked in, yourSecretsare permanently exposed to anyone with access to your Git repository.
The solution is to split the difference: encrypt all your secrets so you can safely check them into your repository without fear of exposing them. Then you'll then only need access to a single encryption key to "unlock" your IaC repository, and have perfectly reproducible infrastructure. Open source tools like Mozilla’s SOPS can help with this.
You can read more Kubernetes security best practices by checking out how we implement security for our customer’s managed Kubernetes deployments.
You can also check out Kubernetes Best Practices around efficiency. Looking for a complete Kubernetes governance platform? Fairwinds Insights is available for free. Get started today.
