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. explains that these units contain application code and other dependencies that help to improve the efficiency of the software delivery process. SPEC INDIA 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. Kubernetes Configurations 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 , 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. Stackrox 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. 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. Threat Stack Misconfigurations are clearly no laughing matter. A study on 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. TechRepublic Container Images’Security 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. explains on its website that organizations need to steer clear of pulling images from unknown sources. Kubernetes 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 , malicious actors could abuse those security flaws to escalate privileges within the container environment or to remotely execute commands. IBM Alternatively, the images might not be as they appear. 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. TechTarget 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. Kubernetes Network Policies and Security Practices 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: 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 . He also regularly produces written content for Zix and a number of other companies in the digital security space. David Bisson Bora