Container Security
Shift Left: Moving Container Security into the Dev, Test, and Build Process
Learn how you can use a DevOps methodology that optimizes application deployments and provides greater security for containers. This article explains how to move security into the container creation process in the DevOps workflow.
Save to Folio
More organisations are applying a DevOps methodology to optimise application workload deployments. Streamlining infrastructure deployment, whether on-premises or in a public-hybrid cloud, as well as integrating application component publishing itself, brings value to the organisation as well as its customers.
A typical deployment involves a development and test stage, where testing of code stability and overall application functionality occurs. From there, the code could go through another series of tests (typically performance testing) in a staging environment before it is redeployed to the final production environment.
Once the software is running in production, the DevOps team maintains and manages the workloads, ensuring uptime, performance, and scalability. The DevOps team safeguards the application by monitoring potential attacks, patching the underlying platform, and mitigating threats. This process has become harder given the significant number of worldwide attacks on publicly accessible workloads and, often, from inside the organisation. A zero-trust approach is key here.
Next, as a result of the move to containerised workloads, the infrastructure surface, as well as how containers work together, becomes less obvious. What if the threat is already part of the application? Especially in a container-based architecture, part of the application stack is likely from already available baseline containers—your DevOps team doesn’t always control these.
Security and validation, as well as mitigation, are the primary focuses. These concerns arise primarily when an application is running. In this case, “moving to the left” or “shifting left” means integrating security measures as close to the planning and building phases as possible. In this article, we’ll cover container security threats and how a shift-left approach minimises these threats.
Shifting left? Introducing CI/CD Pipelines
Continuous integration (CI) refers to the left part of the flow. That’s where the infrastructure build, templates and scripts, as well as the application code, are created and validated.
The second half of the cycle is continuous delivery or deployment (CD). This is when the cycle deploys and provisions the application, and then monitors and maintains it.
Together, CI and CD are called a CI/CD pipeline. If we focus on the DevOps concept of CI/CD pipelines, it reflects the following (continuous) motion:
A CI/CD pipeline helps you automate the steps in your software delivery process, such as initiating code builds, running automated tests, and deploying to a staging or production environment. Automated pipelines remove manual errors, provide standardised development feedback loops, and enable fast product iterations.
A popular type of CI/CD pipeline is called GitOps. GitOps is a type of CI/CD pipeline insofar as it means providing an automated deployment mechanism and aligning deployments across developer teams and operational teams. However, it is different from other CI/CD pipelines.
In short, GitOps is the combination of Git, the source control application, and Ops best practices. It provides an operating model for Kubernetes and other cloud-native technologies, which unifies deployment, management, and monitoring of containerised clusters and applications.
Now that we’ve covered the basics of a CI/CD pipeline, let’s spend a few minutes focusing on possible security threats, especially when using containers.
Security Threats in Containers
To protect your container throughout its lifecycle (build, deploy, run), you must understand the potential risks and threats involved in using container tools like Docker, Kubernetes, and OpenShift. Below are some of today’s most common container security threats.
Access and Authorization Exploits
These are similar to threats in traditional virtual machine architectures. Knowing authorised users (and blocking) the people targeting your applications and underlying systems is crucial to a healthy operational platform, and establishes the baseline of zero trust. If your authentication and authorisation functions are poorly configured, they might provide access to your container hosts as well, which is a huge security risk to the full containerised environment.
The same applies to confidential content like secrets and keys that provide access to application resources. You should never store this kind of information in configuration files (for example, web.config and appsettings.json), particularly in a containerised setup. Where possible, try to store these secrets in a secret store such as, HashiCorp Vault, Microsoft Azure™ Key Vault, and others.
Container Image Vulnerabilities
The current list of available Docker Hub systems and application baseline images tops 100,000. Unfortunately, not all should be trusted, because anyone can build and upload a container image to Docker Hub.
In early 2019, Docker released information that a hack gained access to about 5% of all Docker Hub stored container images.
To prevent an attack like this, you should have a security mechanism as part of your CI pipeline, such as scanning code for vulnerability as a pre-scan task during the CI cycle.
Detecting vulnerable code, outdated packages, malicious code, or similar threats during the build stage should improve your security dramatically. Only detecting vulnerabilities when the application is already running and in use could be too late and more costly to fix.
Container Privileges to Host Systems
As a container does not have an operating system, it fully relies on system objects assigned to it from the host environment. By design, the container just needs the dependencies and packages to run the application. Therefore, the container during runtime needs enough privileges to have access to the system objects it needs, but to nothing else.
In a few situations, a container can gain root access to the host. Most times this can be due to misconfigurations that give too much privileged access, or it can be exacerbated and exploited by vulnerabilities in the container image itself. This can possibly threaten all other containers running on the same host (or host group) via lateral movement.
Overall Application Hierarchy Security Risks
As mentioned earlier, container-based workloads are similar to traditional workloads. To help bridge the gap between you and SecOps teams, think
You have to secure access rights to the container, (which individuals peoples and processes have access to the container environment, secure network traffic to and from the container, host level security (running on latest version of Kubernetes for example)
One unique aspect to consider regarding container-based workloads, rather than traditional workloads, would be open source packages. Vulnerabilities from using outdated packages or even vulnerable associated open source dependencies could put your application and container image at risk of being exploited. You should scan your container images for outdated or insecure packages in both your CI/CD pipeline, container registry, and also monitor runtime for threats.
How Can Shift Left Optimise Container Security?
Moving security implementation into the development, test, and build side of the process dramatically improves the integration of security visibility and remediation into the process. The overall goal here should be to automate as much as possible, no matter the target environment or architecture.
Accountability and traces are the key to DevOps and GitOps. Relying on standard or GitOps compatible processes like branches, pull requests, and commits helps developers write secure code with trustworthy packages and artefacts. It also helps infrastructure teams avoid storing secrets or other confidential information in deployment templates or, worse yet, the container images themselves. Moving security practices from the post-build, runtime side scanning to addressing security in the application and container creation process in the DevOps workflow is a “shift left” approach to security.
Introducing Trend Micro Cloud One™ – Container Security
Container Security is just one of seven solutions that make up Trend Micro Cloud One, a security services platform for developers building cloud-native applications, designed to simplify workflow and detect vulnerabilities.
Let’s explore how you can use Container Security to integrate security as far to the left as possible in your DevOps and lifecycle.
Container Security is a total-package solution that provides layered security, a broad depth of defence, and encourages developers to adhere to building best practices. After you implement Container Security as a fundamental part of the build phase, it will scan container images as they are built and provide protection once the images are built and already in use.
Container image scanning handles the starting point of the security scan. Typically, container images are stored in container registries. By integrating container image scanning into the registry, images can be continuously scanned as part of the CI/CD process in the registry or as they are built, preventing images with vulnerabilities from making it into the production registry.
As container orchestration services like Kubernetes pull images from the container registry, you can define policies to allow the use of these containers. For example, if Kubernetes tries to pull an unscanned image, it won’t be able to run it inside the Kubernetes cluster. Similarly, when a container image is flagged as having vulnerabilities, or even associated malware, the security policies will block use of the container image in any container runtime setup, as illustrated in the image below.
Next, similar to a traditional anti-malware engine running on virtual and physical servers and clients, Container Security automatically and continuously detects malicious traffic in containers that are running. This powerful capability provides runtime protection against remote code execution, illegal file access.
To manage all this, Container Security provides complete security lifecycle management. This could become your only source needed to manage overall security and protection of containers, from building to managing to operating.
Next Steps
Containers rely on DevOps and GitOps concepts and processes to enable end-to-end automation. DevOps enables organisations to benefit from an application provisioning process that brings teams together. While this process has been around for years, security is often neglected. Especially in a container-based architecture, integrating security as early as possible into the DevOps process⏤a.k.a moving to the left⏤improves workload protection and security.
Now that you know more about security risks in containers and the benefits of shifting left, you can set out to find a solution. Container Security, a total package of enhanced detection and protection, helps bring security into the build phase, during the container runtime phase, and any DevOps cycle in between.
If you are interested in improving your container security, you can experiment with Container Security by starting a free 30-day trial.
