How to implement secure continuous deployment with containers?

How to implement secure continuous deployment with containers?

In recent years, containers have had a significant impact on application modernization for both small and large organizations. A container consists of an operating system (OS), runtimes, libraries, and the app binary itself, enabling applications to move between a variety of computing environments, such as from a physical machine to the cloud or from a development environment to staging and production. They are useful software packages, but they are not built with a security system of their own. Therefore, it is possible that they may introduce new attack surfaces that can make applications vulnerable to attacks.  

 What is container security? 

 Container security is the process of implementing various tools and solutions to ensure that all components of the container are protected, including container applications, infrastructure, and more. The objective of container security is to protect containerized environments, which are much more complex compared to traditional workloads. It is a continuous practice that should be fully integrated into the entire development cycle. By implementing security as an essential part of your continuous deployment cycle, you can mitigate risk and reduce the number of vulnerabilities. To ensure efficiency, you should automate manual changes. This includes not only development tasks but also those linked to the maintenance and operation of the underlying infrastructure. For instance, you should secure your built pipeline container images as well as the runtime host, chosen platform, and all application layers. 

 What are possible security threats to manage? 

When it comes to securing your containers, it is important to understand the possible security threats before developing solutions to prevent them. Here are the most common security threats for containers. 

Untrusted Containers/Image Vulnerabilities 

Bu resim için metin sağlanmadı

Image vulnerabilities remain the most common type of security threat to containers. A vulnerable container image is a security risk that is embedded inside a container image. While vulnerable images themselves do not act as an active threat, if containers are created based on a vulnerable image, the containers will transfer the vulnerability to a live environment. 

Untrusted packages or other peripheries that are imported into an image typically cause vulnerabilities for container images. Images could also contain malicious code that was inserted during a software supply chain attack or a similar breach of the development environment.   

Application Exploits 

These are typical bad-coding practices that allow an exploitation or a security breach into the application. Some examples are SQL injection, cross-site scripting (XSS), and weaknesses in cryptography key generation and authentication, as well as incorrect use of cookies. No matter how secure you try to make your container images and the environment in which they run, it is possible to have security issues if the application is using containers containing weaknesses inside its source code. For example, insufficient data input validation could permit attacks like SQL injection, allowing attackers to access sensitive information.  

Repository Compromise 

Although some repositories are popular, this does not mean that they are completely safe and protected from all sorts of attacks. In 2019, Docker announced that their Docker Hub user database was compromised by a hacker for a brief period. Approximately 5% of the Docker Hub users were affected by this data breach. The data compromised included usernames, passwords, and version control system credentials like GitHub, Bitbucket, and GitLab tokens. 

Secrets Management 

Secrets management is critical to container security. Just as with traditional virtualization, securing secrets remains a prime security concern when using containers. In the context of containers, you need to think about protecting sensitive information, such as usernames and passwords, API keys, certificates, and tokens at every level. Secrets management defects can arise in many ways. Credentials may be hard coded in scripts placed in containers by developers. Secrets may be stored in an insecurely configured secrets management system. These kinds of defects could allow an attacker to gain access to sensitive data or be able to cause a more dangerous consequence.  

Automate security checks in CI/CD pipelines 

To ensure security checks and tests are performed regularly, automation should be applied wherever possible. Security configurations can be automatically created and updated even if applications and deployment processes are frequently changed. Here are some methods and tools that may help you to secure your containers with automation in your pipelines: 

Bu resim için metin sağlanmadı

Static Code Analysis 

Static code analysis can be defined as the practice that allows you to automatically detect potential bugs, security issues, and defects in software without executing them. We can think of static analysis as an additional automated code review process in the CI/CD pipeline. The code review process is one way to improve the quality of the code. During a code review, a pair of programmers read the code with the precise goal of improving it and spotting dangerous practices from both maintainability and security perspectives. In terms of maintainability, the complexity of the code should be reduced as much as possible. The automated code review works well because it is easier for the programmer to spot bugs and suggest improvements to the code. With it, you have distinct options for static code analysis tools. One of the most preferred platforms for code analysis is SonarQube. 

SonarQube is an open-source platform for the continuous analysis of code quality to perform automatic reviews with static analysis of code to detect bugs. It improves the quality and security of your codebase, and it supports 29 programming languages. SonarQube offers reports on bugs, duplicated code, code coverage, code complexity, coding standards, unit tests, and security recommendations. Whether it is on-premises or in-cloud, SonarQube has the flexibility to connect with your DevOps platform, and it will fail your pipeline if the Quality Gate does not pass. 

