how-codenotary-can-protect-you-from-using-compromised-container-images

 

The above video to use CodeNotary to sign a Docker container image. Be sure to note how the video ends with all but one container verification failing, which is exactly as it should be since only one container was signed in the demo.

Risk surrounds everyone everyday. For coders, risk is especially important to pay attention to as the fallout from a compromise can cause huge damage blows to a well crafted and hard won reputation. Hacks, especially ones that could have been prevented in the first place by employing simple security measures, have a particularly nasty sting to them. This blog will take you through some of the differences and similarities between Docker and Kubernetes and how these container management tools can be maliciously altered. It will also demonstrate how you can protect yourself from using potentially compromised /images/blog and save yourself and your company a lot of time and money by avoiding the otherwise inevitable aftermath cleanup.

 

When Would You Use Docker or Kubernetes

 

Containers are a way of packaging software so applications can be isolated from the rest of the system. Using them makes runs and reruns predictable and repeatable. Though both Docker and Kubernetes utilize containers, they are not the same. They can both run independently and without having to leverage the benefits of the other. However, together the are greater than the sum of their parts and much more powerful.

 

Specifically, Docker is a containerization software that can stand alone or work with other applications. It can work on any computer, anywhere and is used to run, create and manage containers on a single operating system.

 

It’s when you want to level up your applications to run multiple containers across numerous systems that Kubernetes comes in. Kubernetes (K8s) helps by managing the symphonic orchestration of containers so you don’t have to manually mess around with nailing start times, storage requirements, synchronizing communications, or dealing with component failures. In short, it reduces the operational headache of juggling a multitude of responsibilities through automation.

 

How a Container Image Can Be Compromised

 

With so much complexity happening under the hood, it’s easy to understand how security concerns can mount. As the old adage goes in engineering, “The more moving parts you have, the more chances you have for something to go wrong.” At extremely high levels with some of the most complex systems out there today, think AI, it’s not even possible to check the entire system for errors until after a problem event has happened. However, it is not a recommended best practice when the choice between proactive and reactive is available.

 

But back to the topic. Regardless of the amount of security checks that are in place, if a dev is pulling code without any trust, integrity, or authenticity scheme in place, they are essentially inviting an attack to happen.

 

Examples of Compromised Container Images

 

As they say, history has a tendency to repeat itself. It’s no different with repositories. Just within the last 2 years, there were several Python and npm compromises that were discovered in addition to several at DockerHub. Incredibly, some vulnerabilities remained live for up to and beyond a full year after their discovery.

 

In fact, some affected servers may still be compromised as hackers could have obtained persistence by creating new backdoors during the compromised period to give themselves unknown system entry in the future. Pulling and using unvetted container /images/blog is basically like swimming with chum in shark infested waters where the sharks can come back for seconds anytime.

 

How CodeNotary Can Protect You From Using Compromised Images

 

190530 - How CodeNotary Can Protect You From Using Compromised Container Images

 

To protect your reputation for developing clean code, one of the things you’ll want to do is use a tool to verify the integrity of you builds and their components. CodeNotary’s blockchain based tool not only has the ability to sign and verify code instantly, but it can do so across hosting services. So regardless, if you are pulling /images/blog from DockerHub, 3rd party libraries, or any other service, CodeNotary can verify them all with the same immutable integrity.

 

Additionally, there are even multiple ways to verify when first downloading an image including using the:

  • Drag and drop on the CodeNotary verification page here , or
  • Command line interface (which you can get from GitHub here), or
  • Google Chrome Extension that auto-verify any image or file you download (which you can get here).

 

For ongoing continuous verification, there are several integrations (including Docker, Kubernetes, Maven, and Jenkins, with more on the way) we have created for users which you can see here.

 

How to Sign a Docker Container Image – Demo Video

 

The below demonstration video shows all the steps for the specific use case of signing a local Docker container image so vcn, the CodeNotary CLI tool, can verify the image’s integrity. Steps shown include:

 

  1. Login using vcn login
  2. Check the local Docker container image
  3. Sign the container image with the CodeNotary account using vcn sign
  4. Verify the container image using vcn verify
  5. Check the vcn pod (Kubernetes DaemonSet) log if the verification works

 

Be sure to note how the video ends with all but one container verification failing, which is exactly as it should be since only one container was signed in the demo. You can see the demo on ‘How to Sign a Docker Container Image’ here.

 

Conclusion

 

In the end, there are always risks in using software and containers, but having the right mindset, the right security practices, and the right tools from the start of the dev lifecycle can mitigate your risk exposure levels significantly.

 

