Everything You Need to Know to Get Started With Container Security

The use of containers has grown exponentially over the past several years. While container technologies have existed for decades, it was the launch of Docker in 2013 that made it more practical for organizations to adopt a container-first development and operations model.

Along with this growth comes security risks. With millions of available images to choose from, securing containers is a dedicated discipline. There are many layers of security that apply to containers, such as:

• The container image and software inside

• The interaction between the container, host operating system, and other containers on the host

• The host operating system

• Container networking and storage repositories

• The runtime environment, often in Kubernetes clusters

As each layer deserves a guide of its own, this guide focuses on the first aspect: the image and your code. A single container image can contain hundreds or thousands of vulnerabilities, which can expose your organization to security incidents (like a breach) and lost productivity  (from the amount of time it takes to triage and assess vulnerabilities as the number of images in use grows).

What is container security?

Application security was traditionally the responsibility of dedicated security teams, but the way containers are defined and built means that responsibility increasingly falls in the hands of developers and DevSecOps teams.

This shift in responsibility, along with the speed at which containers can be updated and deployed, requires a practical security methodology that goes beyond scanning your containers in CI” and following image best practices to address a scan that reveals hundreds of vulnerabilities.

We’ve previously created a guide for container security with Docker. Check out our 3 practical steps to secure a container image for more hands-on guidance. In this post, we’ll give an overview of the DevSecOps practices organizations are using to build safer container images and running containers, and introduce the technical tooling — such as Snyk Container, Snyk IaC, and our partnership with Sysdig — that provides comprehensive container security from development to runtime.

Why is container security important?

Container security is important because the container image contains all the components that will, eventually, be running your application. If there are vulnerabilities lurking in the container image, the risk and potential severity of security issues during production increases. To that end, you want to monitor production as well. You can create images with no vulnerabilities or elevated privileges, but you still need to monitor what’s happening in runtime.

An overview of container security in different ecosystems

Docker container security

Docker's enormous user base — with tens of millions of users and hundreds of billions of image pulls — shows that containerization is changing how applications are built. The responsibility for security is increasingly shifting to developers. It's important to scan Docker images before pushing them to Docker Hub or other registries in order to find and fix vulnerabilities in Linux packages, user permissions, network configurations, open source tools, or access management. Such a scan can help you uncover and remediate vulnerability issues in your application and infrastructure before you ship.

Kubernetes container security

Kubernetes offers a myriad of security controls to help make your clusters, workloads, and containers safer. It's important to note that Kubernetes requires self-configuration since none of the security controls are configured when you deploy Kubernetes. Furthermore, while Kubernetes offers controls and features to help create a secure cluster, the default security configurations often aren’t enough. Deploying workloads securely requires expertise in Kubernetes. Check out our page on Kubernetes security best practices to learn more.

GKE container security

Google Kubernetes Engine (GKE) provides many tools to secure workloads. It’s good to take a layered approach to GKE security by configuring security features for access controls, workloads, and other security aspects. GKE can be run in standard mode, where you manage the underlying infrastructure, and autopilot, where GKE provisions and manages the infrastructure. The Snyk Container Kubernetes integration allows customers to secure workloads on GKE, in either standard or autopilot, uncover vulnerabilities in both container images and application code, and scan your Kubernetes configurations for issues.

AKS container security

Microsoft Azure Kubernetes Service (AKS), like GKE, comes with robust security features, such as integration with Azure Policy and consistently fast updates/patches. However, it requires a semi-manual process to upgrade cluster components to newer versions, and requires network policies to be enabled when creating the cluster. As with GKE, Snyk can scan your Kubernetes configurations and containers, and enable automatic monitoring as you deploy AKS resources.

EKS Container Security

Amazon Elastic Kubernetes Service (Amazon EKS) has a strong set of security features by default, and operates on the AWS shared responsibility model — which defines who is responsible for the different elements of container security. Usually, AWS is responsible for security "of" the cloud whereas you, the customer, are responsible for security "in" the cloud.  As with other Kubernetes options mentioned above, Snyk integrates with Amazon EKS and Amazon Elastic Container Registry (Amazon ECR) easily, to scan your Kubernetes configurations and containers, and enable automated monitoring as you deploy to Amazon EKS.

Using Snyk Container to secure containers

With millions of container vulnerabilities in the wild, finding, prioritizing, and remediating vulnerabilities can be overwhelming to developers. Snyk Container cuts through the noise of typical vulnerability reports by detecting and fixing application and container vulnerabilities together, even if you don’t have access to the original source code running in your containers.

