With recent platforms like Kubernetes and containers, CVE (Common Vulnerabilities and Exposures) can be found frequently, even in the most common utilities. They can pose a range of challenges for those in charge of security.
There have been cases in the past where a critical issue let an attacker take full root control of a host and all its containers. Examples like that may leave some intimidated about approaching security for Kubernetes.
By understanding the security of Kubernetes and the prominent challenges, we can address how to approach solving for them.
What Are Kubernetes Security Issues?
While adoption of Kubernetes is high, a lot of organizations are now facing troubles with security issues, according to a survey by StackRox.
The highly distributed environments of Kubernetes, often with large clusters, can expose security risks. A bad network configuration can make entire computing systems vulnerable to unauthorized access. Multiple or all of your machine can be at risk just from single nodes with an old operating system or a DoS attack.
It is difficult to monitor and trace containers due to their nature of spinning up and down frequently. Additionally, firewalls do not suit the containers domain. A key area of vulnerability in any Kubernetes environment is the code itself. The lack of ability to isolate containers effectively presents an opportunity for attacks to jeopardize sensitive data, operations, compliance and privileges.
Some prominent Kubernetes security issues and best practices outlined here will help you anticipate and avert issues when deploying your own Kubernetes instance.
How to Address Kubernetes Security Vulnerabilities
Taking proactive steps to account for security weaknesses can greatly reduce the risk of a number of negative scenarios like breaches.
With code presenting an attack service, especially in a production environment, issues can be prevented using straightforward policies like encrypting TCP using TLS handshakes, not exposing unused ports, scanning, and testing regularly.
Kubernetes security tools should have these key functions:
- Reduce time to guarantee code is free of compromises
- Provide digital signatures to have a level of trust for code
- Provide visibility and transparency in configuration issues in addition to code
- Prevent incoming and outbound connection of information to unsecure services
Building code from untrusted registries has its risks; untrusted code potentially opens the doors to attacks through malware or backdoors that grant access unintentionally.
Minimizing opportunities for compromise can greatly help security preparedness. Developers should get rid of unnecessary packages, libraries, and shells. Privileges should be kept as limited as possible and only the secrets necessary to a task should be mounted.
When applications are not isolated in the cluster, issues can arise. Resources and teams should be kept separate from each other using namespaces.
To combat lateral motion of an attack within a cluster, policies can segment the network. Role-based access controls (RBAC) should be correctly configured to limit access.
Infrastructure elements like the API server, etcd, and controllers are all attack surfaces during runtime. There are several moving parts impacting the health of a Kubernetes cluster at any given time.
In the event of an attack, compromised containers need to be quickly isolated, stopped, and replaced with healthy ones while the source of the attack is found and addressed.
Building Your Kubernetes Security Checklist
To approach your Kubernetes security with confidence, you can use this checklist to be best prepared.
- Begin with a minimal approach, adding only what is necessary: To have greater control, use a minimal host OS, SELinux options, and end read-only mounts. You should scan images, OS and any outside kind, for vulnerabilities from top to bottom. No outside source can automatically be deemed trustworthy.
- Use namespaces and RBAC to segment the cluster and users: Anything that isn’t necessary should not be visible. Network segmentation must be put in place pre-production because the default of Kubernetes networking allows any-to-any communications. Policies on inbound and outgoing connections should be carefully defined and routed correctly.
- Keep privileges to a minimum, and never run application processes as root: Attacks that rely on installing software or modifying the file system can be stopped by way of a read-only root file system. Integrating image scanning and other security checks into the CI/CD (Continuous Integration / Continuous Deployment) pipeline can be helpful.
- Secure the cluster itself: Configuring RBAC for security entails limiting access to the API server and encrypting communications with TLS. Kubelet permissions should similarly be locked down.
- Ensure that only authorized images are used: Without a process that ensures that only images adhering to the organization’s policy are allowed to run, the organization is open to risk of running vulnerable or even malicious containers. Downloading and running images from unknown sources is dangerous. It is equivalent to running software from an unknown vendor on a production server. Use private registries to store your approved images - make sure you only push approved images to these registries. This alone already narrows the playing field, reducing the number of potential images that enter your pipeline to a fraction of the hundreds of thousands of publicly available images.
Built-in controls in Kubernetes can help in managing risks, for example by configuring security context to limit pod access, so take advantage of them.
An important element to security is the practice of constantly monitoring it proactively; teams should always have a view of process activity, communications between services, and communications external to the cluster.
The CIS Kubernetes Benchmark includes more than 100 individual checks that evaluate the security of the environment to help with compliance checks.
And now let’s see if you are a Kubernetes Security expert – proof your knowledge and start our quiz!
