Most organizations today are on a path to modernize the way they build and deliver applications and services. The benefits of modernizing are profound. Organizations can deliver revenue-generating features faster and be more responsive to their customers. They can reduce technical debt (and the potential security vulnerabilities hidden there), as well as take advantage of cloud efficiencies. However, in this shift to containerized applications security while accountable for the security of their organization does not have ownership over these applications and security hygiene is left as an after thought.
If containerized applications are in their nature, more contained... what is the risk of no security?
Misconfigurations & Defaults
Kubernetes was designed to be easy to get up and running for lab testing purposes and more. If your organization is deploying applications to production without a uniform security approach you could be exposing your organizations beyond aknd.
Examples of default configurations include but are not limited to:
- Privilege Escalation: By default a container is not allowed to access any devices on the host, but a "privileged" container is given access to all devices on the host. This allows the container nearly all the same access as processes running on the host. Containers running with the privileged flag can do almost anything a host can do, run with all capabilities and gain access to the host’s devices. This means that if an attacker breaches a container running with the privileged flag, they can wreak havoc.
- Use Kubernetes Network Policies: Networking of Kubernetes clusters defaults to an 'allow all' rule, allowing all inbound and outbound communications. In production this greatly increases your exposure to denial of service threats. Organizations need to install a network plugin to control traffic from the application and configure policies accordingly.
- AllowedHostPaths - This specifies a list of host paths that are allowed to be used by hostPath volumes. An empty list means there is no restriction on host paths used. There are many ways a container with unrestricted access to the host filesystem can escalate privileges, including reading data from other containers, and abusing the credentials of system services, such as Kubelet.
Default configurations and associated risk are documented by Kubernetes Pod Security Standards, review for best practice recommendations when locking down your production environment. Limiting the privileges of the containers running in your cluster and enforcing those limitations can be one of the most important protections you can implement.
Containerized applications are only as secure as the code that runs in it. Container vulnerabilities are prevalent and if security is unable to shift left and identify these vulnerabilities prior to production deployment your risk will be amplified. Of Dockers 100 latest images more than 90% of the images contain a high or critical vulnerability.
With over 149K of CVEs in 2020, the security risk is only growing and if application hygiene is left unchecked, your exposure is steep.
So while Containers are more contained, as with all other infrastructure practicing good hygiene and security practices are critical in the success of your organizations security posture.
Be sure to watch Security Connect session for more information on identifying vulnerabilities and risk in Kubernetes environments.