Containers in DevOps are a no new concept. They are virtual sandboxes with all the necessary tools for running microservices, including large applications.
You can think of containers as packaging systems that allow you (as a developer) to store everything you need to run an application, for instance, runtimes and binary codes, from a centralized point.
Containers help developers move applications from one environment to another (like shipping an app from a local machine to a virtual environment or moving it from the initial to the production stage), eliminating all problems tied to different software and configuration settings in developers’ and production end.
Statista’s report on container technology shows that 50% of the globe’s organizations have adopted container orchestration. While this tech has increased adoption based on its benefits, containers could open a gateway for cybersecurity attacks if left unchecked.
CVE Details, the quintessential security vulnerability data source, has recorded 62 Docker-tailored vulnerabilities as of this writing. Doesn’t this call for best developer practices to address these pitfalls and safeguard containers for successful DevOps processes?
This post breaks down the concept of container security, highlights a few challenges, and guides you on the best practices to enact when using container technology.
What is Container Security?
Container security is a continuous process that uses security protocols (tools and policies) to safeguard containers and their environments from potential threats.
If unchecked, the threats can harm your application, its infrastructure, run times, system libraries, operating system, and kernel, among other features.
Considering that containers are available in transients (momentarily) and are also meant for dynamic deployments and scaling, there’s a need for automated security and every stage of the software development life cycle (SDLC).
Also read: Introduction to Kubernetes Kops for Beginners
What are the Challenges in Container Security?
While containers have plenty of rewards (like speeding up software delivery) under them, they are not immune to challenges, mainly because they need security measures (they lack self-security capabilities).
This is because containers access hardware through a hosted operating system (OS). It means that a single container can have several underlying container images introducing a wider scope for attack surfaces, presenting some challenges.
The first is Incorrect Container configuration, where developers forget to customize and use default container configurations which have some pitfalls like some exposed, insecure ports that may not be ideal for your application, leaked credentials such as passwords and authentication tokens, and overly issuing permission to container runtimes (when run as root). When not overridden, these default configs provide avenues for attacks.
Next is container infrastructure vulnerability. Here, packages built into the container, like application code, libraries, and configurations, or those on the host operating system, introduce vulnerabilities. Susceptibility can be introduced in any stage of an application life cycle, for example, when external dependencies are built into a container image, open-source libraries are installed as part of the application, container base images coming from third-party container registries and hosts that are exploitable through networks and endpoints.
Visibility into container workloads is among the biggest container challenge. This is due to the highly dynamic nature of containers that make monitoring tools unable to locate which containers are running and inspect their network behavior. Improved visibility prevents breaches and improves incidence response time if any happens.
Additionally, the container is susceptible if any phase of the CI/CD pipeline is insecure, either on the application code or the container workload infrastructure. While it’s common for developers to address security at the end of an application life cycle, administering it at every step of development safeguards your apps from this setback.
Which Tools Can Resolve Challenges in Container Security?
You can ensure that your deployed enterprise solutions are safe by enacting container security and integrity using security tools. These tools scan for vulnerabilities and constantly monitor them for attacks, bugs, or any issues.
Whether you’re searching for open-source container security tools or a commercialized type, all will serve the same purpose. They all operate by auditing your container infrastructure and running against common vulnerabilities and exposures (CVEs).
Here are a few tools you can try: Pingsafe Editors Choice, Datadog Cloud SIEM, Anchore, Sophos Cloud-Native Security, Bitdefender GravityZone, Sysdig secure, Aqua Security, and RedHat Advanced Cluster Security for Kubernetes.
Also read: 11 Container Security Scanners to find Vulnerabilities
The Best Practices for Container Security
Despite the above-posed challenges in container security, here’s a breakdown of the best conventions you can implement to optimize container security in all stages of the application life cycle.
Securing Your Images
You use container images to create containers. The slightest misconfiguration or malicious actions can trigger vulnerabilities in containers under production. You can counter this by:
- Using trustworthy images – When not creating your images from scratch, you’d always opt for working with images from trusted sources. Public repositories like Docker Hub have images, including those with malware and misconfiguration.
- Including the necessary components only – If there are components that your application does not need, it would be best to remove them. For instance, the UNIX system naturally presents ‘awk’ and “sed” binaries.
- Including your application in the container image – A container image clutches a subset of the operating system (OS) and the application running. For every tool and library pulled into the container, it’s a potential threat. It would be best to include the application in the container image to solve this. This is done through a statically compiled binary with all required dependencies.
Automating Scans for Vulnerability and Management
Regular vulnerability scanning and management of your container and hosts help detect vulnerabilities at any stage in the application life cycle.
In this case, you can enact code scanning to detect bugs and static application security testing (SAST) to find vulnerabilities in your application code. A software composition analysis (SCA) can provide visibility into open-source software components generating a software bill of materials that can be cross-referenced against documented open-source vulnerabilities.
Additionally, image scanning analyses the contents and your container image build-up process for susceptibility. With tools like Clair, you can scan for known vulnerabilities. Alternatively, employ dynamic application security testing (DAST), which points out security risks based on container behavior. DAST tools can also perform host scanning, where you inspect container host components (host kernel and OS) for misconfiguration.
While the above measures are adopted in the ongoing process of a container life cycle, you can embrace the “shift left” philosophy. It means implementing security right from the start of your development life cycle. A good tool if you choose this approach is Trivy.
Securing Container Registries
Container registries are an efficient centralized way to store images and distribute them. Often, organizations will have thousands of images stored in public or private registries. There are several measures to ensure all team members and collaborators use vulnerability-free images.
First, implementing a user access control (for private registries) establishes who can publish and access images. While this is a basic security measure, it prevents unauthorized persons from publishing, modifying, or deleting your images.
The next measure is signing your images which ties every image to the person who signed it, making it difficult to substitute an image for a compromised one. You can use the Docker Content Trust techniques to add digital signatures to data sent and received from registries. Finally, remember that scanning your images (continuously) aids in detecting any critical vulnerabilities.
Monitoring Containers
You can optimize the visibility into container workloads through observability tools. The tools should be able to monitor and test for vulnerabilities in all components and enable real-event time logging for the containerized environments.
Observability tools detect threats by auditing metrics and logs from all components of the container stack and analyzing them for abnormalities. With this approach, you’re able to rectify misconfigurations immediately when identified.
To collect resource usage metrics, use tools like cAdvisor or kube-state-metrics. For monitoring containers’ activity and the performance of your clusters, use tools like Grafana or Prometheus.
If you want to analyze network traffic between containers, use Wireshark or tcpdump. If you are on managed Kubernetes service like (AKS), use Azure Monitor to track resources and security threats.
Additionally, Azure Log Analytics can collect and analyze your AKS resources. If you choose the Amazon EKS, Amazon CloudTrail is good for logging and watching; use Amazon Cloud Watch.
Implementing Network Security
Network security control measures can help safeguard against unauthorized container access. The criterion employed here is network segmentation which isolates containers, limiting them to access necessary services only.
If you’re running your containerized applications on Kubernetes, you can use the K8s network policies to configure incoming and outgoing pod traffic in clusters. This, in turn, restricts traffic to specific pods based on labels.
The transport layer security (TLS) can be augmented for pod communication. You can opt for either TLS or the secure sockets layer (SSL) techniques for secure communication between the API server and other components. Load balancers are a good solution if you’d also want to limit traffic entry into your clusters.
If your clusters have microservices, you can ensure secure traffic through service mesh tools like Meshery or Linkerd. Lastly, secure your network if you’re using a cloud prodder to host your clusters.
If you’re on Azure Kubernetes Service (AKS), use network security groups (NSGs) for traffic management. If you’re on Amazon Elastic Kubernetes Service (EKS), the best fit would be Amazon virtual private cloud (VPC) security groups.
Reducing Surface Attacks
Minimizing the surface of attacks has two benefits; increased speed of service and lowering the potential for security breaches.
Using a multi-stage build, you can create lightweight images with a small surface attack and improved boot time and performance. There are several solutions to do this. If you’re on Linux, you can use Alpine Linux, BusyBox, or Tiny Core Linux.
For Ubuntu, there’s Ubuntu Minimal. You can also use Scratch, a special Docker image – essentially an open container, to build minimalistic images from the start.
Limiting Container Privileges
The principle employed here entails providing minimum permission to perform a given task. When containers are run as root, they grant a user various operation privileges like installing packages or read-write operation power on your operating system.
The risk is that attackers can leverage the escalation of power to the container runtime if compromised. That being the case, there are two viable solutions. You can run containers in rootless mode or restrict LINUX Kernel abilities to only those needed for container workload.
Managing Secrets Safely
Your container and docker configuration files should be free of secrets. Secrets include certificates, passwords, application program interface (API) keys, and tokens. And while this is the best practice, you’ll often see these secrets hard-coded into the build process or source code images.
In such instances, sensitive data gets into containers and is cached in intermediate container layers even when containers have been removed. For such cases, the best approach is to deploy a secrets management solution like AWS Secrets Manager and Vault to store and manage secret credentials.
Empowering Your Team
As the last of security measures, educating your team on the best security practices is crucial. This means that all your team players can identify and respond to security threats.
A good way to enact this is by adding container security to your team onboarding processes. Offering hands-on training, continuous learning, and regular security assessments sets your DevOps team apart by equipping them with updated security trends.
Final Thoughts
Container security is a crucial continuous process of the software development life cycle. The best approach to this query is incorporating security right from the application code to the container runtime, host operating system, and the underlying network infrastructure.
You can realize this by following a strategic plan involving verifying containers and only using those from trusted sources. Undertake container hardening to ensure they only have the necessary services in them. Instill logging methods that are easily enacted through monitoring tools. Segment your network so that containers are separated from the overall infrastructure.
Always sign your images to validate data input and output through your services. Additionally, you should have regular scans and penetration tests to check for any vulnerabilities and take corrective actions immediately. And as the technology landscape evolves, always stay updated with the latest security practices.
Next, check out how to automate security.