Journey to Containerized Workloads: Security Pitfalls and How To Dodge Them With Tenable Cloud Security 

Tenable Cloud Security now includes built-in container security functionality, so you can detect and prevent insecure containers from being deployed to production. In this blog, you’ll learn how Tenable can help you avoid critical container security mistakes. 

As companies adopt containers in the cloud, they often unwittingly adopt vulnerabilities along the way. This happens for various reasons. For example, some companies may lack the processes needed for security in complex Kubernetes environments. Meanwhile, others might lack a centralized strategy and try to implement too many tools and policies, causing alert overload, confusion between teams and security gaps. Regardless of the cause, the containerized application development process can be a minefield of security concerns. Understanding what those security issues are and what you can do to avoid them is a practical first step in securing your cloud workloads. 

Container security governance with Tenable

With container security tools like Tenable Cloud Security, you can see the security posture of your container images and registries pre-deployment, as well as have visibility into the rest of your cloud environment. Tenable Cloud Security allows for true DevSecOps. Security teams can set security standards across teams and get visibility into environments, while DevOps teams get the information they need to remediate vulnerabilities and policy violations as early in the development process as possible. This reduces risk and empowers DevOps teams to embed security in their workflows under the security team’s governance.

Container security has long been part of the Tenable platform, but now these capabilities have been broadened and streamlined. Now, as part of Tenable Cloud Security, container security capabilities extend from developer workstations to image registries, with assets and findings integrated into centralized dashboards providing actionable insights and KPIs. Coupled with existing infrastructure-as-code scanning, Tenable Cloud Security offers complete code-to-cloud security.

Managing and evolving processes to meet the security needs of container infrastructure is integral to the success of Tenable customers in the cloud.

Let’s begin where most developers start when containerizing applications: by creating a container image. 

Pitfall #1: Unscanned base images

It’s a common DevOps practice to save time by using publicly available base images from container-image libraries like DockerHub. Developers can then modify the image to fit their project needs. However, this does not come without risks. When using prebuilt public images, it can be unclear if the image has been recently maintained, if it meets your company’s security requirements or if it has been compromised with hidden vulnerabilities. In addition to public container base-images, developers also define their own images and by doing so might automate the use of untested, insecure base operating systems.

How to avoid these pitfalls: 

The answer to this is not to unilaterally declare that all images have to be built in-house. A great thing about cloud computing is the communal sharing of resources and best practices. The very foundation of cloud-native infrastructure stems from a deep open source history. 

For example, the security team may establish policies that ensure when developers pull a base Ubuntu image, they must make sure it has all of its most recent patches and has been updated to its latest version. You also can start by taking advantage of the Center for Internet Security’s (CIS) pre-hardened images, which are built from common operating systems, but are designed to meet specific security benchmarks. These practices dramatically reduce initial vulnerabilities, creating far less alert “noise.” 

With Tenable Cloud Security you can scan and remediate container images as part of local build processes. Tenable scans images based on tailored policies. These images are scanned for vulnerabilities so they can be fixed before they move through the highly-automated container development process. 

Once developers have built these container images, the images go sit in repositories and registries. This step often leads to another very common container security pitfall - registry vulnerabilities. 

Pitfall #2: Registry vulnerabilities 

The constant push and pull of container registries means that ensuring the security of what’s coming in and going out of them is essential. Whether container registries are public or private, mismanaging their access and privileges can lead to attackers gaining root access to a user’s host environment. Over-privileged container images can not only be used to laterally creep and exploit vulnerabilities in other parts of the build process, but they also can waste resources and drive up expenses. Additionally, registries can harbor misconfigurations that must be remediated before being pushed into production.

How to avoid these pitfalls: 

The National Institute for Standards and Technology (NIST) provides numerous countermeasures for registry vulnerabilities in the Application Container Security Guide. One measure states that registries are the place to put context-aware authorization controls to use. 

“For example, organizations can configure their continuous integration processes to allow images to be signed by the authorized personnel and pushed to a registry only after they have passed a vulnerability scan and compliance assessment. Organizations should integrate these automated scans into their processes to prevent the promotion and deployment of vulnerable or misconfigured images,” the NIST guide reads.

Tenable Cloud Security provides those vulnerability and compliance assessments. Users can enable auto-scanning of the artifacts in container registries and then automate scanning these artifacts in pipelines as well. Alongside those vulnerability and compliance assessment capabilities, Tenable Cloud Security has built-in policies to detect and remediate common registry misconfigurations. 

After a container artifact leaves the registry, it moves through the pipeline for deployment via a container orchestration platform. It’s no secret that container orchestration platforms like Kubernetes (K8s) are complex. Security can be challenging, and necessary visibility is often lacking. This makes misconfigured Kubernetes clusters one of the most precarious security pitfalls. 

Pitfall #3  Misconfigured Kubernetes clusters 

Container orchestration platforms like Kubernetes do not check or verify the containers they are deploying, and they also can be misconfigured themselves. NIST reports in the Application Security Guide that misconfigured orchestrator nodes can lead to increased risk, including:

• Unauthorized hosts joining the cluster and running containers 
• The compromise of a single cluster host implying compromise of the entire cluster—for example, if the same key pairs used for authentication are shared across all nodes
•  Communications between the orchestrator and DevOps personnel, administrators, and hosts being unencrypted and unauthenticated

How to avoid these pitfalls: 

Container orchestration platforms are often configured for speed and not security. It must be a priority to ensure proper and secure configuration without drift. In that same Application Container Security Guide report, NIST also states countermeasures for securing orchestration platforms. 

“Orchestration platforms should be configured to provide features that create a secure environment for all the apps they run. Orchestrators should ensure that nodes are securely introduced to the cluster, have a persistent identity throughout their lifecycle, and can also provide an accurate inventory of nodes and their connectivity states,” the NIST guide reads.

When containers are deployed as part orchestration software like Kubernetes, Tenable Cloud Security can validate configurations and access control policies for underlying Kubernetes and cloud infrastructure. Users can also view aggregated security results of all of their K8 clusters and drill down into specific remediation steps based on priority. With Tenable Cloud Security, you can flag the top five vulnerable clusters as well as all clusters running in your environment with Kubernetes Security Posture Management capabilities. 

Prevention: The key to containerized workloads

You’ve probably noticed a pattern amongst all of the solutions to these pitfalls - all of them occur pre-deployment and can be fixed before you put the container into production. This isn't a new principle. “Shift Left” has been the buzzword of choice in the cloud security world for years now. However, it’s extremely difficult to shift left with point security solutions designed to cover only portions of the attack surface. The Tenable One Exposure Management Platform solves that. 

Tenable Cloud Security as part of the Tenable One Exposure Management Platform is the only comprehensive solution that gives you insight and prioritization of vulnerabilities across the attack surface. With Tenable, you define a single policy framework from build to deployment and then continuous access risk using Cloud Security Posture Management (CSPM) and Kubernetes Security Posture Management (KSPM) solutions during runtime. With container security now integrated into Tenable Cloud Security, you can see the security posture of your container images, registries, and Kubernetes clusters in a single view alongside the rest of your multi or hybrid cloud deployments.

Learn more 

• Read the press release 
• Read the white paper 
• Check out the solution web page 
• Join us for a Cloud Security Coffee Break