This series started with the statement, what do you mean by "Can't ignore the stack anymore?"
When your background is application development, you have spent many hours, days and years perfecting your craft. You have not only mastered languages and concepts, you have made it a point to learn to make good architectural decisions when pulling together the applications you develop.
The problem is, we tend to ignore the stack we are working on as much as we can. Well it's time that we as application developers broadened our horizons a bit, expanding our understanding of the stack we work on with the introduction of cloud, Platform as a Service (PaaS) and containers to our toolboxes.
Our tour of your cloud stack continues, from our previous article in this series where we talked about how crucial stack interoperability is to our xloud stack, it's now on to the final piece concerning securing containers at scale.
Previously we talked about why containers at scale matter, but we did not touch on one of the bigger issues when maintaining containers at scale, that of keeping your container landscape secure.
While containers are the new way of delivering applications to the operational side of your organization, they are only as secure as the content running inside of them. Look at it like allowing a developer to put together a container filled with vulnerabilities as being akin to an operator setting up a machine with an OS and other software that is full of vulnerabilities.
Both are very bad news. Even more so when containers can be deployed throughout your landscape in massively scalable deployments.
If you thought using a vendor source like Docker Hub, think again. A report from Banyan shows us, over 30% of the officially hosted images contain High Priority Security Vulnerabilities. That should scare the bejesus out of all of us who are responsible for building, deploying and maintaining containers at scale.
What can be done about this you ask?
Several things actually, like ensuring the containers you build use safe components, that you know the origin and that you trust those components or containers to be what you need. Let's look at a few things that can help you trust the content you are using.
1. The OS Matters
Building your containers means one thing, the operating system matters. Linux is containers so start with a certified, trusted and secure OS such as Red Hat Enterprise Linux (RHEL). This is the base layer that many data centers are running on bare metal, so why not skip the heartache and ensure your containers run on RHEL too?
2. Sign Your Containers
Ensure your container work, once you trust the contents, is signed. This can be done by integrating that process into your container builds using the Container Image Signing Integration Guide. This article shows you the architecture, explains the best practice and walks through a reference implementation. Red Hat container image signing provides a path to ensure authorship, integrity and non-repudiation.
3. Container Catalog
The number one way to ensure your containers are built using layers of trusted work is to pull your image layers from the Red Hat Container Catalog. This online searchable catalog contains Enterprise-ready containers and should be your trusted source for secure, certified, and up-to-date container images.
With these three pointers you are now well on your way to producing containers, deploying containers at scale and securing your containers at scale.
Be sure to catch up on the rest of the series.
App Dev Cloud Stack series
Missed a previous article or looking for a specific article in the series?
- Can’t ignore the stack anymore
- Foundations for a stable Cloud
- Beginners guide to containers at scale
- Why containers at scale matter
- It’s all about the PaaS baby
- Open interoperability critical to success
- Securing containers at scale
This concludes the App Dev Cloud Stack series, please feel free to leave comments and feedback below.