10 Questions To Assess Your Container and Kubernetes Security

Source:-containerjournal.com

Kubernetes adoption has exploded, especially in production environments, and is considered by most as the de facto container orchestrator. As the container and Kubernetes market continues to mature, security of the cloud-native stack is becoming ever more important. The Cloud Native Computing Foundation recently published its results of a months-long security audit, along with recommendations for both cluster administrators and developers.

There are many security considerations to be aware of when using Kubernetes—are your images, deployments, nodes and clusters properly locked down? Below are 10 questions you should ask your DevOps and security teams to help ensure your containers and Kubernetes clusters are secure throughout the container life cycle.

Are we using the latest version of Kubernetes and Docker?

Most vulnerabilities that are exploited are often those for which a patch was already released. Sometimes it comes down to staying on top of software updates as the highest impact action you can take to secure your systems. During its security audit, the CNFC found a host of vulnerabilities and flaws in the code, and future releases will address many of these. Update your systems as soon as a new version is released.

Are there images we’re using that haven’t been scanned in more than X number of days?

Regularly scanning your images is a key component of ensuring that you’re not inadvertently allowing vulnerable images from being pushed to production. This is especially true for zero-day vulnerabilities that are discovered after an image has been scanned.

Where are our images coming from (aka, image provenance)?

Developers will often look for shortcuts to improve velocity, including using questionable image registries that might not be integrated with an image scanner. You should enforce policies to ensure images are only pulled from trusted and reputable registries that are fully integrated with your image scanner.

Are there any Pods that don’t have any network policies associated to them?

Pods are the atomic unit of Kubernetes and can contain one or more containers. Kubernetes network policies are a critical component of securing Pods. When a network policy is associated to a Pod (or group of Pods), then that Pod can only communicate to a limited number of other Pods as defined by that network policy, thus “isolating” the Pod. However, if no network policy is associated to a Pod, that Pod is free to connect to any and all Pods. A Pod that can communicate to any other Pod exposes you to exponentially greater risk during a breach.

Are there network communication paths that are currently allowed but aren’t being used or aren’t necessary?

Hardening your environment starts with making sure unnecessarily permissive network policies are removed. While it might be easier and faster to get up and running by allowing all communication, you will increase your attack surface. Implementing secure network segmentation policies is a hallmark of a hardened Kubernetes environment.

Is Kubernetes Role-Based Access Control (RBAC)-enabled?

The most important security advice we can give regarding RBAC is to actually use it. A variety of Kubernetes distributions and platforms have enabled RBAC by default over time, and newly upgraded older clusters may still not enforce RBAC because the legacy Attribute-Based Access Control (ABAC) controller is still active.

Are there any containers running with privileged flag?

One of the most egregious container misconfigurations is running them with privileged flag. This flag provides all the capabilities to the container while lifting limitations, which essentially gives it the same level of capabilities as the underlying host. This means that if a container that’s privileged is breached by a bad actor, they will have host-level access.

Are all running containers’ root filesystems mounted as read-only?

One of the benefits of containerization is its immutable infrastructure: Once something is built, it won’t change. Making the container’s root filesystem read-only prevents any writes to the container’s root filesystem at runtime and reduces the attack vectors.

Are there any containers sharing the host network namespace?

A container that runs in the host’s network namespace could access network traffic to and from other pods because that container effectively lives “outside” in the main Docker host and has full access to its network interfaces.

Can we see which processes are running in containers across clusters?

Runtime threat detection relies on seeing what processes are running to detect unexpected or malicious processes. Usually, a suspicious process is the first sign of a compromised container.