This post was originally published here by siri oaklander.
Recent news on the discovery of the first Kubernetes vulnerability, the popular cloud container orchestrations system, highlights two things critical to security, the need to:
- Audit and harden systems on the periphery and inside an infrastructure, and
- Continually review these systems for vulnerable packages and configurations during their lifecycle, in addition to normal intrusion detection monitoring.
If you’re not already familiar with Kubernetes, it is essentially a popular series of open source projects for automating the deployment, scaling, and management of containerised applications. It is also an exceptionally well built and useful system, and like all systems that become popular, it becomes the object of increased scrutiny by researchers and malicious actors, as finding security holes in it can grant access to valuable data and resources across many organizations.
A researcher has identified the first known major finding for Kubernetes within the Kubernetes API server as CVE-2018-1002105 (patch information and other details available here), and fully remediating this will require updating Kubernetes to a fixed version. Fortunately this can be done today since this was responsibly disclosed to the company before it became public.
In a nutshell, due to the Kubernetes vulnerability, an attacker could use the Kubernetes API server to connect to a backend server and send arbitrary requests, authenticated by the API server’s TLS credentials. The upshot is that such an attacker could then retrieve sensitive information or make dangerous changes through effectively legitimate channels, making it hard to detect that anything is going on at all.
The real chilling fact about this is that “in default configurations, all users (authenticated and unauthenticated) are allowed to perform discovery API calls that allow this escalation.” That means that settings can partially mitigate this by at least disallowing anonymous requests from performing discovery, which will cause some disruption to services that take advantage of this but at least require authentication to take advantage of this vulnerability.
Defense in depth and the principle of least privilege are critical to a good security program as many critical issues grant access of some kind that then permit leveraging an additional issue to actually gain control or exfiltrate data. Because of this, it is important to audit, harden, and monitor all systems wherever they are located, and even inside a virtual or actual network to restrict communications and permissions to the least necessary for servers/services/containers to do their work.
In this case, minimizing privilege helps but does not fully fix the problem. And securing the servers behind the API server is certainly important, but here we see requests coming through normal authentic channels by taking advantage of the API servers credentials.
This is why it is important to have a system like CloudPassage Halo in place to monitor for vulnerable packages and configurations on an ongoing basis. That way you can quickly and automatically uncover new findings, permitting you to update expediently and minimize exposure.
