Many enterprises often find themselves sifting through guidance, compliance regulations, and requirements as organizations set out on their DevSecOps journey. Sifting through all of the key terminology and understanding how each key item intricately interacts with other key components can be overwhelming for developers who may be in the beginning stages of their journey. To help, Anchore has created a shift left lexicon to help you gain a clear understanding of the key phrases and terminology used in DevSecOps.
Container Security Terminology Guide
Let’s start with a container. A container is a collection of processes along with constraints on what resources the container can access and isolate from other activities on the system. Multiple containers can then be run on top of the same host so that they can all share the host OS kernel with one another. The best way to understand containers is to look at container images and see how container images are consumed by a registry and deployed on Kubernetes.
Container images are templates for the creation of containers and contain all of the source code, dependencies, licenses, metadata, libraries and supporting files needed for an application to run. Images are (usually) defined by a Dockerfile, which allows for them to be reproducibly built from defined base images, source code, and build instructions.
A registry is a storage system for images. Different images are stored in individual repositories in the registry, and in the repository, different versions of the image can be denoted with tags. Some registries are public and anyone can anonymously pull images, while others are private and require authentication. Many public registries also offer the ability to mark individual repositories as private.
E.g. docker.io/alpine:latest Registry: docker.io Repository: alpine Tag: latest
Registries are useful in DevOps workflows because in general the container images will be built in one environment but will run in production in a different environment. The registry is a centralized hub: automation can direct worker nodes in the build farm to push completed images into the registry, and worker nodes in the production environment can pull the latest vetted version of an image when it’s time to execute.
Kubernetes is an industry-standard container orchestration platform. This simply means that it keeps track of containers across a cluster of worker nodes, which can be as small as a single system on a developer’s desk or scale up to hundreds or thousands of nodes, across multiple datacenters and cloud providers. There are other container orchestrators but all major vendors have standardized on Kubernetes and many practitioners use “orchestration” and “Kubernetes” interchangeably.
Continuous Integration (CI)
Continuous Integration (CI) refers to the automated building of software on a continual basis as changes are checked in by developers. This generally means that developers are making a steady stream of small changes rather than the more traditional method of committing changes in huge but infrequent batches. As the changes come in, the CI tooling will automatically integrate the changes into the codebase, coordinating the efforts of multiple developers on the team.
Continuous Delivery (CD)
Continuous Delivery (CD) is a complimentary automation technique, which takes the software artifacts produced by the CI tooling and delivers them to the next location. In some cases, this may mean submitting recently checked-in code to automated testing processes, or it could move finished and tested code from a QA environment to a production environment.
A fully automated set of tooling to integrate changes, apply testing (including security checks), and move code to production is often referred to as a CI/CD Pipeline.
These are only a few key terms that are very important in gaining a foundational understanding of core concepts embedded within DevSecOps methodology. Stay tuned for part two of our shift left lexicon where we’ll dive deeper into container security terminology.