5 Tricky Container Security Challenges
Containerized environments can be relatively complex to secure, particularly for enterprise teams used to more traditional network security processes and strategies. There was initial optimism that containerized infrastructure would actually be more inherently secure because microservices are limited in function and can be hardened. The reality, though, has proved otherwise.
Here are five reasons why securing container and Kubernetes environments requires new approaches that must diverge from—and go beyond—traditional security capabilities.
Container abstraction makes visibility a challenge
Container and Kubernetes infrastructures virtualize all application activity, obscuring visibility and making it difficult for security professionals to see what’s happening within hosts and network traffic. This containerized environment is hyper-dynamic, as it could be scaling and/or changing frequently and quickly; this makes it hard for traditional tools to catch up. For example, a Kubernetes pod may only run for a few minutes before it goes away automatically so that all the resources can be reused. If a tool isn’t able to detect suspicious behavior in time, it will miss the window and lose the chance to capture any forensic data. At the same time, traditional tools—like web application firewalls (WAFs), next-gen firewalls or endpoint security—are of no use in container environments because they cannot see attacks as they happen.
Kubernetes itself is an attack surface
Kubernetes, along with other orchestrators and container management tools, offer brand new attack surfaces for hackers to explore and exploit. There are already critical vulnerabilities being found in Kubernetes platforms; the Kubernetes API server became a popular attack target and Kubernetes management ports are being port-scanned by attackers worldwide. Security professionals face a new challenge in learning to protect against emerging exploits to these open source tools, while attackers are busy actively probing for new weaknesses.
Developers must play an increasingly crucial security role
Most developers aren’t security experts, which was largely acceptable with traditional application development environments. However, protecting applications throughout containerized development pipelines calls for security to shift left and include safeguards from the very beginning of the build phase. Effective security measures must also secure applications in production where the risks are highest. As a result, developers have been enlisted in the work of actively securing the applications they develop.
Security automation is the number-one DevOps challenge
DevOps teams face a challenging skills gap and learning curve when it comes to understanding how Kubernetes or other orchestration tools work, as well as how it deploys pods, how role-based access controls (RBACs) and secure service accounts work, and more. On top of that, the first priority for DevOps teams operating microservices-based environments is to automate as much of the application deployment process as possible. The central goal of operating these environments—whether manually or via automation—is to rapidly deploy application updates (with some teams reaching 100 deployments a week), rather than the weekly or monthly cadence familiar to traditional development practices. That need for speed requires a continuous automated pipeline with built-in automated security that doesn’t slow down deployment with manual steps.
For DevOps teams, overcoming this shift left challenge means adopting a modern toolchain of security plugins and extensions across the pipeline. For example, teams can install tools to automatically scan application images during the build phase and reject builds with known vulnerabilities or compliance violations. Teams can also integrate tools to evaluate and audit RBACs, Docker and Kubernetes configurations and ensure processes line up to the established CIS benchmarks.
The work isn’t over, as DevOps teams must also take on the difficult challenge of protecting production environments, where zero-day vulnerabilities, insider threats, cryptomining and other ever-evolving attacks will arise without sufficient and automated precautions. Addressing these potential vulnerabilities as early as possible requires teams to hone their knowledge of known and emerging threats and carefully implement best practices and tools to detect and prevent them.
Container and Kubernetes security require a new security model
The traditional model for securing applications in production was based on denying threats that exhibit certain signatures. When a certain threat became known, a security team would respond and implement a new firewall rule. Needless to say, environments never had the latest threat signatures or safeguards in place. Dynamic container and Kubernetes environments require a much more responsive and automated system for implementing protections. DevOps teams face the challenge and opportunity of shifting to a zero-trust security model where only a declared list of allowed connections and processes are permitted.
Within microservices-based environments, each container, image, application and microservice has a limited set of functions, network connections and processor file activity that constitute normal, secure behavior. Attackers will seek to exploit the network or vulnerabilities via abnormal connections or processes that aim for unauthorized file access. This is where developers can play an increased security role: Developers know their applications best, and can help security teams by building a list of the behaviors that the application should be allowed to perform when in production.
Just as developers create a manifest for deploying their applications in Kubernetes, they can use security-as-code practices to write security manifest Kubernetes-native YAML files as custom resource definitions (CRDs). These human-readable YAML files declare the security context for the application at runtime. That security manifest is managed as code, pushed into production and protected by the zero-trust model that allows only authorized behaviors. Iterative application changes will include edits and testing of this security code. As a result, the security team should never need to manually create or change security rules outside of this regular pipeline.
Developers, DevOps and security teams must shift left and lead security automation together
Automated security processes across pipelines and declarative zero-trust security policies now call upon and enable developers and DevOps to play key roles in implementing effective container and Kubernetes security. The traditional latencies of reacting to threats with manual firewall rules are no longer acceptable. Instead, developers and DevOps teams empowered by flexible security models can introduce rules instantly and contribute to systems that eliminate threats proactively and automatically.