Kubernetes is extremely popular, but without proper security measures, it also comes with risks. Security expert CyberArk names three specific risks and shows which defensive measures are required to get hardware, API server and container risks in Kubernetes under control.
In software development today, speed and agility are key. Container technology is being used to an increasing extent. Kubernetes has emerged as the de facto standard for managing containerized workloads and services.
Security aspects of Kubernetes
From a security perspective, the Kubernetes orchestration platform brings with it specific identity-related challenges that need to be addressed early in the development process. Otherwise, containerized environments can pose a risk to IT security. There are three main potentially vulnerable areas within Kubernetes that organizations should focus on as part of a true DevSecOps approach.
Kubernetes Risk: Hardware
Whether running Kubernetes on-premises or in a third-party managed cloud, a hardware platform is still required. Once an attacker has access to the virtual machine running Kubernetes and gains root privileges, they can also attack Kubernetes clusters.
To prevent this, there are the following security best practices:
- Enforcing the principle of least privilege is crucial to protecting the hardware that underlies both Kubernetes and the containers themselves. Virtual machines should be deployed with the lowest level of privileges (that is, only those that are strictly necessary for functional reasons) to make it difficult for attackers to gain root access.
- Credentials need to be rotated regularly, and using an automated vault solution makes sense to further increase protection without adding to the overhead.
Kubernetes risk: Kubernetes API Server
Aside from the physical machines, the Kubernetes control plane also needs to be secured. It provides access to all containers running in a cluster, including the Kubernetes API server, which acts as a front end and facilitates user interaction within the cluster.
An attack on the API server can have a large impact. Even a single stolen secret or credential can be used to escalate an attacker's access rights and privileges. An initially small vulnerability can quickly develop into a network-wide problem.
Security best practices include:
- To mitigate risk, organizations should first secure endpoints against credential theft and malware threats. Local computers used by users with administrative rights in Kubernetes are particularly relevant.
- Multi-factor authentication (MFA) for access to Kubernetes API servers is essential. For example, a stolen credential cannot be used for Kubernetes access.
- Once users are authenticated in Kubernetes, they can access all resources within the cluster. The management of authorizations is therefore of crucial importance. With role-based access control, a company can ensure that users only have the access rights they really need.
- Least privilege should also be enforced across Kubernetes service accounts, which are automatically created when a cluster is set up, to help authenticate pods. Equally important is regularly rotating secrets to eliminate access opportunities for those who no longer need them.
Kubernetes Risk: Containers
Pods and containers are the building blocks of a Kubernetes cluster and contain the information needed to run the application. There are several potential vulnerabilities within this container ecosystem and workflow. These include, for example, unsecured access to the container API or to the container host and unprotected image registries.
The following best practices are recommended for container security:
- Secrets must not be embedded in code or in a container image. Otherwise, anyone with access to the source code also has access to information in code repositories, for example.
- Security risks are significantly minimized with role-based access control, restriction of secret access to the processes within a specific container, and deletion of secrets that are no longer required.
- Secret usage, including rotation or deactivation, should be logged. A central secrets management solution that enables the automatic administration and protection of confidential access data is also advantageous.
"By adopting these best practices, a company can significantly improve security across the entire Kubernetes environment," said Michael Kleist, Area Vice President DACH at CyberArk. “In addition, there is also the possibility of supporting developers with self-service functions in their daily work, for example with regard to code scanning. This allows them to make a further contribution to increasing Kubernetes security quickly and conveniently.”
More at CyberArk.com
About CyberArk
CyberArk is the global leader in identity security. With Privileged Access Management as a core component, CyberArk provides comprehensive security for any identity - human or non-human - across business applications, distributed work environments, hybrid cloud workloads and DevOps lifecycles.