If you like, you can try out CodeNotary’s Verification tool for yourself by clicking below. And if you are an open source developer, there’s a bonus, because it’s free for all OSS devs to use forever.

 

 

Yes, I Want to Test Out CodeNotary

 

REFERENCES

https://blog.containership.io/k8svsdocker/

https://containerjournal.com/2019/01/14/kubernetes-vs-docker-a-primer/

https://resources.whitesourcesoftware.com/blog-whitesource/docker-image-security-scanning

https://www.bleepingcomputer.com/news/security/17-backdoored-docker-/images/blog-removed-from-docker-hub/

CNIL
Metrics and Logs

(formerly, Opvizor Performance Analyzer)

VMware vSphere & Cloud
PERFORMANCE MONITORING, LOG ANALYSIS, LICENSE COMPLIANCE!

Monitor and Analyze Performance and Log files:
Performance monitoring for your systems and applications with log analysis (tamperproof using immudb) and license compliance (RedHat, Oracle, SAP and more) in one virtual appliance!

Subscribe to Our Newsletter

Get the latest product updates, company news, and special offers delivered right to your inbox.

Subscribe to our newsletter

Use Case - Tamper-resistant Clinical Trials

Goal:

Blockchain PoCs were unsuccessful due to complexity and lack of developers.

Still the goal of data immutability as well as client verification is a crucial. Furthermore, the system needs to be easy to use and operate (allowing backup, maintenance windows aso.).

Implementation:

immudb is running in different datacenters across the globe. All clinical trial information is stored in immudb either as transactions or the pdf documents as a whole.

Having that single source of truth with versioned, timestamped, and cryptographically verifiable records, enables a whole new way of transparency and trust.

Use Case - Finance

Goal:

Store the source data, the decision and the rule base for financial support from governments timestamped, verifiable.

A very important functionality is the ability to compare the historic decision (based on the past rulebase) with the rulebase at a different date. Fully cryptographic verifiable Time Travel queries are required to be able to achieve that comparison.

Implementation:

While the source data, rulebase and the documented decision are stored in verifiable Blobs in immudb, the transaction is stored using the relational layer of immudb.

That allows the use of immudb’s time travel capabilities to retrieve verified historic data and recalculate with the most recent rulebase.

Use Case - eCommerce and NFT marketplace

Goal:

No matter if it’s an eCommerce platform or NFT marketplace, the goals are similar:

  • High amount of transactions (potentially millions a second)
  • Ability to read and write multiple records within one transaction
  • prevent overwrite or updates on transactions
  • comply with regulations (PCI, GDPR, …)


Implementation:

immudb is typically scaled out using Hyperscaler (i. e. AWS, Google Cloud, Microsoft Azure) distributed across the Globe. Auditors are also distributed to track the verification proof over time. Additionally, the shop or marketplace applications store immudb cryptographic state information. That high level of integrity and tamper-evidence while maintaining a very high transaction speed is key for companies to chose immudb.

Use Case - IoT Sensor Data

Goal:

IoT sensor data received by devices collecting environment data needs to be stored locally in a cryptographically verifiable manner until the data is transferred to a central datacenter. The data integrity needs to be verifiable at any given point in time and while in transit.

Implementation:

immudb runs embedded on the IoT device itself and is consistently audited by external probes. The data transfer to audit is minimal and works even with minimum bandwidth and unreliable connections.

Whenever the IoT devices are connected to a high bandwidth, the data transfer happens to a data center (large immudb deployment) and the source and destination date integrity is fully verified.

Use Case - DevOps Evidence

Goal:

CI/CD and application build logs need to be stored auditable and tamper-evident.
A very high Performance is required as the system should not slow down any build process.
Scalability is key as billions of artifacts are expected within the next years.
Next to a possibility of integrity validation, data needs to be retrievable by pipeline job id or digital asset checksum.

Implementation:

As part of the CI/CD audit functionality, data is stored within immudb using the Key/Value functionality. Key is either the CI/CD job id (i. e. Jenkins or GitLab) or the checksum of the resulting build or container image.

White Paper — Registration

We will also send you the research paper
via email.

CodeNotary — Webinar

White Paper — Registration

Please let us know where we can send the whitepaper on CodeNotary Trusted Software Supply Chain. 

Become a partner

Start Your Trial

Please enter contact information to receive an email with the virtual appliance download instructions.

Start Free Trial

Please enter contact information to receive an email with the free trial details.