Category: Kubernetes

containers in arches

Securing cloud native containers

Security, in and of itself, is a broad topic. Container security adds yet another facet to the already nebulous subject of security. In a lot of enterprises today security is first and foremost and the process for securing applications continues to shift left, meaning security is moving to be integrated earlier into the development process. This post will focus on some of the high level tasks and automations developers and operators can implement to mitigate risk.

The issues.

Misconfiguration

The #1 security risk in any cloud native environment is misconfiguration. How do operators know if what they are deploying is secured properly? In a lot of cases, deployments are left insecure for long periods of time without anyone noticing. This is a massive problem, especially for new technologies such as Kubernetes.

Software Defects

Another security risk is software bugs. Every day new vulnerabilities are found in software. Some of the vulnerabilities are minor, but increasingly the discoveries constitute a potentially critical issue when deploying software to a public facing system. Vulnerabilities are “what is known”. There is a signature for each of the known vulnerabilities which can be used to scan software.

However, “you don’t know what you don’t know”. Keep in mind many defects exist which are not known. These are the zero-day vulnerabilities.

Defense-in-depth

Scanning

Scanning software for known vulnerabilities is an absolute must have in any defense-in-depth strategy. However, even the best scanning tools have unknown vulnerabilities (or known limitations). The best defense is offense so creating a system where your container images go through multiple scanners is always a good strategy.

It is important to scan at many different points in the development process and also continually when in production. Any change could potentially be a breach. It is also very important to have layers which would support the other layers if a layer is permeable. Impervious security requires layers and your goal as a security architect is to create impervious security. Read on for other layers.

Network visualization

“It starts and ends with the network”. Kubernetes, being the orchestrator of choice for cloud native deployments, attempts to keep things simple which has lead to a number of CNIs (container network interface) to give platform engineering many choices when deploying workloads. Having something to visualize the network is important, especially when you can act upon those connections. NeuVector provides these capabilities. Being able to quarantine a pod or take a packet capture is key to ensuring continuous protection against unknown attacks and for any required forensics.

Data protection

Many different regulations apply to data for enterprises. Being able to provide audit reports for specific data regulations is massively important for HIPAA or PCI DSS. Being able to provide reporting for SOC2 compliance may be important. If your tool cannot “see” into the packet before it traverses the kernel, then it cannot prevent data from crossing a “domain” or prevent sensitive information from being leaked.

WAF

A lot of cloud native security tools have the ability to block layer 3 packets. Very few have true layer 7 capabilities. Being able to manage traffic at layer 7 is critical to anyone who is running applications on Kubernetes. Layer 7 is where a lot of unknown vulnerabilities are stopped, but only if the tool can look into the application packet before it traverses the kernel. This is the important point. Once the packet crosses the kernel you are compromised. Use a tool which will learn your workloads behavior. This behavior is the workloads signature and would be the ONLY traffic allowed to traverse the network.

Wrapping it up

Security is the highest scoring word in buzzword bingo these days. Everyone wants to ensure their environments are secure and it takes specialized tools for specific platforms. Don’t use the perimeter firewall as a Kubernetes firewall…it simply will not suffice for complete security inside a Kubernetes cluster. Use a tool which can watch every packet and the data inside every packet ensuring only packets with your workloads signature and nothing else traverses the network. One that allows for visualization of the network along with the traditional scanning, admission control, and runtime security requirements every cloud native implementation requires.

Where did Kubernetes come from?

There’s a lot of great articles about how containers and subsequently Kubernetes came about…just search kubernetes with your favorite search engine!

From a devops perspective the virtual machine’s (VM’s) movement created a bunch of issues for operators mostly because of how developers took advantage of the monolithic stack which VM’s proliferated.

Google started down the path when they realized the opportunities based on how some older technologies consumed compute resources and added a cgroup functionality to the kernel. The container movement was officially underway.

This also started a movement to change how applications are developed. They say “timing is everything” and it all fell into place. If you think about how the basic elements of container technologies (images, containers, and registries) are used today the concept of develop once, run anywhere has taken hold.

BUT…this really is only one part of the full equation. Developers now have a lot more resources at their disposal and these resources are what operators have to manage.

That’s where Kubernetes comes into the picture. Kubernetes helps solve the operational issues around managing or orchestrating all of the containers and their requirements around scale, load balancing, service discovery, observability, etc.

Kubernetes originated with Google primarily because Google was well ahead of most everyone hence the work on cgroups. Google created a platform they called Borg well before Docker was conceived and right about the time Amazon started their “web services” division.

Google released Borg in 2015 to a new foundation created with the Linux Foundation called the CNCF or Cloud Native Compute Foundation. Borg was donated as Kubernetes which stands for “Helmsman”. K8s (short hand for Kubernetes) is now one of thousands of CNCF projects.

With 10 years of experience behind them and the reputation of Google, Kubernetes was then and continues today to be the de facto standard platform of modern cloud native computing.