Navigating Compliance Challenges in a DevOps World
Less than three months after Kubernetes’ first serious security vulnerability was discovered, news broke out about a new and even more severe container escape vulnerability impacting runC (details can be found here). This latest discovery has once again brought container security concerns to the forefront, with compliance challenges right on the heels.
Compliance remains one of the central considerations for container adoption, especially in highly regulated sectors such as health care and financial services. As organizations deploy more containers in production, they often discover that their existing security tools are inadequate for addressing container compliance challenges. While containers have fundamentally accelerated application development, organizations using them still must adhere to the same set of external regulations, including NIST, PCI and HIPAA. They also must meet their internal policies for best practices and configurations.
Container Compliance Challenges
Speed of DevOps
One of the challenges organizations face in adhering to compliance policies is a direct result of the microservices architecture and continuous deployment models in use in DevOps environments. Traditional application development methodologies afforded compliance and audit teams enough time to run their checks to ensure continuous compliance with relevant policies.
Containers and microservices have dramatically altered application development, with some organizations pushing changes to production 50 or more times a day. For most compliance teams, containers pose an unfamiliar challenge with little in the way of pre-existing procedures and tooling to both have and demonstrate that they have the necessary controls in place to secure their container and Kubernetes environments.
The speed and ease with which containers allow application or application updates to be packaged and deployed can lead to mistakenly introducing vulnerabilities that security might not have the time to catch.
For example, one of the primary directives for the Payment Card Industry Data Security Standards (PCI DSS) is to “build and maintain secure network systems.” The penalty for non-compliance with PCI DSS could be as severe as payment brands terminating card-processing privileges for the violating merchant, which would be catastrophic to a business. Identifying network connections between nodes and clusters, or containers and pods, and ensuring they are configured in a compliant manner can be a daunting task when you have a sprawling infrastructure that is in constant flux.
Similarly, the Health Insurance Portability and Accountability Act (HIPAA) Security Rule requires implementing strict access management policies to electronic protected health information. The default network policy configurations for Kubernetes is wide open, allowing groups of pods to communicate with each other and other network endpoints. Restricting access requires you to create network rules in YAML files, which is a painful and cryptic endeavor, especially in large Kubernetes deployments.
For these reasons, compliance assurance checks must be fully automated and embedded within the DevOps workflows—across all layers of the infrastructure, including pods, clusters, namespaces and nodes—such that every application update is compliant with relevant policies in the build phase and non-compliant components are prevented from deploying to runtime environments.
Additional challenges include:
- Using open source image registries to build containers can introduce vulnerabilities—All base images must go through vulnerability scans to be compliant. In addition, some policy frameworks, such as PCI DSS, require that organizations implement a system to rank and prioritize the highest-risk vulnerabilities ahead of the low-risk ones. This process can be extremely difficult because you could have a vulnerability that’s in a cluster in a test environment but not in production, and it’s being used for an internal application only, with zero exposure to external networks. At the same time, this same vulnerability could be present in a running deployment in production with escalated privileges that’s open to the internet. Ensuring this second instance of the vulnerability is prioritized over the first can be difficult.
- Preparing for compliance audits—Compliance audits are lengthy and tedious, and it can slow down development velocity, which is anathema to DevOps. Enabling automated, continuous security fits the DevOps model.
Container and Kubernetes Security Best Practices for Compliance
Follow these recommendations to create a more compliant container and Kubernetes environment:
- Understand image vulnerabilities: By some estimates, up to 30 percent of images downloaded from Docker Hub or other registries have a vulnerability.
- Enable role-based access control for Kubernetes: Once enabled, avoid using clusterwide permissions and instead use namespace-specific permissions.
- Use namespaces: Most compliance frameworks encourage or require that you isolate your sensitive infrastructure components. Namespaces is a first step in isolating and applying security controls for different components compromising of sensitive workloads.
- Limit container resources: The risk of introducing a security flaw is positively correlated with the number of running containers in an environment as well as the amount of resources consumed.
- Look for compliance-ready security tooling: Ensure that the platforms you put in place to secure Kubernetes and containers also provide compliance-specific features such as dashboards and exportable CSV files and reports to make it easy to provide auditors with evidence of your security controls.
In addition, follow these container security best practices to help you pass your next compliance audit.