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:

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.

Summary

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!