Shift Left: Moving Container Security into the Dev, Test, and Build Process Solution Engineer

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 standardized 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 containerized 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 authorized 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 authorization functions are poorly configured, they might provide access to your container hosts as well, which is a huge security risk to the full containerized 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 containerized 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 Optimize 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 artifacts. 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.

Read More HERE