Using Dynamic Admission Control to Secure Your Kubernetes’ Supply Chain

Kubernetes adoption is up, but many organizations are suffering security incidents in their container and Kubernetes environments. In the fall edition of the “State of Container and Kubernetes Security” report, for instance, 91% of respondents told StackRox that they had adopted the container orchestration platform. That’s about the same proportion (90%) of survey participants that admitted to having suffered a security incident in their Kubernetes and container environments over the preceding 12 months. Two-thirds of those security incidents consisted of a misconfiguration issue. Those events were followed by a vulnerability incident (22%), a runtime incident (17%) and a failed audit (16%). Nearly half (44%) of respondents said that they ultimately delayed moving an application into production as a result of their security concerns.

SEE ALSO: SolarWinds hack and security – What is a software bill of materials?

The Importance of Securing the Container Supply Chain

Organizations need to defend themselves against the types of security incidents mentioned above. One of the ways they can do that is by focusing on securing the container supply chain. First, they need to have an understanding of what the container supply chain is.

Here’s DevProJournal with a definition:

The container supply chain includes what’s inside the container (developer code, Linux libraries), as well as the container host (Linux kernel), and orchestration layer (Kubernetes). The platform (host and orchestration) is fairly straight forward to lock down. The platform can be secured following traditional security procedures and best practices such as making sure SELinux is in enforcing mode.

Organizations therefore need to pay particular attention to what’s inside the containers. In doing so, they’ll realize that those contents tend to come from three major sources: a vendor or Linux distribution such as RHEL openssl libraries and glibc, upstream libraries or services including Ruby and Node.js as well as in-house developers.

Addressing the first source is fairly straightforward, according to DevProJournal. That type of code comes as part of the Linux distribution of the container image. Acknowledging that fact, developers can track and verify that code once they understand the support lifecycle of the distribution that they’ve chosen.

Tackling the second and third sources can be a bit more difficult. Advanced persistent threat groups and other digital attackers are actively working to hack container repositories and code repositories so that they can trick developers into introducing malware into their code. Simultaneously, with the aim of releasing new services as quickly as possible, developers might not code defensively or might not verify the trustworthiness of an underlying container image or open-source library. In either of those scenarios, developers might inadvertently expose their organizations or their clients to malicious software.

This possibility raises an important question: how can organizations work with their developers to keep their code secure?

How Dynamic Admission Control Can Help

One of the ways they can do this is by having their admins use dynamic admission control. This Kubernetes principle relies on admission controllers, piece of code that intercept requests to the API server before it’s authenticated and authorized. Admission controllers need be enabled to use some of the more advanced security features of Kubernetes such as Pod Security Policies (PSPs). Enable admins can use PSPs to enforce a security context and thereby control the security aspects of a pod. PSPs come in three types of classifications: Privileged, an unrestricted variety which allows for privilege escalations; Baseline, a minimally restrictive policy which prevents known privilege escalations; and Restricted, the most heavily restricted type of policy which uses best practices to harden a pod. (Note: PSPs are slated to for deprecation in an upcoming Kubernetes release.)

For its part, dynamic admission control specifically makes use of admission webhooks that call webhook servers in order to interact with pods. There are two types of admission webhooks that admins can configure: ValidatingAdmissionWebhooks, which runs in the validation phase and calls a validating webhook that matches the request; and MutatingAdmissionWebhook, which runs in the mutation phase and calls any mutating webhook that matches the request. The former is useful for validating specific aspects of the pod configuration during the admission process, while the latter helps to mutate pods upon creation.

According to Kubernetes’ documentation, admins can use admission webhooks to create a security baseline across an entire namespace or cluster. This can take the form of setting up PSPs. But it can involve pulling images from specific registries that are known to the enterprise only as well as rejecting deployments that don’t meet security standards, thereby helping to harden the container supply chain against security threats.

SEE ALSO: Kubernetes Is Much Bigger Than Containers: Here’s Where It Will Go Next

Container Supply Chain Security and CKS

Candidates can learn more about container supply chain security—and Kubernetes security, more generally—through pursuing certification as a Certified Kubernetes Security Specialist (CKS). Indeed, this certification covers other important Kubernetes security topics such as cluster setup, cluster hardening and system hardening. StackRox elaborated on the contents of this certification in a blog post:

The CKS is the third Kubernetes based certification backed by the Cloud Native Computing Foundation (CNCF). CKS will join the existing Certified Kubernetes Administrator (CKA) and Certified Kubernetes Application Developer (CKAD) programs. All three certifications are online, proctored, performance-based exams that will require solving multiple Kubernetes security tasks from the command line…. The CKS focuses specifically on Kubernetes’ security-based features such as role-based access control (RBAC) and network policies and utilizing existing Kubernetes functionality to secure your clusters.

To learn more about CKS certification, check out the CNCF’s website here.

The post Using Dynamic Admission Control to Secure Your Kubernetes’ Supply Chain appeared first on JAXenter.