Kubernetes is the Greek word for helmsman or pilot. It is now accelerating the digital transformation at firms by helping them transition away from legacy technology and embrace cloud-native software development. The recent KubeCon event had a gathering of more than 12,000 developers and executives from around the world in San Diego. Every company wants to take advantage of Kubernetes and its ability to automatically deploy, manage, and scale software workloads in the cloud.

The cloud dynamics are changing, and cloud applications are now running increasingly adopting containerization with a microservices architecture. The containers act as separate entities and are not tied down to any piece of hardware, and they can run nearly anywhere and on any machine, across different clouds and servers. Gartner’s report states that more than 75% of global companies will run containerized applications by 2022. Indeed, Kubernetes has become the de-facto standard platform for running and managing containers across the firms.

No doubt, Kubernetes has already won the orchestration competition with others. However, the companies are still hesitant to use Kubernetes not just because it has a steep learning curve, but because of the security concerns. Security remains one of the foremost constraints while working with containers and Kubernetes. In this DevSecOps era, organizations can’t compromise and neglect security as an afterthought if they want to unlock the benefits of cloud-native technologies.

In this article, we will take a deep dive into different areas of Kubernetes security and provide practical recommendations to help you build a resilient cloud-native infrastructure.

The most recent security flaw, which was discovered, is in the Kubernetes kubectl command-line tool. This flaw can lead attackers to run code on the host machine and can compromise production environments.

In 2018, a severe vulnerability in Kubernetes (CVE-2018–1002105) was disclosed that allows an unauthorized and unauthenticated user to gain full admin privileges on a cluster and perform privilege escalation. With this, attackers might easily be able to gain access to Pods in all namespaces, bring down the whole cluster or inject malicious code, etc. However, the issue got fixed in Kubernetes version v1.10.11, v1.11.5, v1.12.3.

In one more incident, a security firm RedLock said that hackers accessed one of Tesla’s Amazon cloud accounts, and they used it to run cryptocurrency-mining malware. The initial point of entry for the Tesla cloud breach was an unsecured administrative console for Kubernetes.

Pod Security policies have been created to limit and define what can be run on a Kubernetes cluster. Some things usually developers might want to limit to restrict unauthorized access to, such as pods that have privileged access, access to the host network, or have access to the host processes, etc. A pod security policy is set at a cluster-level, and this controls the security aspects of the pod. To be accepted into the system, the PodSecurityPolicy defines a set of constraints for a pod. In addition to this, you should also have a Kubernetes Docker Registry to provision your k8s cluster with the charts and images needed to orchestrate your application for more security purposes.

According to the Kubernetes docs:

Kubernetes supports multiple virtual clusters backed by the same physical cluster. These virtual clusters are called namespaces. Note that namespaces are logical isolations, but networking between them is still allowed. To complete the security isolation, we need to use NetworkPolicy or service mesh tools like Istio or Linkerd to enforce the networking isolations too.

The namespace can be visualized as a virtual cluster inside a Kubernetes cluster, and there can be multiple namespaces inside a Kubernetes cluster. These are all logically separated from each other and each potentially with different constraints. It helps in organizing and grouping objects within a cluster, so we will be able to filter and control them as a unit.

You need to define Kubernetes namespaces because namespaces help to divide the cluster resources and quotas between multiple users and teams. So basically, Kubernetes Namespaces help to manage your Kubernetes resources much easier.

RollingUpdate is the preferable update strategy for deployments that ensures that the homogeneous set of pods are always up and running at all times.

This strategy aims to prevent application downtime while performing the updates. Old pods are specified to shutdown after new pods of the new deployment version have started-up and became ready to handle the traffic.

In this deployment strategy, you can set maxUnavailable and maxSurge to pods.

A rolling update waits for new pods to become ready before it starts scaling down the old ones. If there arises any problem, the rolling update can be stopped without bringing the whole cluster down, and that is one crucial fact about rolling updates while considering security in Kubernetes deployment practices.

Also, the rolling updates provide the ability to help the accessed user to roll out the new images. Deployment provides more functionalities, such as rollback support. If you are not using a managed service like Kubernetes, you can still use the rolling update or node pools method with your own cluster to upgrade nodes. (Source: cloud.google.com)

RBAC allows Kubernetes architects to specify which types of actions are permitted for a user and what kind of tasks they are going to perform depending on their role in the organization

This is how you create roles based on the different kinds of access your users and applications need to various resources, and later assign only the required and minimum permissions for appropriate access to the roles. Minimum or restricting access to only specified and well-identified users who must perform defined actions on a resource is critical in securing your cluster and is one of the security best practices.

To tighten the security and ease handling a large number of accounts, RBAC makes use of an intermediate item called binding. Via role binding mechanism, you can create “roles,” which will have a set of capabilities, then assign each user one or more roles.

For example, some users might just have permission to list pods, and some other users may have permission to get, list, watch, create, update, patch, delete pods.

A Kubernetes Secret is created to keep sensitive information (key-value pairs and metadata) such as username and password, SSH keys, certificates, tokens for connecting with other pods, and other authentication factors the web service needs to run efficiently. Handling secrets has always been challenging in applications, and putting sensitive information in a Secret object allows developers for better application and control security.

You can create custom secrets and tell the pods to use these custom secrets along with the native Secrets provided by Kubernetes. You can make use of these Secrets to deploy a web service across multiple clusters easily.

According to the CNCF blog, Kubernetes audit logs are detailed descriptions of each call made to the Kubernetes API-Server.

An audit trail is a log of the chronological events that happened over a given time on a system. It helps administrators and architects understand which event occurred, what exactly happened, when did it take place, and what triggered the event. In a Kubernetes system, the same theory applies, and the audit trail can be used to investigate and debug issues, fine-tune permissions, control user-based access, understand the way the system is being used, etc.

Audit logs are organized and fetched in JSON, and each log contains rich metadata with all related key attributes.

Kubernetes administrators are recommended to define audit policies to strengthen the security because audit policies allow the definition of a set of rules which act on the mentioned/conditioned events and determine the level of data that needs to be logged.

Just like any application, Kubernetes is continuously updating new features and security updates. Hence, it is imperative that the underlying nodes and Kubernetes clusters need to be in parallel and up to date as well.

The standard “zonal” Kubernetes Engine clusters will have only one master node backing them, but you can create “regional” clusters that provide multi-zone feature, highly available masters. One crucial thing to remember here is, while creating a cluster, be sure to select the “regional” option.

By using Kubernetes Engine, you can keep your Kubernetes cluster up to date with just a few clicks. It is highly recommended to use Kubernetes Engine regional clusters for the high-availability masters and automatic node upgrades to have a hassle-free upgrade experience. (Source: cloud.google.com)

For example, the Kubernetes Patch Release Team recently (in 2019) released new builds to patch Kubernetes vulnerabilities for CVE-2019–16276 and CVE-2019–11253, and these vulnerabilities have the potential to cause damage under some Kubernetes configurations. Hence it is highly recommended upgrading to Kubernetes builds and clusters to the latest version regardless of your Kubernetes configuration.

The way that we create, manage, and ship software and applications have completely changed. Every software powered organization wants to be on the edge of software evolution and make use of the latest cloud technology like Kubernetes. When firms think about DevOps, they think of cloud-native technology, and security has been the utmost priority while using Kubernetes, and it is vital to take care of the above-mentioned security best practices while using Kubernetes.

Previously published at https://codeburst.io/7-kubernetes-security-best-practices-you-must-follow-ae32f1ed6444