An important, core principle around which the anchore container image inspection, analysis, scanning and enforcement technologies have been built stems from the reality that, when dealing with container deployments in production, there is a great deal of variance in the software, configuration, and other static artifacts that exist across an organization’s container image set. Even within a single application that is delivered in the form of container images evolving over a (often short) period of time, frequent updates and modifications happen, resulting in the catalog of image software/configuration being in a state of flux. Given this characteristic of typical container environments, anchore tools and services have been designed to help users gain insight into container image composition, and importantly be able to specify rules to enforce security, compliance and best-practice requirements, while allowing the workload to be highly dynamic. The core concept we use in anchore to achieve these goals is that of the anchore policy evaluation, which is fed a user-defined document or set of documents that we refer to as anchore policy bundles.
Using the policy mechanisms of anchore, users can define a collection of checks, whitelists, and mappings (encapsulated as a self-contained anchore policy bundle document). Anchore policy bundles can then be authored to encode a variety of rules, including checks within (but not limited to) the following categories:
- Security vulnerabilities
- Package whitelists and blacklists
- Presence of credentials in an image
- Dockerfile line checks
- Exposed ports
- Effective user
- Software licenses
- Image digest whitelist/blacklist
User-defined anchore policies are used to perform evaluations against container images as they move through their lifecycle from CI/CD to production. Using the policy evaluation framework, users / integrated systems can receive reports (evaluation results, security vulnerability scans, image content reports, and more) and control recommendations (policy evaluation pass/fail) at every step during a container image’s lifecycle.
Today, we’re pleased to announce the availability of a new service called the Anchore Policy Hub, which offers a store of pre-defined anchore policy bundles, and additionally (importantly!) is intended to serve as a mechanism for container DevOps and SecOps user communities to discuss container security, compliance and best-practices topics, while demonstrating functional working expressions of these topics in the form of fully usable anchore policy bundles, all in a public forum.
What is Being Released
Specifically, the Anchore Policy Hub is a centralized repository of resources that are publicly available and can be loaded into/consumed by any anchore engine installation, via anchore engine clients. This system serves as a canonical store of source documents (initially, anchore policy bundles), both serving as a location where pre-defined policy bundles can be easily fetched and loaded into anchore engine deployments, to serve as a starting point for creating your own policy bundles, as well as a providing a location where users of anchore can submit and share new policy bundles. Moving forward, our intention is to use this system as a mechanism for storing/sharing other anchore resources as well.
For this initial release, we have made available the following new resources:
- The Anchore Policy Hub source document repository itself, hosted on github, which is initially populated with a set of policy bundles that can be used as a starting point for your own policy definitions.
- Three pre-defined policy bundles that implement security and best practices checks from a few different perspectives, including a ‘security only’ bundle, a ‘Docker CIS 1.13.0’ bundle, and a ‘mixture of security and best practices’ bundle.
- A simple, publicly accessible HTTP service, where clients can fetch and install policy bundles generated automatically from the source materials above.
- New operations in the anchore CLI, version 0.3.2, for listing, inspecting and installing policy bundles served from the hub.
Start Using the Hub
For those existing anchore users who are anxious to get started right away, we have made available three policy bundles hosted in the hub that can be installed today. The requirements are:
- Have a deployed anchore engine service up and running (for new users, see the anchore engine installation guides to get started).
- Installed anchore-cli version 0.3.2 or greater (or simply use the engine-cli:v0.3.2 container), configured to access your anchore engine deployment.
The example below shows the process for listing, reviewing, installing and optionally modifying bundles from the anchore policy hub using the CLI:
# anchore-cli --version anchore-cli, version 0.3.2 # anchore-cli policy hub list Name Description anchore_security_only Single policy, single whitelist bundle for performing security checks, including example blacklist known malicious packages by name. anchore_default_bundle Default policy bundle that comes installed with vanilla anchore-engine deployments. Mixture of light vulnerability checks, dockerfiles checks, and warning triggers for common best practices. anchore_cis_1.13.0_base Docker CIS 1.13.0 image content checks, from section 4 and 5. NOTE: some parameters (generally are named 'example...') must be modified as they require site-specific settings # anchore-cli policy hub get anchore_cis_1.13.0_base Policy Bundle ID: anchore_cis_1.13.0_base Name: anchore_cis_1.13.0_base Description: Docker CIS 1.13.0 image content checks, from section 4 and 5. NOTE: some parameters (generally are named 'example...') must be modified as they require site-specific settings Policy Name: CIS File Checks Policy Description: Docker CIS section 4.8 and 4.10 checks. Policy Name: CIS Dockerfile Checks Policy Description: Docker CIS section 4.1, 4.2, 4.6, 4.7, 4.9 and 5.8 checks. Policy Name: CIS Software Checks Policy Description: Docker CIS section 4.3 and 4.4 checks. Whitelist Name: RHEL SUID Files Whitelist Description: Example whitelist with triggerIds of files that are expected to have SUID/SGID, for rhel-based images Whitelist Name: DEB SUID Files Whitelist Description: Example whitelist with triggerIds of files that are expected to have SUID/SGID, for debian-based images Mapping Name: default Mapping Rule: */*:* Mapping Policies: CIS Software Checks,CIS Dockerfile Checks,CIS File Checks Mapping Whitelists: DEB SUID Files,RHEL SUID Files # anchore-cli policy hub install anchore_cis_1.13.0_base Policy ID: anchore_cis_1.13.0_base Active: False Source: local Created: 2019-01-31T18:42:50Z Updated: 2019-01-31T18:42:50Z # anchore-cli policy list Policy ID Active Created Updated anchore_cis_1.13.0_base False 2019-01-31T18:42:50Z 2019-01-31T18:42:50Z
Once the policy bundle has been installed from the hub, you can perform image add and evaluate actions using the usual mechanisms of anchore, as with any other pre-existing policy bundle and image set:
# anchore-cli image add docker.io/alpine:3.8 Image Digest: sha256:616d0d0ff1583933ed10a7b3b4492899942016c0577d43a1c506c0aad8ab4da8 Parent Digest: sha256:dad671370a148e9d9573e3e10a9f8cc26ce937bea78f3da80b570c2442364406 Analysis Status: not_analyzed Image Type: docker Image ID: 491e0ff7a8d51cd66a07e8b98976694174e82c0abbc77a96533c580a11378464 Dockerfile Mode: None Distro: None Distro Version: None Size: None Architecture: None Layer Count: None Full Tag: docker.io/alpine:3.8 # anchore-cli image wait docker.io/alpine:3.8 Status: analyzing Waiting 5.0 seconds for next retry. Image Digest: sha256:616d0d0ff1583933ed10a7b3b4492899942016c0577d43a1c506c0aad8ab4da8 Parent Digest: sha256:dad671370a148e9d9573e3e10a9f8cc26ce937bea78f3da80b570c2442364406 Analysis Status: analyzed Image Type: docker Image ID: 491e0ff7a8d51cd66a07e8b98976694174e82c0abbc77a96533c580a11378464 Dockerfile Mode: Guessed Distro: alpine Distro Version: 3.8.2 Size: 2207038 Architecture: amd64 Layer Count: 1 Full Tag: docker.io/alpine:3.8 # anchore-cli evaluate check docker.io/alpine:3.8 --policy anchore_cis_1.13.0_base --detail Image Digest: sha256:616d0d0ff1583933ed10a7b3b4492899942016c0577d43a1c506c0aad8ab4da8 Full Tag: docker.io/alpine:3.8 Image ID: 491e0ff7a8d51cd66a07e8b98976694174e82c0abbc77a96533c580a11378464 Status: fail Last Eval: 2019-01-31T18:44:30Z Policy ID: anchore_cis_1.13.0_base Final Action: stop Final Action Reason: policy_evaluation Gate Trigger Detail Status dockerfile instruction Dockerfile directive 'ADD' check 'exists' matched against '' for line 'file:91fb97ea3549e52e7b6e22b93a6736cf915c756f3d13348406d8ad5f1a872680 in /' warn dockerfile instruction Dockerfile directive 'HEALTHCHECK' not found, matching condition 'not_exists' check stop dockerfile instruction Dockerfile directive 'FROM' check 'not_in' matched against 'example_trusted_base1,example_trusted_base2' for line 'scratch' stop dockerfile effective_user User root found as effective user, which is explicity not allowed list stop
Finally, since some standards require site-specific information be supplied, we have included example values in the policy hub bundles that should be modified for your specific environment/application being scanned. To modify a policy bundle, you can edit the JSON directly, make a copy of the installed bundle and add a new bundle with your included modifications, or Enterprise users can use the Anchore Enterprise UI policy editing feature to make the necessary modifications and manage the installed bundles in anchore-engine.
For more examples and information, please visit the Anchore Policy Hub repository on GitHub, which will have all of the latest information on usage, contributing, and deployment options.
We’re truly excited to be sharing this service with the anchore and container user communities today, and invite all to visit the Anchore Policy Hub repository on GitHub for more information on how to start using the policy bundles already available, how to contribute your own policy bundles, modify the ones that are there already, discuss the topic generally, and even how to host an on-premises instance of an anchore hub in your own environment using the provided tools. We look forward to working with you via the hub to help advance the cause of bringing high-quality container image inspection, security, compliance and best-practice enforcement tooling to any and all who are deploying containers today!