At the heart of Anchore’s solution is the concept of users certifying container images based on rules that they define. In the past certifications for applications typically came from operating systems vendors who defined their own standards and worked with independent software vendors (ISVs) on certification programs to give a level of assurance to end users that the application was compatible with the underlying operating system. Other organizations have created standards and certification tests to cover various forms of compliance validation, especially in the government sector or regulated industries.
Today the problem is more complex and there can no longer be just a single certification. For example, the requirements of a financial services company are different from the requirements of a healthcare company handling medical records and these are different from the needs of a federal institution and so on.
Anchore believes that rather than having certification in the hands of a small number of vendors or standards bodies, we want to allow organizations to define what certification means to them. In effect, we want to democratize certification.
Today we are seeing the baseline feature set for container security is a CVE scan and that's certainly required but it's just the first step.I'm sure the policies and you have in place today for your traditional deployments are more than just ensuring that you've updated all operating system packages.
These policies could cover security, starting with the ubiquitous CVE scan but then going further to analyze the configuration of key security components, for example, you could have the latest version of the apache webserver but have configured the wrong set of TLS Ciphers suites leading to insecure communication. Outside of security, policies could cover application-specific configurations to comply with best practices or to enable consistency and predictability.
In this blog, we will walk through some sample policies and cover how users can customize these policies as well as create and share their own policies.
Let’s start by looking at the policy evaluation of a test image. We will be using the anchore gate command. In Anchore’s terminology gates are checks that are run on images as they pass through the CI/CD pipeline or later when performing an evaluation on existing images.
Instead of using the default policy, we will use a customized policy called “basic-policy” that will be loaded by the CLI.
# anchore gate --image=testimage --policy=basic-policy+--------------+------------------+-----------------+---------------+-------------------------+-------------+
| Image Id | Repo Tag | Gate | Trigger | Check Output | Gate Action |
+--------------+------------------+-----------------+---------------+-------------------------+-------------+
| 9ebc746ba558 | testimage:latest | DOCKERFILECHECK | NOHEALTHCHECK | Dockerfile does not | WARN |
| | | | | contain any HEALTHCHECK | |
| | | | | instructions | |
| 9ebc746ba558 | testimage:latest | PKGBLACKLIST | PKGNAMEMATCH | Package is blacklisted: | STOP |
| | | | | openssh-server | |
| 9ebc746ba558 | testimage:latest | ANCHORESEC | VULNMEDIUM | Medium Vulnerability | WARN |
| | | | | found in package - | |
| | | | | bind-license | |
| | | | | (RHSA-2017:0276 - https | |
| | | | | ://rhn.redhat.com/errat | |
| | | | | a/RHSA-2017-0276.html) | |
| 9ebc746ba558 | testimage:latest | ANCHORESEC | VULNMEDIUM | Medium Vulnerability | WARN |
| | | | | found in package - | |
| | | | | openssl-libs | |
| | | | | (RHSA-2017:0286 - https | |
| | | | | ://rhn.redhat.com/errat | |
| | | | | a/RHSA-2017-0286.html) | |
| 9ebc746ba558 | testimage:latest | ANCHORESEC | VULNMEDIUM | Medium Vulnerability | WARN |
| | | | | found in package - vim- | |
| | | | | minimal (RHSA-2016:2972 | |
| | | | | - https://rhn.redhat.co | |
| | | | | m/errata/RHSA-2016-2972 | |
| | | | | .html) | |
| 9ebc746ba558 | testimage:latest | ANCHORESEC | VULNHIGH | High Vulnerability | STOP |
| | | | | found in package - | |
| | | | | bind-license | |
| | | | | (RHSA-2017:0062 - https | |
| | | | | ://rhn.redhat.com/errat | |
| | | | | a/RHSA-2017-0062.html) | |
| 9ebc746ba558 | testimage:latest | IMAGECHECK | BASEOUTOFDATE | Image base image | WARN |
| | | | | (docker.io/acathrow | |
| | | | | /aic-test:1a) ID is | |
| | | | | (9ebc746ba558), but the | |
| | | | | latest ID for | |
| | | | | (docker.io/acathrow | |
| | | | | /aic-test:1a) is | |
| | | | | (f3e982542816) | |
| 9ebc746ba558 | testimage:latest | FINAL | FINAL | | STOP |
+--------------+------------------+-----------------+---------------+-------------------------+-------------+Here the output is formatted in a tabular view for a command line user to read however if you want to automate the processing of the output then the anchore command supports a --json or --plain command line option to output the results in a format that is easily parsed by other tools.
The most important part of the output is the last line that indicates that the final policy evaluation is “STOP”. Anchore gates will output one of three actions:
GO: The gate is open and the image should be allowed to pass through to the next stage.
STOP: The gate is closed and the image should not proceed
WARN: The gate is open and should proceed to the next step however warnings have been raised that should be reviewed.
If you are automating the use of Anchore from the command line then the return code from the anchore command can be used to evaluate the status: 0 = Go, 1 = Stop, 2 = Warn.
Looking at the output of the policy evaluation we can see that two policy checks outputted a “STOP” action. The first was due to a blacklisted package being present in the image and the second was due to a high-level CVE vulnerability.
Next, we’ll take a look at the policy.
DOCKERFILECHECK:NOTAG:STOP DOCKERFILECHECK:NOFROM:STOP DOCKERFILECHECK:NOHEALTHCHECK:WARN DOCKERFILECHECK:EXPOSE:STOP:DENIEDPORTS=22 SUIDDIFF:SUIDFILEDEL:GO SUIDDIFF:SUIDMODEDIFF:STOP SUIDDIFF:SUIDFILEADD:STOP IMAGECHECK:BASEOUTOFDATE:WARN PKGBLACKLIST:PKGNAMEMATCH:STOP:BLACKLIST_NAMEMATCH=openssh-server ANCHORESEC:FEEDOUTOFDATE:STOP:MAXAGE=2 ANCHORESEC:UNSUPPORTEDDISTRO:STOP ANCHORESEC:VULNCRITICAL:STOP ANCHORESEC:VULNHIGH:STOP ANCHORESEC:VULNMEDIUM:WARN
The policy file lines are of the following format:
Gate name : Trigger : Action : Optional ParametersYou can consider a Gate as a family of checks that can be performed.
Checks can raise triggers that may have parameters.
Once a trigger is raised then an action (GO, STOP or WARN) is defined.
For example, looking at the following snippet from this simple policy:
DOCKERFILECHECK:NOHEALTHCHECK:WARNWithin the Dockerfilecheck gate there is a that looks for a healthcheck statement in the Dockerfile. If no healthcheck statement is found then the NOHEALTHCHECK trigger is raised.
In this example, we have configured Anchore to raise a warning if the Dockerfile does not include a health check.
In the next example we’ll blacklist two packages:
PKGBLACKLIST:PKGNAMEMATCH:STOP:BLACKLIST_NAMEMATCH=openssh-server,foolibHere we have configured the PKGNAMEMATCH trigger to issue a STOP action if either openssh-server or foolib is present in the image.
The PKGBLACKLIST gate has two triggers : PKGFULLMATCH which matches both a package name and version and PKGNAMEMATCH which matches just the name of the package.
Anchore comes pre-installed with a number of policy modules that can be extended by the user and we regularly add new modules.
You can retrieve a full list of available policy options by running the following command:
# anchore gate --show-policytemplateThis will output a sample policy including all available gates including all available parameters.
The policy template option is useful for providing a policy file that you can further customize.
To get more detailed descriptions of gates, triggers and configuration options you can run the
following command:
# anchore gate --show-gatehelpPKGCHECK:
PKGNOTPRESENT:
description: 'triggers if the package(s) specified in the params are not installed
in the container image. PKGFULLMATCH param can specify an exact match (ex:
"curl|7.29.0-35.el7.centos"). PKGNAMEMATCH param can specify just the package
name (ex: "curl"). PKGVERSMATCH can specify a minimum version and will trigger
if installed version is less than the specified minimum version (ex: zlib|0.2.8-r2)'
params: PKGFULLMATCH,PKGNAMEMATCH,PKGVERSMATCHIn this snippet, you can see the configuration options for the Package Check gate which allows a policy to specify that certain packages should be installed in the image. In addition to checking for the presence of a package, the user can configure minimum required versions.
We have set up a git repository to make it easier to share sample policies and allow the community to collaborate. You can access the repository here.
In our next blog, we’ll cover whitelists and show how you can reduce some of the noise that is often seen in CVE scans by whitelisting vulnerabilities that are not exploitable in your image.