Hardening Container Images 

The main purpose of hardening container images is to analyze their current security status and then make improvements to address any concerns. In the container Dockerfile build process, it is typical to have log files, secrets, and other kinds of data that will not be in the final container image. To prevent these files from being included in the build context, the .dockerignore file could be used to leave out specific files or directories from the build process. It also helps to protect any secrets data or credentials from accidental leaks. 

Using a base image like Debian:latest may seem secure, but using it as-is could expose your container image to hidden threats. It is possible that images on Docker Hub can come with outdated software packages. Images may also be configured with insecure default settings that put the workloads at risk. A typical hardening process will address possible weaknesses by updating necessary packages and actively looking for known vulnerabilities. At the end of the process, a new base image can be created so that you can safely use it within your pipelines. 

Image Scanning 

Without a security scan, it is impossible to know whether your image is safe to use. There are several solutions capable of scanning images for vulnerabilities. Most of the tools available in the market run similar assessments, usually based on lists of known common vulnerabilities and exposures, that produce a list of problems you can analyze and fix. 

Anchore is an open-source project that analyzes docker images. Anchore can be run stand-alone or with orchestration platforms, such as Kubernetes, Amazon ECS (Elastic Container Service), and Docker Swarm. Anchore can be integrated into your CI/CD pipelines, such as Jenkins, via a plugin to secure the CI/CD pipeline by adding image scanning. After building the image in the pipeline, you need to submit the docker image to Anchore, which will then analyze and provide you with the details if it has any vulnerabilities. Anchore can also be used to scan repositories and automatically add any tags found in the repository. Once added, the Anchore engine will poll the registry to look for changes periodically. 

Clair is another open-source project for scanning vulnerabilities and running static analyses for container images. Clair scans each container layer and provides a notification of any vulnerabilities that may be a threat. It is based on the Common Vulnerabilities and Exposures (CVEs) and similar databases from Red Hat, Ubuntu, and Debian. Clair exposes application programming interfaces (APIs) for clients to initiate and perform scans in your pipelines. It is also possible to build services using Clair that can monitor the containers continuously for any container vulnerabilities. 

If you are using a cloud-based solution for container registries, such as AWS ECR (Elastic Container Registry), the scanning process becomes straightforward. In AWS, Amazon ECR image scanning helps in identifying software vulnerabilities in your container images. ECR offers two types of scanning—enhanced and basic scanning. With enhanced scanning, Amazon ECR integrates with Amazon Inspector to provide automated, continuous scanning of your repositories. Container images are scanned for both operating systems and programming language package vulnerabilities. As new vulnerabilities are detected, the scan results are updated and Amazon Inspector passes an event to EventBridge, a serverless event-based service, to notify you. For basic scanning, Amazon ECR uses the CVE database from the open-source Clair project. With basic scanning, you configure ECR to scan, or you can scan manually, and AWS provides a list of scan findings. 

Each solution has similar functionalities for image scanning. Once you have selected the right tool and applied it to your pipeline, you can take different actions based on the results of the analysis. Keeping a record of your scan results may be a good idea so that you can reference addressed vulnerabilities in the future. 

Image Signing 

Image signing allows you to add a digital fingerprint to a container image. Signed images allow the user of a container image to verify the source and trust the container image. Image signing can be applied when an image is pushed to the image registry. Cosign and Notary are two of the tools available for signing and verifying container images. For Docker registries, Docker offers Docker Content Trust (DCT), which can use digital signatures for data sent to and received from remote Docker registries. Using DCT, publishers can sign images, and consumers of the images can ensure that the images they pull are signed. 

User Access Controls 

Your containers may be hosted on multiple systems or cloud platforms, which makes access management more important. API keys, tokens, and login credentials should be stringently managed to ensure container access is limited to privileged users. User access can be defined by role-based access control, allowing you to restrict access when needed. If you are using a private registry, you need to establish access controls that specify who can access and push images and who cannot perform this kind of action. 

 

Although every organization has a different container architecture, when it comes to container security, there are many issues and risks to consider. While this can sometimes be a simple user-related problem, sometimes it can be an important vulnerability on the application side. By implementing the above-mentioned controls in your CI/CD pipelines, you will be able to reduce the risks you face, thereby strengthening the security of your containers. 

To view or add a comment, sign in

Insights from the community

Others also viewed

Explore topics