Key Questions to Ask your DevOps Teams About Containers and Kubernetes

DevOps teams are responsible for balancing two important forces
in their organizations’ software development efforts: shorter delivery cycle
times for applications that continue to increase in size and diversity.

To support themselves in this effort, many DevOps teams use containers. SPEC INDIA explains that these units contain application code and other
dependencies that help to improve the efficiency of the software delivery
process.

The issue is when an organization has too many containers to manage. At that junction, many organizations turn to Kubernetes. This platform reduces the operational burden of managing many containers at once.

By making it easier to share software and dependencies with Ops personnel, it frees developers from the manual tasks of running containerized software. This allows them to focus on responding to customers and building better programs in the first place.

Still, containers and Kubernetes aren’t without their security challenges. These issues could leave an organization’s data open to attackers if not properly addressed.

To minimize the risk of a data breach, organizations therefore need to ask their DevOps teams certain questions regarding their containers and Kubernetes environments. They should focus on questions that specifically relate to their Kubernetes configurations, container images and network policies/security practices.

Perhaps the most important question that organizations can
ask with reference to their Kubernetes configurations is as follows:

“Are our Kubernetes configurations providing adequate
security for our containers?”

The answer is probably “no” if an organization is using default configurations. That’s because those settings are meant to facilitate agility and speed in the software delivery process. They’re not designed to promote security.

The issue of pod communication helps to illustrate the shortcomings of default Kubernetes seetings. As explained by Stackrox, all pods are allowed to communicate with one another without any restrictions. This configuration makes it possible for an attacker to move laterally throughout a network and access an organization’s sensitive information.

In response to these and other threats, organizations need to work with their DevOps teams in implementing custom configurations that complement their security needs. They need to be careful in the process, however, as misconfigurations could create more security issues.

Take the administrative console, for instance. Threat Stack noted that an attacker could abuse a misconfigured API on the administrative console to hide behind DNS systems. They could then abuse that position to conduct cryptomining attacks or engage in other malicious activity.

Misconfigurations are clearly no laughing matter. A study on TechRepublic found that misconfigurations were the cause of 69% of security events weathered by respondents. That’s far greater than runtime and vulnerabilities incidents at 27% and 24%, respectively.

When it comes to securing their images, organizations first need to ask their DevOps teams to explain from which locations they’re pulling their container images. Kubernetes explains on its website that organizations need to steer clear of pulling images from unknown sources.

Doing so is tantamount to running unknown software on a computer. There’s just no telling what that software program will do; it could produce malicious effects.

For that reason, organizations need to confirm with their DevOps teams that they’re pulling their images primarily if not solely from private registries.

It’s at this point that organizations need to ask their DevOps teams another question: “Can we verify that the container images we’re pulling are safe?” That’s a loaded question, as the container images could suffer from vulnerabilities.

According to IBM, malicious actors could abuse those security flaws to escalate privileges within the container environment or to remotely execute commands.

Alternatively, the images might not be as they appear. TechTarget notes that nefarious individuals can use what are known as lookalike container images. To pull off these attacks, malicious actors put container images in public repositories and design them in such a way that they look like legitimate applications.

But they’re not. Once pulled down from the repository, the container images run malicious code in their environments. This process enables attackers to access organizations’ infected environments.

Last but not least, organizations need to ask some additional questions that pertain to their container and Kubernetes security. They should begin by asking their DevOps teams to clarify what’s in their network policies. DevOps personnel should know the traffic flows of the organization, so they should be able to explain how the current Kubernetes network policy supports those channels of communication.

Ideally, the organization should balance those policies with pod security policies. To have these frameworks in place, DevOps teams need to make sure that the admission controller is enabled and that they’ve authorized policies. Failure to do so could prevent any pods from spawning in the cluster.

Next, they should ask, “What other security policies do we have in place?” Organizations should verify that there’s a container security plan in effect. Such a framework should prevent the DevOps team from pulling container images from private repositories only. It should also detail the vulnerability scanning processes for the purpose of limiting containers’ exposure.

About the Author: David Bisson is an information security writer and security junkie. He's a contributing editor to IBM's Security Intelligence and Tripwire's The State of Security Blog, and he's a contributing writer for Bora. He also regularly produces written content for Zix and a number of other companies in the digital security space.