Policies via CTL
Introduction
Policies are central to the concept of Anchore Enterprise, this article provides information on how to create, delete, update, and describe policies using AnchoreCTL to interact with a running Anchore Enterprise deployment.
At a high-level Anchore Enterprise consumes policies store in a Policy that contain:
- Policies
- Allowlists
- Mappings
- Allowlisted Images
- Denylisted Images
Anchore Enterprise can store multiple policies for each account, but only one policy can be active at any point in time. All users within an account share the same set of policies. It is common to store historic policies to allow previous policies and evaluations to be inspected. The active policy is the one used for evaluation for notifications, incoming kubernetes webhooks (unless configured otherwise), and other automatic system functions, but a user may request evaluation of any policy stored in the system using its id.
For more information on the content and semantics of policies see: Policies and Evaluation
Creating Policies
Policies are just JSON documents. Anchore Enterprise includes a default policy configured at installation that performs basic CVE checks as well as some Dockerfile checks.
To create custom polices, you may:
- Edit JSON manually and upload a file
- Use the Anchore Enterprise UI to edit policies
Managing Policies
Policies can be managed directly using the REST API or the anchorectl policy command.
Adding Policies using AnchoreCTL
The anchorectl tool allows you to upload policies to Anchore Enterprise.
# anchorectl policy add --input /path/to/policy/policy.json
Note: Adding a policy will not automatically set the policy to be active, you will need to activate the policy using the activate command.
Listing Policies
Anchore Enterprise may store multiple policies however at a given time only one policy may be active. Policies can be listed using the policy list command.
# anchorectl policy list
✔ Fetched policies
┌────────────────┬──────────────────────────────────────┬────────┬──────────────────────┐
│ NAME │ POLICY ID │ ACTIVE │ UPDATED │
├────────────────┼──────────────────────────────────────┼────────┼──────────────────────┤
│ Default policy │ 2c53a13c-1765-11e8-82ef-23527761d060 │ true │ 2023-10-25T20:39:28Z │
│ devteam1policy │ da8208a2-c8ae-4cf2-a25b-a52b0cdcd789 │ false │ 2023-10-25T20:47:16Z │
└────────────────┴──────────────────────────────────────┴────────┴──────────────────────┘
Each policy has a unique ID that will be reference in policy evaluation reports.
Note: Times are reported in UTC.
Viewing Policies
Using the policy get command, summary or detailed information about a policy can be retrieved. The policy is referenced using its unique id.
# anchorectl policy get 2c53a13c-1765-11e8-82ef-23527761d060
✔ Fetched policy
Name: Default policy
ID: 2c53a13c-1765-11e8-82ef-23527761d060
Comment: Default policy
Policies:
- artifactType: image
comment: System default policy
id: 48e6f7d6-1765-11e8-b5f9-8b6f228548b6
name: DefaultPolicy
rules:
- action: STOP
gate: dockerfile
id: ce7b8000-829b-4c27-8122-69cd59018400
params:
- name: ports
value: "22"
- name: type
value: denylist
trigger: exposed_ports
...
...
The policy can be downloaded in JSON format by passing the --detail parameter.
# anchorectl policy get 2c53a13c-1765-11e8-82ef-23527761d060 --detail -o json-raw > policy.json
✔ Fetched policy
Activating Policies
The policy activate command can be used to activate a policy. The policy is referenced using its unique id which can be retrieved using the policy list command.
# anchorectl policy activate 2c53a13c-1765-11e8-82ef-23527761d061
✔ Activate policy
┌─────────────────┬──────────────────────────────────────┬────────┬──────────────────────┐
│ NAME │ POLICY ID │ ACTIVE │ UPDATED │
├─────────────────┼──────────────────────────────────────┼────────┼──────────────────────┤
│ Default policy │ 2c53a13c-1765-11e8-82ef-23527761d061 │ true │ 2023-10-25T20:50:17Z │
└─────────────────┴──────────────────────────────────────┴────────┴──────────────────────┘
Deleting Policies
Policies can be deleted from Anchore Enterprise using the policy del command The policy is referenced using its unique id. A policy marked as active cannot be deleted, another policy has to be marked active before deleting the currently active policy.
# anchorectl policy delete 2c53a13c-1765-11e8-82ef-23527761d061
✔ Deleted policy
No results
See Anchore Policy Checks for information about available policy gates and triggers in Anchore Enterprise.
1 - Anchore Policy Checks
Introduction
In this document, we describe the current anchore gates (and related triggers and parameters) that are supported within anchore policy.
Gate: dockerfile
Checks against the content of a dockerfile if provided, or a guessed dockerfile based on docker layer history if the dockerfile is not provided.
Note For further information on usage see Policy Gate: Dockerfile
| Trigger Name | Description | Parameter | Description | Example |
|---|
| instruction | Triggers if any directives in the list are found to match the described condition in the dockerfile. | instruction | The Dockerfile instruction to check. | from |
| instruction | Triggers if any directives in the list are found to match the described condition in the dockerfile. | check | The type of check to perform. | = |
| instruction | Triggers if any directives in the list are found to match the described condition in the dockerfile. | value | The value to check the dockerfile instruction against. | scratch |
| instruction | Triggers if any directives in the list are found to match the described condition in the dockerfile. | actual_dockerfile_only | Only evaluate against a user-provided dockerfile, skip evaluation on inferred/guessed dockerfiles. Default is False. | true |
| effective_user | Checks if the effective user matches the provided user names, either as a allowlist or blocklist depending on the type parameter setting. | users | User names to check against as the effective user (last user entry) in the images history. | root,docker |
| effective_user | Checks if the effective user matches the provided user names, either as a allowlist or blocklist depending on the type parameter setting. | type | How to treat the provided user names. | denylist |
| exposed_ports | Evaluates the set of ports exposed. Allows configuring allowlist or blocklist behavior. If type=allowlist, then any ports found exposed that are not in the list will cause the trigger to fire. If type=denylist, then any ports exposed that are in the list will cause the trigger to fire. | ports | List of port numbers. | 80,8080,8088 |
| exposed_ports | Evaluates the set of ports exposed. Allows configuring allowlist or blocklist behavior. If type=allowlist, then any ports found exposed that are not in the list will cause the trigger to fire. If type=denylist, then any ports exposed that are in the list will cause the trigger to fire. | type | Whether to use port list as a allowlist or denylist. | denylist |
| exposed_ports | Evaluates the set of ports exposed. Allows configuring allowlist or blocklist behavior. If type=allowlist, then any ports found exposed that are not in the list will cause the trigger to fire. If type=denylist, then any ports exposed that are in the list will cause the trigger to fire. | actual_dockerfile_only | Only evaluate against a user-provided dockerfile, skip evaluation on inferred/guessed dockerfiles. Default is False. | true |
| no_dockerfile_provided | Triggers if anchore analysis was performed without supplying the actual image Dockerfile. | | | |
Gate: files
Checks against files in the analyzed image including file content, file names, and filesystem attributes.
| Trigger Name | Description | Parameter | Description | Example |
|---|
| content_regex_match | Triggers for each file where the content search analyzer has found a match using configured regexes in the analyzer_config.yaml “content_search” section. If the parameter is set, the trigger will only fire for files that matched the named regex. Refer to your analyzer_config.yaml for the regex values. | regex_name | Regex string that also appears in the FILECHECK_CONTENTMATCH analyzer parameter in analyzer configuration, to limit the check to. If set, will only fire trigger when the specific named regex was found in a file. | .password. |
| name_match | Triggers if a file exists in the container that has a filename that matches the provided regex. This does have a performance impact on policy evaluation. | regex | Regex to apply to file names for match. | .*.pem |
| attribute_match | Triggers if a filename exists in the container that has attributes that match those which are provided . This check has a performance impact on policy evaluation. | filename | Filename to check against provided checksum. | /etc/passwd |
| attribute_match | Triggers if a filename exists in the container that has attributes that match those which are provided . This check has a performance impact on policy evaluation. | checksum_algorithm | Checksum algorithm | sha256 |
| attribute_match | Triggers if a filename exists in the container that has attributes that match those which are provided . This check has a performance impact on policy evaluation. | checksum | Checksum of file. | 832cd0f75b227d13aac82b1f70b7f90191a4186c151f9db50851d209c45ede11 |
| attribute_match | Triggers if a filename exists in the container that has attributes that match those which are provided . This check has a performance impact on policy evaluation. | checksum_match | Checksum operation to perform. | equals |
| attribute_match | Triggers if a filename exists in the container that has attributes that match those which are provided . This check has a performance impact on policy evaluation. | mode | File mode of file. | 00644 |
| attribute_match | Triggers if a filename exists in the container that has attributes that match those which are provided . This check has a performance impact on policy evaluation. | mode_op | File mode operation to perform. | equals |
| attribute_match | Triggers if a filename exists in the container that has attributes that match those which are provided . This check has a performance impact on policy evaluation. | skip_missing | If set to true, do not fire this trigger if the file is not present. If set to false, fire this trigger ignoring the other parameter settings. | true |
| suid_or_guid_set | Fires for each file found to have suid or sgid bit set. | | | |
Gate: passwd_file
Content checks for /etc/passwd for things like usernames, group ids, shells, or full entries.
| Trigger Name | Description | Parameter | Description | Example |
|---|
| content_not_available | Triggers if the /etc/passwd file is not present/stored in the evaluated image. | | | |
| denylist_usernames | Triggers if specified username is found in the /etc/passwd file | user_names | List of usernames that will cause the trigger to fire if found in /etc/passwd. | daemon,ftp |
| denylist_userids | Triggers if specified user id is found in the /etc/passwd file | user_ids | List of userids (numeric) that will cause the trigger to fire if found in /etc/passwd. | 0,1 |
| denylist_groupids | Triggers if specified group id is found in the /etc/passwd file | group_ids | List of groupids (numeric) that will cause the trigger ot fire if found in /etc/passwd. | 999,20 |
| denylist_shells | Triggers if specified login shell for any user is found in the /etc/passwd file | shells | List of shell commands to denylist. | /bin/bash,/bin/zsh |
| denylist_full_entry | Triggers if entire specified passwd entry is found in the /etc/passwd file. | entry | Full entry to match in /etc/passwd. | ftp:x:14:50:FTP User:/var/ftp:/sbin/nologin |
Gate: packages
Distro package checks
| Trigger Name | Description | Parameter | Description | Example |
|---|
| required_package | Triggers if the specified package and optionally a specific version is not found in the image. | name | Name of package that must be found installed in image. | libssl |
| required_package | Triggers if the specified package and optionally a specific version is not found in the image. | version | Optional version of package for exact version match. | 1.10.3rc3 |
| required_package | Triggers if the specified package and optionally a specific version is not found in the image. | version_match_type | The type of comparison to use for version if a version is provided. | exact |
| verify | Check package integrity against package db in the image. Triggers for changes or removal or content in all or the selected “dirs” parameter if provided, and can filter type of check with the “check_only” parameter. | only_packages | List of package names to limit verification. | libssl,openssl |
| verify | Check package integrity against package db in the image. Triggers for changes or removal or content in all or the selected “dirs” parameter if provided, and can filter type of check with the “check_only” parameter. | only_directories | List of directories to limit checks so as to avoid checks on all dir. | /usr,/var/lib |
| verify | Check package integrity against package db in the image. Triggers for changes or removal or content in all or the selected “dirs” parameter if provided, and can filter type of check with the “check_only” parameter. | check | Check to perform instead of all. | changed |
| denylist | Triggers if the evaluated image has a package installed that matches the named package optionally with a specific version as well. | name | Package name to denylist. | openssh-server |
| denylist | Triggers if the evaluated image has a package installed that matches the named package optionally with a specific version as well. | version | Specific version of package to denylist. | 1.0.1 |
| metadata | Triggers on a package type comparison. | type | The type of package. | rpm |
| metadata | Triggers on a package name comparison. | name | The name of the package. Wildcards are supported. | *ssl |
| metadata | Triggers on a package version comparison. | version | The version of the package. Wildcards are supported. | *fips |
Gate: vulnerabilities
CVE/Vulnerability checks.
| Trigger Name | Description | Parameter | Description | Example |
|---|
| package | Triggers if a found vulnerability in an image meets the comparison criteria. | package_type | Only trigger for specific package type. | all |
| package | Triggers if a found vulnerability in an image meets the comparison criteria. | severity_comparison | The type of comparison to perform for severity evaluation. | > |
| package | Triggers if a found vulnerability in an image meets the comparison criteria. | severity | Severity to compare against. | high |
| package | Triggers if a found vulnerability in an image meets the comparison criteria. | cvss_v3_base_score_comparison | The type of comparison to perform for CVSS v3 base score evaluation. | > |
| package | Triggers if a found vulnerability in an image meets the comparison criteria. | cvss_v3_base_score | CVSS v3 base score to compare against. | None |
| package | Triggers if a found vulnerability in an image meets the comparison criteria. | cvss_v3_exploitability_score_comparison | The type of comparison to perform for CVSS v3 exploitability sub score evaluation. | > |
| package | Triggers if a found vulnerability in an image meets the comparison criteria. | cvss_v3_exploitability_score | CVSS v3 exploitability sub score to compare against. | None |
| package | Triggers if a found vulnerability in an image meets the comparison criteria. | cvss_v3_impact_score_comparison | The type of comparison to perform for CVSS v3 impact sub score evaluation. | > |
| package | Triggers if a found vulnerability in an image meets the comparison criteria. | cvss_v3_impact_score | CVSS v3 impact sub score to compare against. | None |
| package | Triggers if a found vulnerability in an image meets the comparison criteria. | fix_available | If present, the fix availability for the vulnerability record must match the value of this parameter. | true |
| package | Triggers if a found vulnerability in an image meets the comparison criteria. | vendor_only | If True, an available fix for this CVE must not be explicitly marked as wont be addressed by the vendor | true |
| package | Triggers if a found vulnerability in an image meets the comparison criteria. | max_days_since_creation | If provided, this CVE must be older than the days provided to trigger. | 7 |
| package | Triggers if a found vulnerability in an image meets the comparison criteria. | max_days_since_fix | If provided (only evaluated when fix_available option is also set to true), the fix first observed time must be older than days provided, to trigger. | 30 |
| package | Triggers if a found vulnerability in an image meets the comparison criteria. | vendor_cvss_v3_base_score_comparison | The type of comparison to perform for vendor specified CVSS v3 base score evaluation. | > |
| package | Triggers if a found vulnerability in an image meets the comparison criteria. | vendor_cvss_v3_base_score | Vendor CVSS v3 base score to compare against. | None |
| package | Triggers if a found vulnerability in an image meets the comparison criteria. | vendor_cvss_v3_exploitability_score_comparison | The type of comparison to perform for vendor specified CVSS v3 exploitability sub score evaluation. | > |
| package | Triggers if a found vulnerability in an image meets the comparison criteria. | vendor_cvss_v3_exploitability_score | Vendor CVSS v3 exploitability sub score to compare against. | None |
| package | Triggers if a found vulnerability in an image meets the comparison criteria. | vendor_cvss_v3_impact_score_comparison | The type of comparison to perform for vendor specified CVSS v3 impact sub score evaluation. | > |
| package | Triggers if a found vulnerability in an image meets the comparison criteria. | vendor_cvss_v3_impact_score | Vendor CVSS v3 impact sub score to compare against. | None |
| package | Triggers if a found vulnerability in an image meets the comparison criteria. | package_path_exclude | The regex to evaluate against the package path to exclude vulnerabilities | .test.jar |
| package | Triggers if a found vulnerability in an image meets the comparison criteria. | inherited_from_base | If true, only show vulns inherited from the base, if false than only show vulns not inherited from the base. Don’t specify to include vulns from the base image and the current image. | True |
| denylist | Triggers if any of a list of specified vulnerabilities has been detected in the image. | vulnerability_ids | List of vulnerability IDs, will cause the trigger to fire if any are detected. | CVE-2019-1234 |
| denylist | Triggers if any of a list of specified vulnerabilities has been detected in the image. | vendor_only | If set to True, discard matches against this vulnerability if vendor has marked as will not fix in the vulnerability record. | True |
| stale_feed_data | Triggers if the CVE data is older than the window specified by the parameter MAXAGE (unit is number of days). | max_days_since_sync | Fire the trigger if the last sync was more than this number of days ago. | 10 |
| vulnerability_data_unavailable | Triggers if vulnerability data is unavailable for the image’s distro packages such as rpms or dpkg. Non-OS packages like npms and java are not considered in this evaluation | | | |
Gate: licenses
License checks against found software licenses in the container image
| Trigger Name | Description | Parameter | Description | Example |
|---|
| denylist_exact_match | Triggers if the evaluated image has a package installed with software distributed under the specified (exact match) license(s). | licenses | List of license names to denylist exactly. | GPLv2+,GPL-3+,BSD-2-clause |
| denylist_exact_match | Triggers if the evaluated image has a package installed with software distributed under the specified (exact match) license(s). | package_type | Only trigger for specific package type. | all |
| denylist_partial_match | triggers if the evaluated image has a package installed with software distributed under the specified (substring match) license(s) | licenses | List of strings to do substring match for denylist. | LGPL,BSD |
| denylist_partial_match | triggers if the evaluated image has a package installed with software distributed under the specified (substring match) license(s) | package_type | Only trigger for specific package type. | all |
Gate: ruby_gems
Ruby Gem Checks
| Trigger Name | Description | Parameter | Description | Example |
|---|
| newer_version_found_in_feed | Triggers if an installed GEM is not the latest version according to GEM data feed. | | | |
| not_found_in_feed | Triggers if an installed GEM is not in the official GEM database, according to GEM data feed. | | | |
| version_not_found_in_feed | Triggers if an installed GEM version is not listed in the official GEM feed as a valid version. | | | |
| denylist | Triggers if the evaluated image has a GEM package installed that matches the specified name and version. | name | Gem name to denylist. | time_diff |
| denylist | Triggers if the evaluated image has a GEM package installed that matches the specified name and version. | version | Optional version to denylist specifically. | 0.2.9 |
| feed_data_unavailable | Triggers if anchore does not have access to the GEM data feed. | | | |
Gate: npms
NPM Checks
| Trigger Name | Description | Parameter | Description | Example |
|---|
| newer_version_in_feed | Triggers if an installed NPM is not the latest version according to NPM data feed. | | | |
| unknown_in_feeds | Triggers if an installed NPM is not in the official NPM database, according to NPM data feed. | | | |
| version_not_in_feeds | Triggers if an installed NPM version is not listed in the official NPM feed as a valid version. | | | |
| denylisted_name_version | Triggers if the evaluated image has an NPM package installed that matches the name and optionally a version specified in the parameters. | name | Npm package name to denylist. | time_diff |
| denylisted_name_version | Triggers if the evaluated image has an NPM package installed that matches the name and optionally a version specified in the parameters. | version | Npm package version to denylist specifically. | 0.2.9 |
| feed_data_unavailable | Triggers if the system does not have access to the NPM data feed. | | | |
Gate: secret_scans
Checks for secrets and content found in the image using configured regexes found in the “secret_search” section of analyzer_config.yaml.
| Trigger Name | Description | Parameter | Description | Example |
|---|
| content_regex_checks | Triggers if the secret content search analyzer has found any matches with the configured and named regexes. Checks can be configured to trigger if a match is found or is not found (selected using match_type parameter). Matches are filtered by the content_regex_name and filename_regex if they are set. The content_regex_name shoud be a value from the “secret_search” section of the analyzer_config.yaml. | content_regex_name | Name of content regexps configured in the analyzer that match if found in the image, instead of matching all. Names available by default are: [‘AWS_ACCESS_KEY’, ‘AWS_SECRET_KEY’, ‘PRIV_KEY’, ‘DOCKER_AUTH’, ‘API_KEY’]. | AWS_ACCESS_KEY |
| content_regex_checks | Triggers if the secret content search analyzer has found any matches with the configured and named regexes. Checks can be configured to trigger if a match is found or is not found (selected using match_type parameter). Matches are filtered by the content_regex_name and filename_regex if they are set. The content_regex_name shoud be a value from the “secret_search” section of the analyzer_config.yaml. | filename_regex | Regexp to filter the content matched files by. | /etc/.* |
| content_regex_checks | Triggers if the secret content search analyzer has found any matches with the configured and named regexes. Checks can be configured to trigger if a match is found or is not found (selected using match_type parameter). Matches are filtered by the content_regex_name and filename_regex if they are set. The content_regex_name shoud be a value from the “secret_search” section of the analyzer_config.yaml. | match_type | Set to define the type of match - trigger if match is found (default) or not found. | found |
Checks against image metadata, such as size, OS, distro, architecture, etc.
| Trigger Name | Description | Parameter | Description | Example |
|---|
| attribute | Triggers if a named image metadata value matches the given condition. | attribute | Attribute name to be checked. | size |
| attribute | Triggers if a named image metadata value matches the given condition. | check | The operation to perform the evaluation. | > |
| attribute | Triggers if a named image metadata value matches the given condition. | value | Value used in comparison. | 1073741824 |
Gate: always
Triggers that fire unconditionally if present in policy, useful for things like testing and deny-listing.
| Trigger Name | Description | Parameter | Description | Example |
|---|
| always | Fires if present in a policy being evaluated. Useful for things like deny-listing images or testing mappings and allowlists by using this trigger in combination with policy mapping rules. | | | |
Gate: retrieved_files
Checks against content and/or presence of files retrieved at analysis time from an image
| Trigger Name | Description | Parameter | Description | Example |
|---|
| content_not_available | Triggers if the specified file is not present/stored in the evaluated image. | path | The path of the file to verify has been retrieved during analysis | /etc/httpd.conf |
| content_regex | Evaluation of regex on retrieved file content | path | The path of the file to verify has been retrieved during analysis | /etc/httpd.conf |
| content_regex | Evaluation of regex on retrieved file content | check | The type of check to perform with the regex | match |
| content_regex | Evaluation of regex on retrieved file content | regex | The regex to evaluate against the content of the file | .SSlEnabled. |
Gate: Malware
| Trigger | Description | Parameters |
|---|
| scans | Triggers if any malware scanner has found any matches in the image. | |
| scan_not_run | Triggers if no scan was found for the image. | |
Gate: Tag Drift
Compares the SBOM from the evaluated image’s tag and the tag’s previous image, if found. Provides triggers to detect packages added, removed or modified.
| Trigger Name | Description | Parameter | Description | Example |
|---|
| packages_added | Checks to see if any packages have been added. | package_type | Package type to filter for only specific types. If ommitted, then all types are evaluated. | apk |
| packages_removed | Checks to see if any packages have been removed. | package_type | Package type to filter for only specific types. If ommitted, then all types are evaluated. | apk |
| packages_modified | Checks to see if any packages have been modified. | package_type | Package type to filter for only specific types. If ommitted, then all types are evaluated. | apk |
Gate: Image Source Drift
Triggers for evaluating diffs of an image’s source repo sbom and the built image. Operates on the diffs defined by ‘contains’ relationships where the image is the ‘source’ and the source revisions that are the ’target’ for the relationship.
| Trigger Name | Description | Parameter | Description | Example |
|---|
| package_downgraded | Checks to see if any packages have a lower version in the built image than specified in the input source sboms | package_types | Types of package to filter by | java,npm |
| package_removed | Checks to see if any packages are not installed that were expected based on the image’s related input source sboms | package_types | Types of package to filter by | java,npm |
| no_related_sources | Checks to see if there are any source sboms related to the image. Findings indicate that the image does not have a source sbom to detect drift against | | | |
Gate: Ancestry
Checks the image ancestry against approved images.
| Trigger Name | Description | Parameter | Description | Example |
|---|
| allowed_base_image_digest | Checks to see if base image is approved | base_digest | List of approved base image digests. | sha256:123abc |
| allowed_base_image_tag | Checks to see if base image is approved | base_tag | List of approved base image tags. | docker.io/debian:latest |
| no_ancestors_analyzed | Checks to see if the image has a known ancestor | | | |
Gate: Distro
Checks against the image distro metadata. This can be used to denylist versions of a distro, such as versions that are EOL.
| Trigger Name | Description | Parameter | Description | Example |
|---|
| deny | Triggers if the image distro and version match the criteria | distro | Name of the distribution to match | debian |
| deny | Triggers if the image distro and version match the criteria | version | Version of distribution to compare against | 9 |
| deny | Triggers if the image distro and version match the criteria | check | The comparison to use in the evaluation | < |
Next Steps
See how policy gates can be used in evaluation steps in Evaluating Images Against Policies
2 - Evaluating Images Against Policies
Introduction
The evaluate command can be used to evaluate a given image for policy compliance.
The image to be evaluated can be in the following format:
- Image Digest
- Image ID
- registry/repo:tag
Using the Evaluate command
# anchorectl image check docker.io/debian:latest
✔ Evaluated against policy [failed] docker.io/debian:latest
Tag: docker.io/debian:latest
Digest: sha256:0fcb5a38077422c4e70c5c43be21831193ff4559d143e27d8d5721e7a814bdcc
Policy ID: 2c53a13c-1765-11e8-82ef-23527761d060
Last Evaluation: 2023-10-25T20:34:43Z
Evaluation: fail
By default, only the summary of the evaluation is shown. Passing the --detail parameter will show the policy checks that raised warnings or errors.
# anchorectl image check docker.io/debian:latest --detail
✔ Evaluated against policy [failed] docker.io/debian:latest
Tag: docker.io/debian:latest
Digest: sha256:0fcb5a38077422c4e70c5c43be21831193ff4559d143e27d8d5721e7a814bdcc
Policy ID: 2c53a13c-1765-11e8-82ef-23527761d060
Last Evaluation: 2023-10-25T20:35:05Z
Evaluation: fail
Final Action: stop
Reason: policy_evaluation
Policy Evaluation Details:
┌─────────────────┬─────────────┬────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┬────────┐
│ GATE │ TRIGGER │ DESCRIPTION │ STATUS │
├─────────────────┼─────────────┼────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┼────────┤
│ dockerfile │ instruction │ Dockerfile directive 'HEALTHCHECK' not found, matching condition 'not_exists' check │ warn │
│ vulnerabilities │ package │ MEDIUM Vulnerability found in os package type (dpkg) - libgnutls30 (CVE-2011-3389 - https://security-tracker.debian.org/tracker/CVE-2011-3389) │ warn │
│ vulnerabilities │ package │ CRITICAL Vulnerability found in os package type (dpkg) - zlib1g (CVE-2022-37434 - https://security-tracker.debian.org/tracker/CVE-2022-37434) │ stop │
└─────────────────┴─────────────┴────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┴────────┘
In this example we specified library/repo:tag which could be ambiguous. At the time of writing the image Digest for library/debian:latest was sha256:0fc..... however previously different images may have been tagged as library/debian:latest. The --history parameter can be passed to show historic evaluations based on previous images or previous policies.
Anchore supports allowlisting and denylisting images by their name, ID or digest. A denylist or allowlist takes precedence over any policy checks. For example if an image is explicitly listed as denylisted then even if all the individual policy checks pass the image will still fail evaluation.
# anchorectl image check docker.io/debian:latest --detail
✔ Evaluated against policy [failed] docker.io/debian:latest
Tag: docker.io/debian:latest
Digest: sha256:0fcb5a38077422c4e70c5c43be21831193ff4559d143e27d8d5721e7a814bdcc
Policy ID: 2c53a13c-1765-11e8-82ef-23527761d060
Last Evaluation: 2023-10-25T20:39:36Z
Evaluation: fail
Final Action: stop
Reason: denylisted
Policy Evaluation Details:
┌─────────────────┬─────────────┬────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┬────────┐
│ GATE │ TRIGGER │ DESCRIPTION │ STATUS │
├─────────────────┼─────────────┼────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┼────────┤
│ dockerfile │ instruction │ Dockerfile directive 'HEALTHCHECK' not found, matching condition 'not_exists' check │ warn │
│ vulnerabilities │ package │ MEDIUM Vulnerability found in os package type (dpkg) - libgnutls30 (CVE-2011-3389 - https://security-tracker.debian.org/tracker/CVE-2011-3389) │ warn │
└─────────────────┴─────────────┴────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┴────────┘
In this example even though the image only had one policy check that raised a warning the image fails policy evaluation since it is present on a denylist.
Evaluating status based on Digest or ID
Performing an evaluation on an image specified by name is not recommended since an image name is ambiguous. For example the tag docker.io/library/centos:latest refers to whatever image has the tag library/centos:latest at the time of evaluation. At any point in time another image may be tagged as library/centos:latest.
It is recommended that images are referenced by their Digest. For example at the time of writing the digest of the ‘current’ library/centos:latest image is sha256:191c883e479a7da2362b2d54c0840b2e8981e5ab62e11ab925abf8808d3d5d44
If the image to be evaluated is specified by Image ID or Image Digest then the --tag parameter must be added. Policies are mapped to images based on registry/repo:tag so since an Image ID may may to multiple different names we must specify the name user in the evaluation.
For example - referencing by Image Digest:
# anchorectl image check docker.io/debian@sha256:0fcb5a38077422c4e70c5c43be21831193ff4559d143e27d8d5721e7a814bdcc --detail --tag docker.io/debian:latest
✔ Evaluated against policy [failed] docker.io/debian@sha256:0fcb5a38077422c4e70c5c43be21831193ff4559d143e27d8d5721e7a814bdcc
Tag: docker.io/debian:latest
Digest: sha256:0fcb5a38077422c4e70c5c43be21831193ff4559d143e27d8d5721e7a814bdcc
Policy ID: 2c53a13c-1765-11e8-82ef-23527761d060
Last Evaluation: 2023-10-25T20:44:24Z
Evaluation: fail
Final Action: stop
Reason: denylisted
Policy Evaluation Details:
┌─────────────────┬─────────────┬────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┬────────┐
│ GATE │ TRIGGER │ DESCRIPTION │ STATUS │
├─────────────────┼─────────────┼────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┼────────┤
│ dockerfile │ instruction │ Dockerfile directive 'HEALTHCHECK' not found, matching condition 'not_exists' check │ warn │
│ vulnerabilities │ package │ MEDIUM Vulnerability found in os package type (dpkg) - libgnutls30 (CVE-2011-3389 - https://security-tracker.debian.org/tracker/CVE-2011-3389) │ warn │
│ vulnerabilities │ package │ CRITICAL Vulnerability found in os package type (dpkg) - zlib1g (CVE-2022-37434 - https://security-tracker.debian.org/tracker/CVE-2022-37434) │ stop │
└─────────────────┴─────────────┴────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┴────────┘
For example - referencing by image ID:
# anchorectl image check dd8bae8d259fed93eb54b3bca0adeb647fc07f6ef16745c8ed4144ada4d51a95 --detail --tag docker.io/debian:latest
✔ Evaluated against policy [failed] dd8bae8d259fed93eb54b3bca0adeb647fc07f6ef16745c8ed4144ada4d51a95
Tag: docker.io/debian:latest
Digest: sha256:0fcb5a38077422c4e70c5c43be21831193ff4559d143e27d8d5721e7a814bdcc
Policy ID: 2c53a13c-1765-11e8-82ef-23527761d060
Last Evaluation: 2023-10-25T20:45:20Z
Evaluation: fail
Final Action: stop
Reason: denylisted
Policy Evaluation Details:
┌─────────────────┬─────────────┬────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┬────────┐
│ GATE │ TRIGGER │ DESCRIPTION │ STATUS │
├─────────────────┼─────────────┼────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┼────────┤
│ dockerfile │ instruction │ Dockerfile directive 'HEALTHCHECK' not found, matching condition 'not_exists' check │ warn │
│ vulnerabilities │ package │ MEDIUM Vulnerability found in os package type (dpkg) - libgnutls30 (CVE-2011-3389 - https://security-tracker.debian.org/tracker/CVE-2011-3389) │ warn │
│ vulnerabilities │ package │ CRITICAL Vulnerability found in os package type (dpkg) - zlib1g (CVE-2022-37434 - https://security-tracker.debian.org/tracker/CVE-2022-37434) │ stop │
└─────────────────┴─────────────┴────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┴────────┘
3 - Policy Mappings
Mappings in the policy are a set of rules, evaluated in order, that describe matches on an image, id, digest, or tag and the corresponding sets of policies and allowlists to apply to any image that matches the rule’s criteria.
Policies can contain one or more mapping rules that are used to determine which rule_sets and allowlists apply to a given image. They match images on the registry and repository, and finally be one of id, digest, or tag.
A mapping has:
- Registry - The registry url to match, including wildcards (e.g. ‘docker.io’, ‘quay.io’, ‘gcr.io’, ‘*’)
- Repository - The repository name to match, including wildcards (e.g. ’library/nginx’, ‘mydockerhubusername/myrepositoryname’, ’library/*’, ‘*’)
- Image - The way to select an image that matches the registry and repository filters
- type: how to reference the image and the expected format of the ‘value’ property
- “tag” - just the tag name itself (the part after the ‘:’ in a docker pull string: e.g. nginx:latest -> ’latest’ is the tag name)
- “id” - the image id
- “digest” - the image digest (e.g. sha256@abc123)
- value: the value to match against, including wildcards
Note: Unlike other parts of the policy, Mappings are evaluated in order and will halt on the first matching rule. This is important to understand when combined with wildcard matches since it enables sophisticated matching behavior.
Examples
Example 1, all images match a single catch-all rule:
[
{
"registry": "*",
"repository": "*",
"image": { "type": "tag", "value": "*"},
"rule_set_ids": ["defaultpolicy"],
"allowlist_ids": ["defaultallowlist"]
}
]
Example 2, all “official” images from DockerHub are evaluated against officialspolicy and officialsallowlist (made up names for this example), while all others from DockerHub will be evaluated against defaultpolicy and defaultallowlist , and private GCR images will be evaluated against gcrpolicy and gcrallowlist:
[
{
"registry": "docker.io",
"repository": "library/*",
"image": { "type": "tag", "value": "*"},
"rule_set_ids": [ "officialspolicy"],
"allowlist_ids": [ "officialsallowlist"]
},
{
"registry": "gcr.io",
"repository": "*",
"image": { "type": "tag", "value": "*"},
"rule_set_ids": [ "gcrpolicy"],
"allowlist_ids": [ "gcrallowlist"]
},
{
"registry": "*",
"repository": "*",
"image": { "type": "tag", "value": "*"},
"rule_set_ids": [ "defaultpolicy"],
"allowlist_ids": [ "defaultallowlist"]
}
]
Example 3, all images from a unknown registry will be evaluated against defaultpolicy and defaultallowlist, and an internal registry’s images will be evaluated against a different set (internalpolicy and internalallowlist):
[
{
"registry": "myregistry.mydomain.com:5000",
"repository": "*",
"image": { "type": "tag", "value": "*"},
"policy_ids": [ "internalpolicy"],
"allowlist_ids": [ "internalallowlist"]
},
{
"registry": "*",
"repository": "*",
"image": { "type": "tag", "value": "*"},
"policy_ids": [ "defaultpolicy"],
"allowlist_ids": [ "defaultallowlist"]
}
]
Using Multiple Policies and Allowlists
The result of the evaluation of the mapping section of a policy is the list of rule sets and allowlists that will be used for actually evaluating the image. Because multiple rule sets and allowlists can be specified in each mapping rule, you can use granular rule sets and allowlists and then combined them in the mapping rules.
Examples of schemes to use for how to split-up policies include:
- Different policies for different types of checks such that each policy only uses one or two gates (e.g. vulnerabilities, packages, dockerfile)
- Different policies for web servers, another for database servers, another for logging infrastructure, etc.
- Different policies for different parts of the stack: os-packages vs. application packages
Next Steps
Read more about the Allowlists component of a policy.
5 - Policy Gate: dockerfile
Introduction
This article reviews the “dockerfile” gate and its triggers. The dockerfile gate allows users to perform checks on the content of the dockerfile or docker history for an image and make policy actions based on the construction of an image, not just its content. This is particularly useful for enforcing best practices or metadata inclusion (e.g. labels) on images.
Anchore is either given a dockerfile or infers one from the docker image layer history. There are implications to what data is available and what it means depending on these differing sources, so first, we’ll cover the input data for the gate and how it impacts the triggers and parameters used.
The “dockerfile”
The data that this gate operates on can come from two different sources:
- The actual dockerfile used to build an image, as provided by the user at the time of running
anchorectl image add <img ref> --dockerfile <filename> or the corresponding API call to: POST /images?dockerfile= - The history from layers as encoded in the image itself (see
docker history <img> for this output)
All images have data from history available, but data from the actual dockerfile is only available when a user provides it. This also means that any images analyzed by the tag watcher functionality will not have an actual dockerfile.
The FROM line
In the actual dockerfile, the FROM instruction is preserved and available as used to build the image, however in the history data, the FROM line will always be the very first FROM instruction used to build the image and all of its dependent based image. Thus, for most images, the value in the history will be omitted and Anchore will automatically infer a FROM scratch line, which is logically inserted for this gate if the dockerfile/history does not contain an explicit FROM entry.
For example, using the docker.io/jenkins/jenkins image:
IMAGE CREATED CREATED BY SIZE COMMENT
sha256:3b9c9666a66e53473c05a3c69eb2cb888a8268f76935eecc7530653cddc28981 11 hours ago /bin/sh -c #(nop) COPY file:3a15c25533fd87983edc33758f62af7b543ccc3ce9dd570e473eb0702f5f298e in /usr/local/bin/install-plugins.sh 8.79kB
<missing> 11 hours ago /bin/sh -c #(nop) COPY file:f97999fac8a63cf8b635a54ea84a2bc95ae3da4d81ab55267c92b28b502d8812 in /usr/local/bin/plugins.sh 3.96kB
<missing> 11 hours ago /bin/sh -c #(nop) ENTRYPOINT ["/sbin/tini" "--" "/usr/local/bin/jenkins.sh"] 0B
<missing> 11 hours ago /bin/sh -c #(nop) COPY file:dc942ca949bb159f81bbc954773b3491e433d2d3e3ef90bac80ecf48a313c9c9 in /bin/tini 529B
<missing> 11 hours ago /bin/sh -c #(nop) COPY file:a8f986413b77bf4d88562b9d3a0dce98ab6e75403192aa4d4153fb41f450843d in /usr/local/bin/jenkins.sh 1.45kB
<missing> 11 hours ago /bin/sh -c #(nop) COPY file:55594d9d2aed007553a6743a43039b1a48b30527f8fb991ad93e1fd5b1298f60 in /usr/local/bin/jenkins-support 6.12kB
<missing> 11 hours ago /bin/sh -c #(nop) USER jenkins 0B
<missing> 11 hours ago /bin/sh -c #(nop) ENV COPY_REFERENCE_FILE_LOG=/var/jenkins_home/copy_reference_file.log 0B
<missing> 11 hours ago /bin/sh -c #(nop) EXPOSE 50000 0B
<missing> 11 hours ago /bin/sh -c #(nop) EXPOSE 8080 0B
<missing> 11 hours ago |9 JENKINS_SHA=e026221efcec9528498019b6c1581cca70fe9c3f6b10303777d85c6699bca0e4 JENKINS_URL=https://repo.jenkins-ci.org/public/org/jenkins-ci/main/jenkins-war/2.161/jenkins-war-2.161.war TINI_VERSION=v0.16.1 agent_port=50000 gid=1000 group=jenkins http_port=8080 uid=1000 user=jenkins /bin/sh -c chown -R ${user} "$JENKINS_HOME" /usr/share/jenkins/ref 328B
<missing> 11 hours ago /bin/sh -c #(nop) ENV JENKINS_INCREMENTALS_REPO_MIRROR=https://repo.jenkins-ci.org/incrementals 0B
<missing> 11 hours ago /bin/sh -c #(nop) ENV JENKINS_UC_EXPERIMENTAL=https://updates.jenkins.io/experimental 0B
<missing> 11 hours ago /bin/sh -c #(nop) ENV JENKINS_UC=https://updates.jenkins.io 0B
<missing> 11 hours ago |9 JENKINS_SHA=e026221efcec9528498019b6c1581cca70fe9c3f6b10303777d85c6699bca0e4 JENKINS_URL=https://repo.jenkins-ci.org/public/org/jenkins-ci/main/jenkins-war/2.161/jenkins-war-2.161.war TINI_VERSION=v0.16.1 agent_port=50000 gid=1000 group=jenkins http_port=8080 uid=1000 user=jenkins /bin/sh -c curl -fsSL ${JENKINS_URL} -o /usr/share/jenkins/jenkins.war && echo "${JENKINS_SHA} /usr/share/jenkins/jenkins.war" | sha256sum -c - 76MB
<missing> 11 hours ago /bin/sh -c #(nop) ARG JENKINS_URL=https://repo.jenkins-ci.org/public/org/jenkins-ci/main/jenkins-war/2.161/jenkins-war-2.161.war 0B
<missing> 11 hours ago /bin/sh -c #(nop) ARG JENKINS_SHA=5bb075b81a3929ceada4e960049e37df5f15a1e3cfc9dc24d749858e70b48919 0B
<missing> 11 hours ago /bin/sh -c #(nop) ENV JENKINS_VERSION=2.161 0B
<missing> 11 hours ago /bin/sh -c #(nop) ARG JENKINS_VERSION 0B
<missing> 11 hours ago /bin/sh -c #(nop) COPY file:c84b91c835048a52bb864c1f4662607c56befe3c4b1520b0ea94633103a4554f in /usr/share/jenkins/ref/init.groovy.d/tcp-slave-agent-port.groovy 328B
<missing> 11 hours ago |7 TINI_VERSION=v0.16.1 agent_port=50000 gid=1000 group=jenkins http_port=8080 uid=1000 user=jenkins /bin/sh -c curl -fsSL https://github.com/krallin/tini/releases/download/${TINI_VERSION}/tini-static-$(dpkg --print-architecture) -o /sbin/tini && curl -fsSL https://github.com/krallin/tini/releases/download/${TINI_VERSION}/tini-static-$(dpkg --print-architecture).asc -o /sbin/tini.asc && gpg --no-tty --import ${JENKINS_HOME}/tini_pub.gpg && gpg --verify /sbin/tini.asc && rm -rf /sbin/tini.asc /root/.gnupg && chmod +x /sbin/tini 866kB
<missing> 11 hours ago /bin/sh -c #(nop) COPY file:653491cb486e752a4c2b4b407a46ec75646a54eabb597634b25c7c2b82a31424 in /var/jenkins_home/tini_pub.gpg 7.15kB
<missing> 11 hours ago /bin/sh -c #(nop) ARG TINI_VERSION=v0.16.1 0B
<missing> 11 hours ago |6 agent_port=50000 gid=1000 group=jenkins http_port=8080 uid=1000 user=jenkins /bin/sh -c mkdir -p /usr/share/jenkins/ref/init.groovy.d 0B
<missing> 11 hours ago /bin/sh -c #(nop) VOLUME [/var/jenkins_home] 0B
<missing> 11 hours ago |6 agent_port=50000 gid=1000 group=jenkins http_port=8080 uid=1000 user=jenkins /bin/sh -c mkdir -p $JENKINS_HOME && chown ${uid}:${gid} $JENKINS_HOME && groupadd -g ${gid} ${group} && useradd -d "$JENKINS_HOME" -u ${uid} -g ${gid} -m -s /bin/bash ${user} 328kB
<missing> 11 hours ago /bin/sh -c #(nop) ENV JENKINS_SLAVE_AGENT_PORT=50000 0B
<missing> 11 hours ago /bin/sh -c #(nop) ENV JENKINS_HOME=/var/jenkins_home 0B
<missing> 11 hours ago /bin/sh -c #(nop) ARG JENKINS_HOME=/var/jenkins_home 0B
<missing> 11 hours ago /bin/sh -c #(nop) ARG agent_port=50000 0B
<missing> 11 hours ago /bin/sh -c #(nop) ARG http_port=8080 0B
<missing> 11 hours ago /bin/sh -c #(nop) ARG gid=1000 0B
<missing> 11 hours ago /bin/sh -c #(nop) ARG uid=1000 0B
<missing> 11 hours ago /bin/sh -c #(nop) ARG group=jenkins 0B
<missing> 11 hours ago /bin/sh -c #(nop) ARG user=jenkins 0B
<missing> 11 hours ago /bin/sh -c apt-get update && apt-get install -y git curl && rm -rf /var/lib/apt/lists/* 0B
<missing> 3 weeks ago /bin/sh -c set -ex; if [ ! -d /usr/share/man/man1 ]; then mkdir -p /usr/share/man/man1; fi; apt-get update; apt-get install -y --no-install-recommends openjdk-8-jdk="$JAVA_DEBIAN_VERSION" ; rm -rf /var/lib/apt/lists/*; [ "$(readlink -f "$JAVA_HOME")" = "$(docker-java-home)" ]; update-alternatives --get-selections | awk -v home="$(readlink -f "$JAVA_HOME")" 'index($3, home) == 1 { $2 = "manual"; print | "update-alternatives --set-selections" }'; update-alternatives --query java | grep -q 'Status: manual' 348MB
<missing> 3 weeks ago /bin/sh -c #(nop) ENV JAVA_DEBIAN_VERSION=8u181-b13-2~deb9u1 0B
<missing> 3 weeks ago /bin/sh -c #(nop) ENV JAVA_VERSION=8u181 0B
<missing> 3 weeks ago /bin/sh -c #(nop) ENV JAVA_HOME=/docker-java-home 0B
<missing> 3 weeks ago /bin/sh -c ln -svT "/usr/lib/jvm/java-8-openjdk-$(dpkg --print-architecture)" /docker-java-home 33B
<missing> 3 weeks ago /bin/sh -c { echo '#!/bin/sh'; echo 'set -e'; echo; echo 'dirname "$(dirname "$(readlink -f "$(which javac || which java)")")"'; } > /usr/local/bin/docker-java-home && chmod +x /usr/local/bin/docker-java-home 87B
<missing> 3 weeks ago /bin/sh -c #(nop) ENV LANG=C.UTF-8 0B
<missing> 3 weeks ago /bin/sh -c apt-get update && apt-get install -y --no-install-recommends bzip2 unzip xz-utils && rm -rf /var/lib/apt/lists/* 2.21MB
<missing> 3 weeks ago /bin/sh -c apt-get update && apt-get install -y --no-install-recommends bzr git mercurial openssh-client subversion procps && rm -rf /var/lib/apt/lists/* 142MB
<missing> 3 weeks ago /bin/sh -c set -ex; if ! command -v gpg > /dev/null; then apt-get update; apt-get install -y --no-install-recommends gnupg dirmngr ; rm -rf /var/lib/apt/lists/*; fi 7.81MB
<missing> 3 weeks ago /bin/sh -c apt-get update && apt-get install -y --no-install-recommends ca-certificates curl netbase wget && rm -rf /var/lib/apt/lists/* 23.2MB
<missing> 3 weeks ago /bin/sh -c #(nop) CMD ["bash"] 0B
<missing> 3 weeks ago /bin/sh -c #(nop) ADD file:da71baf0d22cb2ede91c5e3ff959607e47459a9d7bda220a62a3da362b0e59ea in / 101MB
Where the actual dockerfile for that image is:
FROM openjdk:8-jdk-stretch
RUN apt-get update && apt-get install -y git curl && rm -rf /var/lib/apt/lists/*
ARG user=jenkins
ARG group=jenkins
ARG uid=1000
ARG gid=1000
ARG http_port=8080
ARG agent_port=50000
ARG JENKINS_HOME=/var/jenkins_home
ENV JENKINS_HOME $JENKINS_HOME
ENV JENKINS_SLAVE_AGENT_PORT ${agent_port}
# Jenkins is run with user `jenkins`, uid = 1000
# If you bind mount a volume from the host or a data container,
# ensure you use the same uid
RUN mkdir -p $JENKINS_HOME \
&& chown ${uid}:${gid} $JENKINS_HOME \
&& groupadd -g ${gid} ${group} \
&& useradd -d "$JENKINS_HOME" -u ${uid} -g ${gid} -m -s /bin/bash ${user}
# Jenkins home directory is a volume, so configuration and build history
# can be persisted and survive image upgrades
VOLUME $JENKINS_HOME
# `/usr/share/jenkins/ref/` contains all reference configuration we want
# to set on a fresh new installation. Use it to bundle additional plugins
# or config file with your custom jenkins Docker image.
RUN mkdir -p /usr/share/jenkins/ref/init.groovy.d
# Use tini as subreaper in Docker container to adopt zombie processes
ARG TINI_VERSION=v0.16.1
COPY tini_pub.gpg ${JENKINS_HOME}/tini_pub.gpg
RUN curl -fsSL https://github.com/krallin/tini/releases/download/${TINI_VERSION}/tini-static-$(dpkg --print-architecture) -o /sbin/tini \
&& curl -fsSL https://github.com/krallin/tini/releases/download/${TINI_VERSION}/tini-static-$(dpkg --print-architecture).asc -o /sbin/tini.asc \
&& gpg --no-tty --import ${JENKINS_HOME}/tini_pub.gpg \
&& gpg --verify /sbin/tini.asc \
&& rm -rf /sbin/tini.asc /root/.gnupg \
&& chmod +x /sbin/tini
COPY init.groovy /usr/share/jenkins/ref/init.groovy.d/tcp-slave-agent-port.groovy
# jenkins version being bundled in this docker image
ARG JENKINS_VERSION
ENV JENKINS_VERSION ${JENKINS_VERSION:-2.121.1}
# jenkins.war checksum, download will be validated using it
ARG JENKINS_SHA=5bb075b81a3929ceada4e960049e37df5f15a1e3cfc9dc24d749858e70b48919
# Can be used to customize where jenkins.war get downloaded from
ARG JENKINS_URL=https://repo.jenkins-ci.org/public/org/jenkins-ci/main/jenkins-war/${JENKINS_VERSION}/jenkins-war-${JENKINS_VERSION}.war
# could use ADD but this one does not check Last-Modified header neither does it allow to control checksum
# see https://github.com/docker/docker/issues/8331
RUN curl -fsSL ${JENKINS_URL} -o /usr/share/jenkins/jenkins.war \
&& echo "${JENKINS_SHA} /usr/share/jenkins/jenkins.war" | sha256sum -c -
ENV JENKINS_UC https://updates.jenkins.io
ENV JENKINS_UC_EXPERIMENTAL=https://updates.jenkins.io/experimental
ENV JENKINS_INCREMENTALS_REPO_MIRROR=https://repo.jenkins-ci.org/incrementals
RUN chown -R ${user} "$JENKINS_HOME" /usr/share/jenkins/ref
# for main web interface:
EXPOSE ${http_port}
# will be used by attached slave agents:
EXPOSE ${agent_port}
ENV COPY_REFERENCE_FILE_LOG $JENKINS_HOME/copy_reference_file.log
USER ${user}
COPY jenkins-support /usr/local/bin/jenkins-support
COPY jenkins.sh /usr/local/bin/jenkins.sh
COPY tini-shim.sh /bin/tini
ENTRYPOINT ["/sbin/tini", "--", "/usr/local/bin/jenkins.sh"]
# from a derived Dockerfile, can use `RUN plugins.sh active.txt` to setup /usr/share/jenkins/ref/plugins from a support bundle
COPY plugins.sh /usr/local/bin/plugins.sh
COPY install-plugins.sh /usr/local/bin/install-plugins.sh
Anchore will detect the history/dockerfile as this, if not explicitly provided (note order is reversed from docker history output, so it reads in same order as actual dockerfile):
[
{
"Size" : 45323792,
"Tags" : [],
"Comment" : "",
"Id" : "sha256:cd8eada9c7bb496eb685fc6d2198c33db7cb05daf0fde42e4cf5bf0127cbdf38",
"Created" : "2018-12-28T23:29:37.981962131Z",
"CreatedBy" : "/bin/sh -c #(nop) ADD file:da71baf0d22cb2ede91c5e3ff959607e47459a9d7bda220a62a3da362b0e59ea in / "
},
{
"Size" : 0,
"Tags" : [],
"Comment" : "",
"Id" : "<missing>",
"Created" : "2018-12-28T23:29:38.226681736Z",
"CreatedBy" : "/bin/sh -c #(nop) CMD [\"bash\"]"
},
{
"Size" : 10780911,
"Comment" : "",
"Tags" : [],
"CreatedBy" : "/bin/sh -c apt-get update && apt-get install -y --no-install-recommends \t\tca-certificates \t\tcurl \t\tnetbase \t\twget \t&& rm -rf /var/lib/apt/lists/*",
"Created" : "2018-12-29T00:04:28.920875483Z",
"Id" : "sha256:c2677faec825930a8844845f55454ee0495ceb5bea9fc904d5b3125de863dc1d"
},
{
"Comment" : "",
"Tags" : [],
"Size" : 4340024,
"CreatedBy" : "/bin/sh -c set -ex; \tif ! command -v gpg > /dev/null; then \t\tapt-get update; \t\tapt-get install -y --no-install-recommends \t\t\tgnupg \t\t\tdirmngr \t\t; \t\trm -rf /var/lib/apt/lists/*; \tfi",
"Created" : "2018-12-29T00:04:34.642152001Z",
"Id" : "sha256:fcce419a96b1219a265bf7a933d66b585a6f8d73448533f3833c73ad49fb5e88"
},
{
"Size" : 50062697,
"Tags" : [],
"Comment" : "",
"Id" : "sha256:045b51e26e750443c84216071a1367a7aae0b76245800629dc04934628b4b1ea",
"CreatedBy" : "/bin/sh -c apt-get update && apt-get install -y --no-install-recommends \t\tbzr \t\tgit \t\tmercurial \t\topenssh-client \t\tsubversion \t\t\t\tprocps \t&& rm -rf /var/lib/apt/lists/*",
"Created" : "2018-12-29T00:04:59.676112605Z"
},
... <truncated for brevity> ...
{
"Tags" : [],
"Comment" : "",
"Size" : 0,
"Id" : "<missing>",
"CreatedBy" : "/bin/sh -c #(nop) ENTRYPOINT [\"/sbin/tini\" \"--\" \"/usr/local/bin/jenkins.sh\"]",
"Created" : "2019-01-21T08:56:30.737221895Z"
},
{
"Size" : 1549,
"Tags" : [],
"Comment" : "",
"Id" : "sha256:283cd3aba8691a3b9d22d923de66243b105758e74de7d9469fe55a6a58aeee30",
"Created" : "2019-01-21T08:56:32.015667468Z",
"CreatedBy" : "/bin/sh -c #(nop) COPY file:f97999fac8a63cf8b635a54ea84a2bc95ae3da4d81ab55267c92b28b502d8812 in /usr/local/bin/plugins.sh "
},
{
"Comment" : "",
"Tags" : [],
"Size" : 3079,
"Created" : "2019-01-21T08:56:33.158854485Z",
"CreatedBy" : "/bin/sh -c #(nop) COPY file:3a15c25533fd87983edc33758f62af7b543ccc3ce9dd570e473eb0702f5f298e in /usr/local/bin/install-plugins.sh ",
"Id" : "sha256:b0ce8ab5a5a7da5d762f25af970f4423b98437a8318cb9852c3f21354cbf914f"
}
]
NOTE: Anchore processes the leading /bin/sh commands, so you do not have to include those in any trigger param config if using the docker history output.
The actual_dockerfile_only Parameter
The actual vs history impacts the semantics of the dockerfile gate’s triggers. To allow explicit control of the differences, most triggers in this gate includes a parameter: actual_dockerfile_only that if set to true or false will ensure the trigger check is only done on the source of data specified. If actual_dockerfile_only = true, then the trigger will evaluate only if an actual dockerfile is available for the image and will skip evaluation if not. If actual_dockerfile_only is false or omitted, then the trigger will run on the actual dockerfile if available, or the history data if the dockerfile was not provided.
Differences in data between Docker History and actual Dockerfile
With Actual Dockerfile:
- FROM line is preserved, so the parent tag of the image is easily available
- Instruction checks are all against instructions created during the build for that exact image, not any parent images
- When the actual_dockerfile_only parameter is set to true, all instructions from the parent image are ignored in policy processing. This may have some unexpected consequences depending on how your images are structured and layered (e.g. golden base images that establish common patterns of volumes, labels, healthchecks)
- COPY/ADD instructions will maintain the actual values used
- Multistage-builds in that specific dockerfile will be visible with multiple FROM lines in the output
With Docker History data, when no dockerfile is provided:
- FROM line is not accurate, and will nearly always default to ‘FROM scratch’
- Instructions are processed from all layers in the image
- COPY and ADD instructions are transformed into SHAs rather than the actual file path/name used at build-time
- Multi-stage builds are not tracked with multiple FROM lines, only the copy operations between the phases
Trigger: instruction
This trigger evaluates instructions found in the “dockerfile”
Supported Directives/Instructions:
Parameters
actual_dockerfile_only (optional): See above
instruction: The dockerfile instruction to check against. One of:
- ADD
- ARG
- COPY
- CMD
- ENTRYPOINT
- ENV
- EXPOSE
- FROM
- HEALTHCHECK
- LABEL
- MAINTAINER
- ONBUILD
- USER
- RUN
- SHELL
- STOPSIGNAL
- VOLUME
- WORKDIR
check: The comparison/evaluation to perform. One of: =, != , exists, not_exists, like, not_like, in, not_in.
value (optional): A string value to compare against, if applicable
Examples
- Ensure an image has a HEALTHCHECK defined in the image (warn if not found):
{
"gate": "dockerfile",
"trigger": "instruction",
"action": "warn",
"parameters": [
{
"name": "instruction",
"value": "HEALTHCHECK"
},
{
"name": "check",
"value": "not_exists"
}
]
}
- Check for AWS environment variables set:
{
"gate": "dockerfile",
"trigger": "instruction",
"action": "stop",
"parameters": [
{
"name": "instruction",
"value": "ENV"
},
{
"name": "check",
"value": "like"
},
{
"name": "value",
"value": "AWS_.*KEY"
}
]
}
Trigger: packages_added
This trigger warns if a package was added to the SBOM.
Parameters
Optional parameter: “package_type”
Example
Raise a warning if packages were added.
{
"action": "WARN",
"gate": "tag_drift",
"trigger": "packages_added",
"params": [],
"id": "1ba3461f-b9db-4a6c-ac88-329d38e08df5"
}
Trigger: packages_removed
This trigger warns if a package was deleted from the SBOM.
Parameters
Optional parameter: “package_type”
Example
Raise a warning if packages were deleted.
{
"action": "WARN",
"gate": "tag_drift",
"trigger": "packages_removed",
"params": [],
"id": "de05d77b-1f93-4df4-a65d-57d9042b1f3a"
}
Trigger: packages_modified
This trigger warns if a package was changed in the SBOM.
Parameters
Optional parameter: “package_type”
Example
Raise a warning if packages were changed.
{
"action": "WARN",
"gate": "tag_drift",
"trigger": "packages_modified",
"params": [],
"id": "1168b0ac-df6c-4715-8077-2cb3e016cf63"
}
Trigger: effective_user
This trigger processes all USER directives in the dockerfile or history to determine which user will be used to run the container by default (assuming no user is set explicitly at runtime). The detected value is then subject to a allowlist or denylist filter depending on the configured parameters. Typically, this is used for denylisting the root user.
Parameters
actual_dockerfile_only (optional): See above
users: A string with a comma delimited list of username to check for
type: The type of check to perform. One of: ‘denylist’ or ‘allowlist’. This determines how the value of the ‘users’ parameter is interpreted.
Examples
- Denylist root user
{
"gate": "dockerfile",
"trigger": "effective_user",
"action": "stop",
"parameters": [
{
"name": "users",
"value": "root"
},
{
"name": "type",
"value": "denylist"
}
]
}
- Denylist root user but only if set in actual dockerfile, not inherited from parent image
{
"gate": "dockerfile",
"trigger": "effective_user",
"action": "stop",
"parameters": [
{
"name": "users",
"value": "root"
},
{
"name": "type",
"value": "denylist"
},
{
"name": "actual_dockerfile_only",
"value": "true"
}
]
}
- Warn if the user is not either “nginx” or “jenkins”
{
"gate": "dockerfile",
"trigger": "effective_user",
"action": "warn",
"parameters": [
{
"name": "users",
"value": "nginx,jenkins"
},
{
"name": "type",
"value": "allowlist"
}
]
}
Trigger: exposed_ports
This trigger processes the set of EXPOSE directives in the dockerfile/history to determine the set of ports that are defined to be exposed (since it can span multiple directives). It performs checks on that set to denylist/allowlist them based on parameter settings.
Parameters
actual_dockerfile_only (optional): See above
ports: String of comma delimited port numbers to be checked
type: The type of check to perform. One of: ‘denylist’ or ‘allowlist’. This determines how the value of the ‘users’ parameter is interpreted
Examples
- Allow only ports 80 and 443. Trigger will fire on any port defined to be exposed that is not 80 or 443
{
"gate": "dockerfile",
"trigger": "exposed_ports",
"action": "warn",
"parameters": [
{
"name": "ports",
"value": "80,443"
},
{
"name": "type",
"value": "allowlist"
}
]
}
- Denylist ports 21 (ftp), 22 (ssh), and 53 (dns) . Trigger will fire a match on ports 21, 22, 53 if found in EXPOSE directives
{
"gate": "dockerfile",
"trigger": "exposed_ports",
"action": "warn",
"parameters": [
{
"name": "ports",
"value": "21,22,53"
},
{
"name": "type",
"value": "denylist"
}
]
}
Trigger: no_dockerfile_provided
This trigger allows checks on the way the image was added, firing if the dockerfile was not explicitly provided at analysis time. This is useful in identifying and qualifying other trigger matches.
Parameters
None
Examples
- Raise a warning if no dockerfile was provided at analysis time
{
"gate": "dockerfile",
"trigger": "no_dockerfile_provided",
"action": "warn",
"parameters": []
}
6 - SBOM Drift
Software bill of materials (SBOM) drift is understanding how SBOMs change over time, and is a key part of managing your SBOMs. The nature of changes themselves may give early warning into unexpected behavior or intrusion into the build system that a review without context from previous builds would not easily be able to identify.
To do this, you set triggers for policy violations on changes in the SBOM between images with the same tag so that it can detect drift over time between builds of your images.
Gate: tag_drift
The triggers are:
- packages_added
- packages_removed
- packages_modified
The “tag_drift” gate compares the SBOMs from the image being evaluated as input, and the SBOM of the image that precedes the input image with the requested tag provided for policy evaluation. The triggers in this gate evaluate the result to determine if packages were added, removed, or modified.
Trigger: packages_added
This trigger warns if a package was added to the SBOM.
Parameters
Optional parameter: “package_type”
Example
Raise a warning if packages were added.
{
"action": "WARN",
"gate": "tag_drift",
"trigger": "packages_added",
"params": [],
"id": "1ba3461f-b9db-4a6c-ac88-329d38e08df5"
}
Trigger: packages_removed
This trigger warns if a package was deleted from the SBOM.
Parameters
Optional parameter: “package_type”
Example
Raise a warning if packages were deleted.
{
"action": "WARN",
"gate": "tag_drift",
"trigger": "packages_removed",
"params": [],
"id": "de05d77b-1f93-4df4-a65d-57d9042b1f3a"
}
Trigger: packages_modified
This trigger warns if a package was changed in the SBOM.
Parameters
Optional parameter: “package_type”
Example
Raise a warning if packages were changed.
{
"action": "WARN",
"gate": "tag_drift",
"trigger": "packages_modified",
"params": [],
"id": "1168b0ac-df6c-4715-8077-2cb3e016cf63"
}