Why Kubernetes Needs More Network Visibility And Protection

Source:-informationsecuritybuzz.com

Kubernetes’ popularity has skyrocketed.

In 2018, Forrester declared it the victor in the “war for container orchestration dominance”.

However, a 2019 Gartner report highlights both the immaturity of the container ecosystem and a general lack of operational best practice.

Another issue is that Kubernetes adoption can significantly increase both internal application and associated management-related traffic. This is because it is designed to use small detached chunks of an application that communicate using a company’s internal network (including internal cloud networks).

Unfortunately, logging and detecting errant traffic between containers can be complex. For example, security tools need to be able to spot all compromised containers and unauthorised connections between pods. Furthermore, every application running inside a container may have a different and uniquely exploitable attack surface. Meanwhile, ageing threat detection or handling mechanisms continue to struggle keeping up with the newness and dynamism of container-based environments.

With all that in mind, here are my top three considerations to get Kubernetes security right:

Authentication and authorisations

Multiple layers of security within a system are vital. So too is role-based access control, which can provide Kubernetes cluster access only to those that need it. Restricting Linux capabilities with non-privileged (non-root) access and making filesystems read-only when possible (using read-only mounts) is helpful. Each application in a cluster should also be segregated or isolated whenever possible.

As ever, passwords, multi-factor authentication and certificates means individuals – both internal and external – won’t easily gain access to unauthorised systems. If reasonable, companies can also use private registries to store application images (with access only granted to specifically authorised employees).

Using cloud-native security tools

Cloud-native security tools should be deployed to secure the entire application development lifecycle, from CI/CD pipeline to run-time.

It is important to note that vulnerability scans must start during a build and carry on into production. Leaving security reviews until the end is not an option.

It is also crucial to stay on the ball as operations scale. Managing and securing hundreds of separate clusters, often spread across multiple clouds, can soon turn into a real headache. The best way to ensure compliance is to have a global multi-cluster management system in line with centrally enforced security policies.

Monitoring code to keep Kubernetes secure at scale

How can you ensure code is secure when you run third party – or even internal – applications?

System engineers need to be diligent with application version control and fully understand any associated, and inevitably fast-changing, associated security risks.

It is also vital to update system patches and constantly run vulnerability scans. Nobody wants a WannaCry repeat! As another rule of thumb, it is worth adopting the “principle of least privilege” for components running outside Kubernetes.

Stay strong (and informed)!

True security simply isn’t possible without deep network visibility and protection. Going forward, all organisations need to define every integration point and forensically determine where security processes should exist. Applying security context and policies to pods and containers is a start, but there much more that needs to be done.