Docker containers have been hit by a number of vulnerabilities over the years. So much so, that companies are rolling out security-specific apps to help enhance the platform. Of course, it’s not only the security wrapped within the containers, or the engines that help build and run them. Security starts from the ground up, from services to best practices.
“It’s unlikely that one tool will do everything and safeguard organizations against all the things that can go awry,” said James Kelly, networking strategy lead for Juniper Networks. Kelly believes there are many considerations, among them secure coding practices to trusted execution, build signing, image signing, release management, secure networking, deep packet inspection on ingress-egress and east-west for next-generation firewalls (NGFWs), advanced threat detection and prevention, traffic encryption, access control lists, microsegmentation, application-API identity and more.
Security gets even more crucial at scale. To that, Kelly insists developers and admins must consider, “multitenancy, microsegmentation, encryption without a sidecar — complementary or supplementary to a service mesh encryption scheme — and containerized-NGFW service chaining.”
But what are the tools developers and administrators can employ to beef up the security of their container rollouts? Let’s take a look.
One of the biggest security issues surrounding containers is the images those containers are built upon. If you develop your containers based on a compromised image, havoc will be wreaked. To that end, Gadi Naor, chief technology officer and co-founder of Alcide, says, “The best practice around it would be to build a development container image that contains the build tools, language-specific toolchain teams need to iterate their engineering tasks. Normally you’d start from a base OS image and add the relevant packages to the runtime language being employed.”
In other words, build your own images in-house. That should be considered a pillar of security for container rollouts.
Harbor is an open source container registry that — when used in conjunction with Red Hat’s Clair vulnerability scanner — can also scan your images for known vulnerabilities. Once installed, Harbor serves as a repository that can then scan any uploaded images for issues. Such a scanner platform should be considered a must-have for any and all container developers and administrators. Knowing what’s the issue is with your image files can go along with to making sure you’re deploying safe and secure containers.
Find out how to install Harbor with Clair in “How to Scan Docker Images for Vulnerabilities with Harbor.”
Role-Based Access Control
Next to using safe images, RBAC (Role-Based Access Control) should be a tool every container engineer understands fully. RBAC determines if a user, via local roles and bindings, is allowed to perform an action on a given project. When you give developers access to your clusters, it implies they also have access to the Kubernetes APIs. Why is this so important? According to Scott McCarty, principal product manager for containers at Red Hat, “As developers access these APIs, be it indirectly in development or directly in production (for troubleshooting), role-based access becomes critical to limiting the damage that could be done maliciously, or by mistake.”
Hadolint is the Haskell Dockerfile linter. In the same fashion, you can lint programming languages, static files can be linted. But why lint your Dockerfile? Simple: to check for optimizations, programming errors, bugs, stylistic errors, suspicious constructs, and likely failures. Linting your Dockerfiles will not only result in cleaner code, but no errors and smaller Docker images. Even better, Hadolint can be integrated into your CI pipeline, so the linting of your code can be done automatically. Of using a linter, Naor says, “It will drive such users to evolve their container authoring skills while keeping direct line of sight to security best practices.”
Snyk can help identify potential runtime application risks during build time. Specifically, Snyk can (when integrated into the CI pipeline) continuously find and fix vulnerabilities within your containers. Snyk works by scanning OS packages (per image) by inspecting the relevant OS package manager manifest information and then, based on this information, Snyk analyzes the images for key application binaries and compares the results against their known vulnerability database. Unlike Harbor/Clair which only scans images for vulnerabilities, Snyk can also scan your Dockerfile — if it’s included in the command line — to provide an even more detailed analysis of your base image.
WhiteSource is an open source security and license compliance management platform that automatically identifies all components and dependencies in your build. When using WhiteSource to search for open source components, their browser plugin will reveal any reported bugs, security risks, undesirable licenses (as defined by your configured policy), new versions for each component, and more. By making use of a tool like WhiteSource, you are empowering yourself to make better decisions about the components you want to add to your container build-out.
Alcide offers the Kubernetes Advisor, which is a multicluster vulnerability scanner that does best practices and compliance checks for vulnerability scanning, hunting misplaced secrets and excessive secret access, workload hardening, Istio security configuration, best security practices for Ingress controllers, Kubernetes API server access privileges, and more. Once you have Kubernetes Advisor set up, you’ll get continuous auditing and compliance of your Kubernetes clusters via an easy to use web-based dashboard.
If you’re looking to define, enforce and validate security across your Kubernetes ecosystem, you might want to consider Styra. Styra combines open source and proprietary solutions to provide compliance guardrails to ease compliance of secure applications. With Styra you no longer have to hard-code compliance into your software. Instead, you define policy once and enforce it whenever and wherever. Styra includes a built-in library of compliance policies, the ability to monitor and validate policy changes before committing, use of a declarative model to define the desired state and prevent security drift, and much more.
Of course, there’s a plethora of tools to help you lock down container security, but this should serve as a solid launch point to get you started. Do not neglect the fundamentals of building secure containers from the ground up. And as you scale out, make sure you’re expanding your efforts by employing powerful tools to get powerful results.
Red Hat is a sponsor of The New Stack.