There is a lot in common between unsecured Docker daemons and unsecured Kubernetes API servers. Threat actors can use the exposed APIs that run there to take control of the entire container platform if it is misconfigured. Despite the fact that unsecured Kubernetes clusters seem to have a lower level of malicious activity, cybercriminals operating there may gain access to more critical targets.
Kubernetes is a complicated network made up of several layers and modules and is versatile and scalable thanks to its modular architecture, which allows most components to be individually configured or switched to achieve a particular target. The platform’s sophistication, on the other hand, makes proper security difficult – a single misconfiguration may lead to compromised containers or even clusters.
Unsecured Kubernetes Clusters
Kubernetes clusters that aren’t secure are vulnerable to a variety of threats. Cryptojacking, in which attackers place malicious crypto miners in infected containers, is still the most common type of attack. The crypto-jacking malware is either released as a new container or as a hijacked container. Some malware tries to travel laterally or vertically after gaining access to a container. Attackers can control further containers or applications by moving laterally, and they can control the host or even the cloud environment where the clusters are deployed by moving vertically.
Also Read: Strategies to Enhance the Remediation Efficiency of the Security Teams
Threats Against Unsecured Kubernetes
- Excessively permissive capabilities – Depending on the application’s specifications, each container is given a subset of capabilities. These capabilities give containers access to the host’s kernel modules and grant them highly privileged permissions. If an attacker compromises a container with these features, they can easily gain access to the host.
- Unpatched vulnerabilities – Container breakout can occur if the container runtime or node OS hasn’t been patched. The container runtime schedules and manages containerized software. Applications may break out of containers because of flaws in the container runtime. Most kernel exploits could lead to privilege escalation and container breakout because containers share the host’s OS kernel.
- Shared namespaces – Since every resource of the container, such as networking, processes, and file system, is placed in isolated namespaces, a containerized application can run in a sandboxed setting. A container’s namespaces may need to be shared with other containers or the host in some cases. If a container needs to capture network traffic from the server, it must run in the host’s network namespace. This shared namespace allows attackers to switch from the container to the host through a channel.
- Stolen service account token and cloud account credentials – Tokens for service accounts are stored in containers and used by apps to authenticate with API servers. If the applications are stolen, attackers may impersonate them and use API servers to switch laterally or vertically. Additionally, attackers can gain access to the cloud environment that hosts the Kubernetes clusters using cloud credentials, resulting in a much more serious breach.
Protection Against Threats
Many of the problems listed above can be avoided by enforcing strict security policies, which include:
-
Scan and Patch Regularly
For initial access or privilege escalation, known vulnerabilities can be exploited. Container platforms and applications should be scanned and patched on a regular basis.
Also Read: A Strategic Perspective of the Cloud
-
Securing the Network
Kubernetes components like API server, Kubelet or etc. should never be exposed to the internet. Only a limited subset of IPs should be allowed to interact with these components, as per the firewall rules. Mutual TLS (mTLS) should be enforced on every Kubernetes component that supports it. Furthermore, Network Security Policy should be in place to restrict the pods, IP blocks and namespace that a pod can interact with.
-
Securing the Identity
Apply the theory of least privilege and enforce role-based access control (RBAC). Allow only the permissions that are absolutely necessary for each position. Unauthenticated and anonymous requests should not be accepted or responded to by any components. To avoid credential leaks, rotate the credentials and certificate on a regular basis.
For more such updates follow us on Google News ITsecuritywire News. Please subscribe to our Newsletter for more updates.
