In June of 2018, Amazon announced the general availability of their Elastic Container Service for Kubernetes. Given that at Anchore we deliver our products as Docker container images, it came as no surprise to us that our users and customers would begin deploying our software on EKS. Since Kubernetes, Kubernetes on AWS, and Anchore on EKS adoption have all increased, I thought it best to give EKS a shot.
In this article, we’ll dive more deeply into matching metrics gathered in our first part with opportunities to tune the performance of a given Anchore deployment.
Anchore policy bundles are the unit of policy definition and evaluation. Anchore users may have multiple policy bundles, but for a policy evaluation, the user must specify a bundle to be evaluated or default to the bundle currently marked as active. One of the components of a policy bundle is whitelists. A whitelist is a set of exclusion rules for trigger matches found during policy evaluation.
In the first set of posts in this series, I will walk through how to evaluate and tune your Anchore deployment for better image analysis performance. To do so, we’ll discuss the actions Anchore Engine takes to pull, analyze and evaluate images and how that is affected by configuration and deployment architecture. We’ll also point out how you can get metrics on each of these functions to determine what you can do to improve the performance of your deployment.
The progression of my passion about technology from the early days of my career in unix/linux operations, through development and engineering work, to joining Eucalyptus and Ansible always followed an arc of interest and curiosity. I was always looking to expand my understanding of infrastructure and platform development but also looking for environments that encouraged growth and learning. I was fortunate to have that in the past and I feel extremely fortunate to be able to continue this at Anchore.
Adding Vulnerability Scanning and Policy-Compliance for Your Containers in CI/CD, No Stateful Service Required
Today we are introducing a new way to interact with anchore to get image scans, evaluations, and content reports without requiring a central anchore-engine deployment to be available. We call this new approach ‘inline scan’, to indicate that a single, one-time scan can be performed ‘inline’ against a local container image at any time, without the need for any persistent data or service state between scans.
In this post, I will run through an installation of Anchore on OpenShift. I’ll also discuss in brief how to use Anchore to scan images.