Snyk Container continuously scans for new vulnerabilities, prioritizes fixes based on context and exploitability, uncovers issues in open source dependencies, and matches vulnerabilities to Dockerfile commands to make it easier for developers to introduce fixes. Snyk Container was used to conduct over 130 million container tests in 2021, and 56 million vulnerabilities were fixed by Snyk Container users.

Working in tandem with Snyk Infrastructure as Code to secure configuration for containers, Snyk Container integrates with many Kubernetes platforms including AKS and GKE, container registries such as  Docker Hub, GCR, and Quay, and container base operating systems including Amazon Linux and Ubuntu, and many more. Integrated vulnerability scanning helps developers identify and use suitable minimal base images and automates the update process to quickly eliminate vulnerabilities.

Snyk Container, like the rest of the Snyk platform, is built with a developer-first approach and supports the DevSecOps culture. It integrates into the IDE, scans pull requests before merging, gives guidance for fixes, and applies automated tests to CI/CD pipelines. Once containers are running, it continuously monitors deployments for exposure to existing or newly disclosed vulnerabilities. Alerts are then sent via Slack, Jira, email, or other methods, to help DevSecOps quickly identify and remediate vulnerabilities.

How the Snyk-Sysdig partnership enables container runtime security

Snyk Container’s early image feedback can help cut out 70% or more of vulnerabilities — but potentially 30% of runtime vulnerabilities remain unaccounted for. These can add up to hundreds of vulnerabilities across thousands of containers and numerous clusters. Finding and fixing these vulnerabilities can be daunting. It’s difficult to tell which packages are used in a running container, and which vulnerabilities affect those packages executed in runtime. The security and operations teams responsible for managing live environments have to uncover vulnerabilities, before involving development teams to fix them. And since developers lack systems expertise, legacy vulnerability tools may take months to find and fix issues.

Snyk partnered with Sysdig to help resolve issues in runtime environments by giving more context on what is affecting the runtime environment. This partnership creates a security solution that spans the entire DevOps process. The combination of Snyk and Sysdig platforms secures everything from code in the developer environment to the infrastructure running the cluster.

Check out this announcement post to learn more about how the Snyk-Sysdig partnership extends container security to the runtime environment.

Container security wrap-up

Container security is a broad topic, and even limiting the scope to base image security presents numerous challenges to consider. When it comes to securing your images, here are a few key points to keep in mind:

• Start with base images from a trusted provider, and use digital signatures to verify authenticity.

• Opt for minimal base images with only the basic operating system packages and your framework of choice, then build up from there.

• Check images for vulnerabilities early and often.

• Scan throughout the software lifecycle: the desktop, in CI, stored images in registries, and the containers running in your clusters.

• Choose scanning tools that go beyond basic spreadsheet-style vulnerability reporting, but instead, provide mitigation advice, recommend base images, give developers information to fix any issues, and provide the flexibility you need to set your security gates.

If you’re interested in securing your container images across their lifecycle, Snyk Container automates container security in a developer-first manner, providing the right balance of security and productivity so you can build more secure images and running containers.

Container Security Glossary

• Container scanning: The process of finding vulnerabilities in containers by scanning packages and dependencies in a container image

• Container monitoring: The collecting of metrics and health tracking the health of containerized applications and architectures

• Kubernetes: An open source system originally developed at Google for orchestrating containerized applications across a cluster.

• K8s: An abbreviation for Kubernetes.

• Docker: The most popular container platform in the world. Docker democratized the tooling and processes around container creation and execution, empowering developers to use these technologies easily.

• Dockerfile: A text file containing the configurations needed to build a Docker image.

• Google Kubernetes Engine (GKE): GKE is Google's managing service offering for running Kubernetes workloads on Google Cloud.

• AKS: Microsoft Azure's managed Kubernetes service. It began as a more generic Azure Container Service then evolved into AKS when Kubernetes became the dominant container orchestration platform.

• AWS EKS: Amazon Web Service’s managed Kubernetes service for running Kubernetes workloads on AWS. AWS EKS can be used on its own, or with other services like AWS Fargate. AWS Fargate essentially hides all Kubernetes infrastructure, allowing users to focus only on their own Kubernetes pods.

• Container image: A static file that contains a set of instructions for creating a running container

• Container Registry: A container image repository and management tool that makes it easy to store and share container images.

• Container runtime: Software that creates, runs, and manages containers on a host operating system.

• Shift left: A culture and set of tools that incorporates security into developer workflows

• DevSecOps: Short for development, security, and operations, DevSecOps is an approach that automates security in the software delivery lifecycle.

Container Security FAQ