Kubernetes, commonly called K8s, is an open-source container management system developed by Google. Containers and tools like Kubernetes enable automation of many aspects of application deployment, which provides tremendous benefits to businesses.
K8s is just as vulnerable to attacks and cybercrime as traditional environments, in both public and private clouds. In this blog post, we’ve compiled everything you need to know to make sure your Kubernetes environment is safe.
Here is what we tackle:
- What are K8s security challenges?
- Why secure K8s anyway?
- How to secure the K8s stack
- How to secure the full application stack including K8s
Security challenges with Kubernetes
Kubernetes containers running in pods can be attacked from the outside through the network or internally by insiders. Those insiders can be victims of phishing attacks whose systems become conduits for insider attacks.
These attacks are most commonly caused by:
- Application misconfiguration
A misconfigured application creates an opportunity for an attacker to get inside the container and its environment and start probing for weaknesses in the network, process controls or file system.
- Container-level issues
Once a container is compromised, attackers can attempt to escalate privileges to take control of additional containers or the entire cluster. Pay close attention to container configuration and overall security hygiene.
Kubernetes infrastructure vulnerability
Kubernetes itself is not the sole target for hackers. They often attempt to compromise the API server or Kubelets (agents that use PodSpecs to ensure containers are healthy and running according to specifications), which means your Kubernetes security checklist must be expanded to include activities that ensure the security of the entire infrastructure.
Attacking the orchestration tools directly allows hackers to disrupt running applications and even gain control over the resources used to run the containers or even obtain admin privilege rights over a cluster.
Why secure K8s anyway?
- API service
Kubernetes is entirely API-driven, which means it is necessary to control and limit who can access the cluster and what actions they are allowed to perform. This will be your first line of defense.
What is more, attackers can actually find your Kubernetes clusters on the internet rather easily. For instance, Kubernetes uses etcd as its cluster database. It listens on port 2379/TCP, which is indexed by Shodan, and so can be easily found.
- General exposure
Etcd services are unauthenticated, which makes it very easy for attackers to successfully attack your cluster database and even compromise your entire system. The Kubernetes API is generally exposed when deployed, so securing it is top priority. Luckily, most Kubernetes deployments provide authentication for this port.
- Unauthenticated ports
The Kubelet API, used by Kubernetes to manage containers on individual nodes and in some clusters, is available unauthenticated. That allows attackers to execute code in your containers and possibly take over your entire cluster.
How to secure the K8s stack?
You cannot secure Kubernetes without implementing multiple layers of monitoring. Invigilate critical vectors to detect any events that may have damaging consequences. In particular, monitor:
• the entire network: it’s the typical entry point for attackers as it’s the first point to break in.
• containers: this will allow you to determine a suspicious process once it’s started or any attempts to escalate privileges.
• hosts: it’s good to apply traditional endpoint security to monitor for exploits against the kernel or system resources.Source: kubernetes.io
- API access restrictions
Control access to API through the following:
• Transport Layer Security (TLS) for all API traffic: this is what K8s expects by default
• API authentication: when you install a cluster, choose an authentication mechanism that aligns with the common access patterns. All API clients must be authenticated, including those that are part of the infrastructure.
• API authorization: every API call should pass an authorization check once it’s been authenticated. K8s’s role-based access control (RBACs) control access to application workloads and K8s system resources. It’s critical to configure the RBACs properly.
- Kubelet access control
Access to this API will be unauthenticated by default.
- Workload/user capabilities control by policies
Specific policies control the actions of a given resource, whether it’s on the cluster, in itself or other resources. Consider the following policies:
• Resource usage limit on a cluster: resource quota limits the number or capacity of resources granted to a namespace, while limit ranges restrict the maximum or minimum size of some of those resources
• Pod security policies: control security-related aspects of the pod specification through a set of conditions that a pod must run with to be accepted into the system
• Network access restrictions: allow access to pod and ports to pods from other namespaces
• Cloud metadata API access restrictions
• Pod access control to nodes
- Protection of cluster components against compromise
To ensure maximum protection, implement the following:
• Restrict access to etcd with strong credentials
• Enable audit logging to record actions taken by the API for later analysis
• Restrict access to alpha or beta features
• Rotate infrastructure credentials frequently
• Review third-party integrations before enabling them, because they may alter
• Encrypt secrets at rest
• Enable alerts for security updates and reporting vulnerabilities and always update the system promptly
With the Sumo Logic app for Kubernetes, you will be proactively preventing issues for Kubernetes orchestration. The app allows you to quickly measure and visualize key data to highlight anomalies in an instant. You can perform root cause analysis to improve MTTI and MTTR from a single screen.
The Sumo Logic app for Kubernetes integrates seamlessly with any container architecture, be it local, hosted or hybrid. The app installs instantly as a stand-alone tool in a data center or as part of cloud architecture, and integrates with Sumo Logic apps for all major cloud hosting platforms, including AWS, Google Cloud, Microsoft Azure and VMware Vsphere.
Detailed instructions on how to install the app can be found here.
Securing the full application stack including K8s
RBACs aren’t just for API authorization. It is mandatory to properly configure them for all system resources. In order to do this correctly, make sure you review these access controls and configure them as required:
- Restrict Kubelet permissions
- Require authentication for all external ports
- Limit or remove console access
Sumo Logic offers full-stack visibility into applications, including Kubernetes container orchestration. With the dedicated K8s app, developers are freed from gathering and piecing together reporting from separate, siloed tools. From container technology to microservices and applications, Sumo Logic provides comprehensive visual insights into every layer of the environment
- K8s can be attacked from the outside or from the inside. Common causes of attacks include application misconfiguration, container level issues or
- Kubernetes can be attacked both from the outside and inside. Its entire infrastructure is vulnerable too
- Kubernetes must be secured because it’s entirely API driven, its clusters can be easily traced and etcd services used by Kubernetes are unauthenticated. Ports are unauthenticated as well.
- To secure the K8s stack, monitor everything and implement stringent API access restrictions, protect access to Kubelet, control workflow and user capabilities with policies and protect cluster components against compromise
- To secure the full application stack, configure RBACs to restrict permissions, limit console access and authenticate all external ports
“The highly dynamic nature of container environments orchestrated by Kubernetes presents a number of specific security challenges that are only going to become more prominent as enterprise adoption increases” – Gary Duan, CTO and co-founder NeuVector.