anchore / anchore-engine Goto Github PK

The version comparison for alpine packages can cause incorrect results when comparing versions that sort differently lexicographically from semantically.

APK version formats described here: apk version.c

I am getting the following error:

anchore-cli image list
Error: could not access anchore service

I did:
export ANCHORE_CLI_URL=http://localhost:8228/ and also created a new environment variable for username and password (different from the one present in my config.yaml under "anchoreio>anchorecli>auth")

Also, i do not have root privileges, so i have created aevolume and anchore-cli under $HOME

User downloaded policy item from anchore.io and added to engine through the cli (policy add)

The policy item only had the policy check no mappings etc.
This should not import but instead return an error.

Is this a request for help?:

Yes

Is this a BUG REPORT or a FEATURE REQUEST? (choose one):

FEATURE REQUEST

Version of Anchore Engine and Anchore CLI if applicable:

latest

What I want:

I want to be able to turn off the feed_sync functionality but retain the rest of the features provided by the policy_engine service. I see in the code to do that you can change this line:

from True to False (untested, but in my head I think that's what should happen). Would it be possible to move this option into the config.yaml file rather than hard coded?

Is there a way to get the engine to retry analysis for things with status analysis_failed ?

Use case: User has MiTM proxy doing SSL stripping & resigning for their own security and inspection./

We need to support the ability for user to pass PEM files and automate the running on update-ca-trust.

The symptom appears as an image being successfully added (showing digest X) but then failing to analyze, with a log on the worker ultimately showing:

[ERROR] problem analyzing image - exception: failed to download, unpack, analyze, and generate image export - exception: failed to pull image ......... : manifest unknown: manifest unknown" 

I've confirmed that the manifest calculation is resulting in a different digest than is reported by the 'Digest' tag in the response header (from quay.io registry, specifically), but need to investigate why some schema v1 images are working and others are failing. Specifically, for an image that is failing, tagging the same image with a new tag is resulting in successful digest calculation, though the calculation method is the same in anchore-engine for both.

If the docker_conn and docker_conn_timeout values are set in the engine's config.yaml, they are not picked up by the analyzer service and a specific /root/.anchore/conf/config.yaml must be provided for the analyzer service to set those values as well.

The bug is that the parameters are set for the analyzer worker service process to use for the image pull, but are not passed to the internal anchore analyzer invocation and thus image lookup during analysis fails if the docker_conn is anything other than the local socket or the timeout needs to be longer during the image export.

The solution is to either set the values in the anchore analyzer config using the service config or to modify the anchore analyzer tool to pick them up as invocation parameters or from the environment. Depending on the decision we can add an issue to the anchore repository.

Is this a request for help?:

Yep

Is this a BUG REPORT or a FEATURE REQUEST? (choose one):

Feature Request

Version of Anchore Engine and Anchore CLI if applicable:

latest

What would be nice:

Is it necessary to have the full path of anchore-manager here?

I'm experimenting with putting anchore in different base images and this is a big pain. Can we remove /usr/bin and let PATH do its thing? Thanks!

I've been trying to run anchore via it's 0.1.4 helm chart https://hub.kubeapps.com/charts/stable/anchore-engine/0.1.4 on GKE with kubernetes v1.8 and v1.9.
anchore-engine-worker and postgresql pods start fine but anchore-engine-core pod fails to be ready

My guess is it's related to kubernetes/kubernetes#58720

In the logs I can see:

[service:catalog] 2018-03-21 23:51:48+0000 [-] [bootstrap] [ERROR] cannot load configuration: exception - [Errno 30] Read-only file system: '/config/host_id.json'
Traceback (most recent call last):
  File "/bin/twistd", line 11, in <module>
    load_entry_point('Twisted==17.5.0', 'console_scripts', 'twistd')()
  File "/usr/lib64/python2.7/site-packages/twisted/scripts/twistd.py", line 29, in run
    app.run(runApp, ServerOptions)
  File "/usr/lib64/python2.7/site-packages/twisted/application/app.py", line 662, in run
    runApp(config)
  File "/usr/lib64/python2.7/site-packages/twisted/scripts/twistd.py", line 25, in runApp
    _SomeApplicationRunner(config).run()
  File "/usr/lib64/python2.7/site-packages/twisted/application/app.py", line 380, in run
    self.application = self.createOrGetApplication()
  File "/usr/lib64/python2.7/site-packages/twisted/application/app.py", line 440, in createOrGetApplication
    ser = plg.makeService(self.config.subOptions)
  File "/usr/lib/python2.7/site-packages/twisted/plugins/anchore_catalog.py", line 76, in makeService
    r = anchore_engine.services.common.makeService(slist, options, bootstrap_db=True, bootstrap_users=True)
  File "/usr/lib/python2.7/site-packages/anchore_engine/services/common.py", line 315, in makeService
    raise err
IOError: [Errno 30] Read-only file system: '/config/host_id.json'
Traceback (most recent call last):
  File "/usr/bin/anchore-engine", line 128, in startup_service
    raise Exception("process exited: " + str(rc))
Exception: process exited: 1

We started using anchore for scanning images, when we trigger 10 jobs for scanning images, it going to 30 mins or more. Documentation say it is possible can you let us know how to scale up the analyzer.
https://anchore.freshdesk.com/support/solutions/articles/36000020643-analyzing-images

Is this a BUG REPORT or a FEATURE REQUEST? (choose one):
Feature request

What happened:
When using swagger-codegen to generate a Go api, it fails when using the API since the date (for the anchore_image at least) is in ISO format, and not in RFC3339 as swagger would say.

parsing time ""2018-05-05T18:14:34"" as ""2006-01-02T15:04:05Z07:00"": cannot parse """ as "Z07:00"

What did you expect to happen:
Have RFC3339 date times.
I think it would be enough just to add a Z at the end of the datetimes.

Is this a request for help?:

--- YES

Is this a BUG REPORT or a FEATURE REQUEST? (choose one):
--- BUG or .. NOT permited for unregistered user.

--> anchore-engine, Version: 0.2.1
--> docker image ID of anchore engine is 6eafdab1ce30

What happened:
After add image to anchore, stayed 'not_analyzed' state for a long time.
When I checked system status, 'policy_engine' repeated 'up' and 'down'.

What did you expect to happen:

Any relevant log output from /var/log/anchore:

anchore-engine_1 | [service:policy_engine] 2018-05-17 06:34:26+0000 [-] [bootstrap] [WARNING] no webhooks defined in configuration file - notifications will be disabled
anchore-engine_1 | [service:policy_engine] 2018-05-17 06:34:26+0000 [-] [bootstrap] [INFO] initializing database
anchore-db_1 | WARNING: there is no transaction in progress
anchore-db_1 | WARNING: there is no transaction in progress
anchore-engine_1 | [service:policy_engine] 2018-05-17 06:34:27+0000 [-] [bootstrap] [INFO] Registration complete.
anchore-engine_1 | [service:policy_engine] 2018-05-17 06:34:27+0000 [-] [bootstrap] [INFO] Checking feeds client credentials
anchore-db_1 | WARNING: there is no transaction in progress
anchore-db_1 | WARNING: there is no transaction in progress
anchore-db_1 | WARNING: there is no transaction in progress
anchore-db_1 | WARNING: there is no transaction in progress
anchore-db_1 | WARNING: there is no transaction in progress
anchore-db_1 | WARNING: there is no transaction in progress
anchore-db_1 | WARNING: there is no transaction in progress
anchore-db_1 | WARNING: there is no transaction in progress
anchore-db_1 | WARNING: there is no transaction in progress
anchore-engine_1 | [service:policy_engine] 2018-05-17 06:34:27+0000 [-] [bootstrap] [ERROR] Preflight checks failed with error: 403 Client Error: Forbidden for url: https://ancho.re/v1/account/users/[email protected]. Aborting service startup

What docker images are you using:
anchore-engine:
image: docker.io/anchore/anchore-engine:latest

anchore-db:
image: "postgres:9"

How to reproduce the issue:

Anything else we need to know:
In a 'Anchore Service Configuration File' notice that Anchore's feed service uses anonymous access.
Should I have a account for using feeds? or Should I missed something?

I was browsing through the codebase and found this feature where manifest.mf files are scanned for data. Not all Java libraries add these metadata. However, any library packaged with Apache Maven tends to include a file named pom.properties (generally inside META-INF/maven/groupId/artifactId/pom.properties) which has the name and version info data. This is also generally more reliable than the manifest file due to, once again, typical build tooling usage. This can be very helpful when libraries are shaded together; the manifest files may get destroyed in the process, but all the pom.properties files will safely-ish combine together (other than version number conflicts, but that's also handled by shading).

Took over a minute to complete the image list command. I had to increase the timeout on my AWS ELB for it to not 504 on me.

anchore-cli --debug --u admin --p admin --url image list 0.26s user 0.06s system 0% cpu 1:11.14 total

I plan on looking into this myself just wondering if this is a known thing on your end.

It would be nice to be able to reference an environment variable in the config.yaml, especially for sensitive data (postgres credentials).

I'd expect to be able to use the same syntax that docker-compose does, and be able support either of these:

  database:
    db_connect: '${DATABASE_URI}'
    db_connect_args:
      timeout: 120
      ssl: False
    db_pool_size: 30
    db_pool_max_overflow: 100

or

  database:
    db_connect: 'postgresql+pg8000://postgres:${DATABASE_PASSWORD}@anchore-db:5432/postgres'
    db_connect_args:
      timeout: 120
      ssl: False
    db_pool_size: 30
    db_pool_max_overflow: 100

currently, all routes to anchore-engine must be authenticated, but for integration into systems that ask for an unauthenticated route that can be pinged for very basic service up/down checks (like aws elb healthchecks for ex), it would be more convenient to have an unauthenticated route in anchore-engine that returns 200 on GET while the API service is up and running.

Anchore engine doesn't have any metrics exposed. It means that it's hard to know

• whether the service is running or not
• what's the performance of components(serve core rest APIs, do image scan on image size, etc.)

What happened:

In our environment an achore service might get exposed to clients at https://anchore-apiext.fqdn but internally the application is configured to listen on http://anchore-apiext:8080.

What did you expect to happen:

When using external_tls: true in the config.yaml I also need the services published URL in postgres to reflect https://anchore-apiext.fqdn not http://anchore-apiext:8080 as the external services cannot connect directly to http://anchore-apiext:8080.

What docker images are you using:
anchore/anchore-engine:dev 85d781a75749

How to reproduce the issue:

Create a configuration with following config.yaml

services:
  apiext:
    enabled: True
    require_auth: True
    endpoint_hostname: '${ANCHORE_APIEXT_HOSTNAME}'
    listen: '0.0.0.0'
    port: '8228'
    external_tls: true

Note the published endpoint in the database is https://anchore-apiext:8228.

Anything else we need to know:

Ideally I need something like;

Create a configuration with following config.yaml

services:
  apiext:
    enabled: True
    require_auth: True
    endpoint_hostname: '${ANCHORE_APIEXT_HOSTNAME}'
    listen: '0.0.0.0'
    port: '8228'
    external_tls: true
    external_port: 443

Is this a BUG REPORT or a FEATURE REQUEST?:
Bug report (depends how you look at it 😄 )

Version of Anchore Engine and Anchore CLI if applicable:

Name: anchore-engine
Version: 0.2.2.dev0
Summary: Anchore Engine
Home-page: http://www.anchore.com
Author: Anchore Inc.
Author-email: [email protected]
License: Apache License 2.0
Location: /usr/lib/python2.7/site-packages
Requires: Twisted, pg8000, boto3, botocore, chardet, click, clickclick, connexion, docker-py, enum34, docutils, Flask, functools32, futures, idna, inflection, itsdangerous, Jinja2, jmespath, jsonschema, MarkupSafe, pathlib, python-dateutil, PyYAML, requests, s3transfer, six, SQLAlchemy, swagger-spec-validator, typing, urllib3, watchdog, Werkzeug, passlib, prometheus-client, prometheus-flask-exporter, python-swiftclient, python-keystoneclient, pytz, anchore, certifi
Required-by: 

What happened:
PolicyEvaluation is not well defined in the swagger spec:

What did you expect to happen:
For it to be defined

Happy to do a PR but not sure of the exact fields 🙄

During image deletion from the policy engine service, if there is a problem, logging is insufficient and it appears that the handling of a non-existent image is does not return expected response codes, but instead a 500. This causes confusing responses to the user and logging is not done to help diagnose.

Version: 0.1.5

Fix:
Make deletion idempotent (204 on successful delete or no image exists).
Make not-found condition log a quick message and actual errors should be dumped to log.

Is this a request for help?:

Yes

Is this a BUG REPORT or a FEATURE REQUEST? (choose one):

BUG REPORT

Version of Anchore Engine and Anchore CLI if applicable:

latest

What happened:

It seems like anchore doesn't work with database postgres 9.4

I believe an exception gets thrown from here

Status: Downloaded newer image for postgres:9.4
Creating anchore-engine_anchore-db_1 ... done
Creating anchore-engine_anchore-engine_1 ... done
Attaching to anchore-engine_anchore-db_1, anchore-engine_anchore-engine_1
anchore-engine_1  | [MainThread] [anchore_engine.configuration.localconfig/validate_config()] [WARN] no webhooks defined in configuration file - notifications will be disabled
anchore-db_1      | LOG:  database system was interrupted; last known up at 2018-05-31 04:39:09 UTC
anchore-db_1      | LOG:  database system was not properly shut down; automatic recovery in progress
anchore-db_1      | LOG:  record with zero length at 0/16A9FC8
anchore-db_1      | LOG:  redo is not required
anchore-db_1      | LOG:  MultiXact member wraparound protections are now enabled
anchore-db_1      | LOG:  autovacuum launcher started
anchore-db_1      | LOG:  database system is ready to accept connections
anchore-db_1      | ERROR:  relation "anchore" does not exist at character 355
anchore-db_1      | STATEMENT:  SELECT anchore.service_version AS anchore_service_version, anchore.db_version AS anchore_db_version, anchore.created_at AS anchore_created_at, anchore.last_updated AS anchore_last_updated, anchore.record_state_key AS anchore_record_state_key, anchore.record_state_val AS anchore_record_state_val, anchore.scanner_version AS anchore_scanner_version
anchore-db_1      | 	FROM anchore
anchore-db_1      | 	 LIMIT $1
anchore-db_1      | WARNING:  there is no transaction in progress
anchore-engine_1  | Loading DB routines from module (anchore_engine)
anchore-engine_1  | DB Params: {"db_pool_size": 10, "db_connect": "postgresql+pg8000://postgres:mysecretpassword@anchore-db:5432/postgres", "db_connect_args": {"ssl": false}, "db_pool_max_overflow": 20}
anchore-engine_1  | DB connection configured: True
anchore-engine_1  | Attempting to connect to DB...
anchore-engine_1  | DB connection failed, retrying - exception: test connection failed - exception: (pg8000.core.InterfaceError) ('communication error', error(111, 'Connection refused'))
anchore-engine_1  | Attempting to connect to DB...
anchore-engine_1  | DB connected: True
anchore-engine_1  | Error: Cannot find existing/populated anchore DB tables in connected database - has anchore-engine initialized this DB?
anchore-engine_1  |
anchore-engine_1  | DB - exception: (pg8000.core.ProgrammingError) (u'ERROR', u'42P01', u'relation "anchore" does not exist', u'355', u'parse_relation.c', u'987', u'parserOpenTable', u'', u'') [SQL: u'SELECT anchore.service_version AS anchore_service_version, anchore.db_version AS anchore_db_version, anchore.created_at AS anchore_created_at, anchore.last_updated AS anchore_last_updated, anchore.record_state_key AS anchore_record_state_key, anchore.record_state_val AS anchore_record_state_val, anchore.scanner_version AS anchore_scanner_version \nFROM anchore \n LIMIT %s'] [parameters: (1,)]
anchore-engine_1  |
anchore-engine_anchore-engine_1 exited with code 2

Anchore-engine is not setting the JSON header when sending to webhook.

When trying to analyze images from an Azure Container registry, the anchore-engine catalog service raises an error trying to pull the manifest and returns a 404 to the user indicating that the tag cannot be analyzed or found.

Error logs indicate the system is unable to get the manifest using skopeo:

[anchore_engine.auth.skopeo_wrapper/get_image_manifest_skopeo()] [WARN] CMD failed - exception: command failed: cmd=skopeo inspect --raw --tls-verify=true --creds <redacteduser>:<redactedpassword> docker://zhillregistry1.azurecr.io/testimages:centos7 exitcode=1 stdout= stderr=time="2018-01-03T03:03:55Z" level=fatal msg="unauthorized: authentication required"

Anchore uses skopeo internally to fetch manifests and pull image layers, but skopeo fails to properly authenticate because it expects a returned bearer token to have the token content in the body as a json object with key token (e.g. {"token": "...."}) as docker hub and other registries do, but Azure returns the token with key "access_key". Docker Hub returns both token and access_token with the same content in it's token fetch response.

Azure does support Basic Auth rather than Bearer auth, but because the Azure registry service returns a Bearer challenge in the WWW-Authenticate header of an unauthenticated request, most tools (including Skopeo) detect it and attempt to retrieve a token. But, I see no existing way to force skopeo to try basic auth and either skip the preflight auth check (a GET on the base /v2/ route) or ignore the resulting WWW-Authenticate response header, so it seems best to just fix the token handling.

As a simple check I patched skopeo (patch is a simple change at https://github.com/projectatomic/skopeo/blob/master/vendor/github.com/containers/image/docker/docker_client.go#L69) and confirmed that with both Azure registry admin credentials as well as service principal credentials, the tool is able to pull the manifest and image content. As you can see that patch is actually in code that skopeo vendors in and should be patched upstream and pulled down.

Given that this issue is not directly in Anchore Engine code, this issue will serve to track any upstream PRs as well as workarounds until the issue is resolved or a good workaround is found.

Hello :-),

I use anchore engine for two days now and when i want to add an image on my machine (in local) i have this error : Error: image cannot be found/fetched from registry. I didn't create a registry, my images are stored on my machine.

I can add images that I have pulled from dockerhub, but It doesn't work from images that I have created / pulled from my private registry.

docker logs (anchore container)

[service:catalog] 2018-03-27 10:03:39+0000 [_GenericHTTPChannelProtocol,4,127.0.0.1] [PoolThread-twisted.internet.reactor-0] [anchore_engine.auth.skopeo_wrapper/get_image_manifest_skopeo()] [ERROR] command failed with exception - command failed: cmd=/bin/sh -c skopeo inspect --raw --tls-verify=false docker://docker.io/library/planningdatabase:latest exitcode=1 stdout= stderr=time="2018-03-27T10:03:39Z" level=fatal msg="errors:
[service:catalog] denied: requested access to the resource is denied
[service:catalog] unauthorized: authentication required
[service:catalog] "
[service:catalog] 2018-03-27 10:03:39+0000 [_GenericHTTPChannelProtocol,4,127.0.0.1] [PoolThread-twisted.internet.reactor-0] [anchore_engine.auth.skopeo_wrapper/get_image_manifest_skopeo()] [WARN] CMD failed - exception: command failed: cmd=/bin/sh -c skopeo inspect --raw --tls-verify=false docker://docker.io/library/planningdatabase:latest exitcode=1 stdout= stderr=time="2018-03-27T10:03:39Z" level=fatal msg="errors:
[service:catalog] denied: requested access to the resource is denied
[service:catalog] unauthorized: authentication required
[service:catalog] "
[service:catalog] 2018-03-27 10:03:39+0000 [_GenericHTTPChannelProtocol,4,127.0.0.1] [PoolThread-twisted.internet.reactor-0] [anchore_engine.auth.docker_registry/get_image_manifest()] [ERROR] could not fetch manifest/digest: no digest/manifest from skopeo
[service:catalog] 2018-03-27 10:03:39+0000 [_GenericHTTPChannelProtocol,4,127.0.0.1] [PoolThread-twisted.internet.reactor-0] [anchore_engine.auth.docker_registry/get_image_manifest()] [ERROR] could not get manifest/digest for image using any auth method: (latest):
[service:catalog] 2018-03-27 10:03:39+0000 [-] "127.0.0.1" - - [27/Mar/2018:10:03:39 +0000] "POST /v1/image?tag=planningdatabase:latest HTTP/1.1" 404 192 "-" "python-requests/2.17.3"

my docker compose:

version: '2'
services:
anchore-engine:
#image: "anchore-engine"
image: docker.io/anchore/anchore-engine:latest
privileged: true
environment:
- http_proxy=http://myproxy
- https_proxy=http://myproxy
- no_proxy=/var/run/docker.sock,,localhost,127.0.0.1
depends_on:
- anchore-db
ports:
- "8228:8228"
- "8338:8338"
volumes:
- /root/aevolume/config:/config/:Z
#- /var/run/docker.sock:/var/run/docker.sock
logging:
driver: "json-file"
options:
max-size: 100m
anchore-db:
image: "postgres:9"
environment:
- http_proxy=http://myproxy
- https_proxy=http://myproxy
- no_proxy=/var/run/docker.sock,,localhost,127.0.0.1
volumes:
- /root/aevolume/db/:/var/lib/postgresql/data/pgdata/:Z
environment:
- POSTGRES_PASSWORD=mysecretpassword
- PGDATA=/var/lib/postgresql/data/pgdata/
logging:
driver: "json-file"
options:
max-size: 100m
#uncomment to expose a port to allow direct/external access to the DB, for debugging
#ports:
# - "2345:5432"

if someone can help me ^^

Hi Guys,

I think there is an error with the Dockerfile parsing when you use multiline.

2017-11-02 13:46:00+0000 [-] Traceback (most recent call last):
2017-11-02 13:46:00+0000 [-]   File "/usr/lib/python2.7/site-packages/anchore_engine/services/policy_engine/api/controllers/synchronous_operations.py", line 227, in check_user_image_inline
2017-11-02 13:46:00+0000 [-]     eval_result = executable_bundle.execute(img_obj, tag, ExecutionContext(db_session=db, configuration={}))
2017-11-02 13:46:00+0000 [-]   File "/usr/lib/python2.7/site-packages/anchore_engine/services/policy_engine/engine/policy/bundles.py", line 1074, in execute
2017-11-02 13:46:00+0000 [-]     errors, policy_decision = evaluated_policy.execute(image_obj=image_object, context=context)
2017-11-02 13:46:00+0000 [-]   File "/usr/lib/python2.7/site-packages/anchore_engine/services/policy_engine/engine/policy/bundles.py", line 510, in execute
2017-11-02 13:46:00+0000 [-]     exec_context = gate_obj.prepare_context(image_obj, context)
2017-11-02 13:46:00+0000 [-]   File "/usr/lib/python2.7/site-packages/anchore_engine/services/policy_engine/engine/policy/gates/dockerfile.py", line 359, in prepare_context
2017-11-02 13:46:00+0000 [-]     directive, remainder = line.split(' ', 1)
2017-11-02 13:46:00+0000 [-] ValueError: need more than 1 value to unpack

Sometimes there are no directive

RUN set -ex; \
    BUILD_DEPS="gcc libffi-dev libxml2-dev mariadb-dev musl-dev openssl-dev xmlsec-dev"; \
    apk add --no-cache --virtual .build-deps $BUILD_DEPS; \
    pip install --no-cache-dir --cert /etc/ssl/certs/ca-certificates.crt --requirement requirements.txt; \
    rm -r requirements.txt; \
    EXTRA_RUN_DEPS="$( \
        scanelf --needed --nobanner --recursive /usr/local \
            | awk '{ gsub(/,/, "\nso:", $2); print "so:" $2 }' \
            | sort -u \
            | xargs -r apk info --installed \
            | sort -u \
    )"; \
    apk add --no-cache --virtual .run-deps $EXTRA_RUN_DEPS; \
    apk del .build-deps

You should handle \ here https://github.com/anchore/anchore-engine/blob/master/anchore_engine/services/policy_engine/engine/policy/gates/dockerfile.py#L358

Thanks !

The image analysis fails at this particular point... I have debug turned on... here's the specific error....
.2018-01-19 12:53:55+0000 [-] [Thread-74] [anchore_engine.services.analyzer/process_analyzer_job()] [DEBUG] policy engine request: {'fetch_url': 'catalog://admin/analysis_data/sha256:b5611db8560bb3a95294191613c4ea428342ae857ecf02e9b670194e795c636a', 'image_id': u'b0dbdee9315add8d7b2ee9730a6a9d5f6f0f4cfdbae5a0c0863cc6064cf27761', 'user_id': u'admin'} 2018-01-19 12:53:55+0000 [-] Traceback (most recent call last): 2018-01-19 12:53:55+0000 [-] File "/usr/lib/python2.7/site-packages/anchore_engine/services/analyzer/__init__.py", line 325, in process_analyzer_job 2018-01-19 12:53:55+0000 [-] raise Exception("adding image to policy-engine failed - exception: " + str(err)) 2018-01-19 12:53:55+0000 [-] Exception: adding image to policy-engine failed - exception: HTTPConnectionPool(host=u'localhost', port=8087): Max retries exceeded with url: /v1/images (Caused by NewConnectionError('<urllib3.connection.HTTPConnection object at 0x7fb888368cd0>: Failed to establish a new connection: [Errno 111] Connection refused',)) 2018-01-19 12:53:55+0000 [-] [Thread-74] [anchore_engine.services.analyzer/process_analyzer_job()] [ERROR] problem analyzing image - exception: adding image to policy-engine failed - exception: HTTPConnectionPool(host=u'localhost', port=8087): Max retries exceeded with url: /v1/images (Caused by NewConnectionError('<urllib3.connection.HTTPConnection object at 0x7fb888368cd0>: Failed to establish a new connection: [Errno 111] Connection refused',))

An issue has been reported which effects all versions of anchore-engine from 0.1.1 onward, where an authenticated user can construct input to the image add and repo add operations that is ultimately passed through to a shellout command on the anchore-engine host. This authenticated user input can be constructed in a way that results in an arbitrary command being executed within in the anchore-engine container. The flaw can only be exploited via an authenticated call to anchore-engine (image add, repo add).

A fix has been developed and is being reviewed, where the solution entails - input validation code in the parse_dockerimage_string() routine (for all places where docker image tag/digest/id strings are being ingressed), sanitized internal url encoding between the API and catalog services, and as a final-check at shellout execution time where commands are checked for malicious input in the run_command_list() routine.

We intend to release a new version of anchore-engine (0.2.1) with the fix shortly, and recommend to users that an upgrade be scheduled as soon as possible. Updates will be posted to this ticket as the fix, details, and release becomes available.

I'm trying to analyze images, and the analysis failed. I'm suspecting networking issues, as I'm on an unstable network right now - but I would like to know for sure. By looking at the logs, I could not find any error that could explain why the analysis failed. Where else can I look? I'm running anchore using docker-compose.

BUG, Version is 0.2.1

What happened:

Setup for TLS never seems to "kick in". Following is config.yaml for this:

  apiext:
    enabled: True
    require_auth: True
    endpoint_hostname: '${ANCHORE_HOST_ID}'
    listen: '0.0.0.0'
    port: 8228
    ssl_enable: True
    ssl_cert: '/Users/m0k00lj/Images/nchore/aevolume/config/anchore.crt'
    ssl_key: '/Users/m0k00lj/Images/nchore/aevolume/config/anchore.key'

Notice that I purposely mispelled "anchore" in middle of key paths above. This isn't even recognized by anchore engine and startup occurs as usual...why? No fileNotFound exception, etc. Also when I mismatch key/cert there's no error about them not matching...it's as if entire ssl setup is somehow ignored.

In logs I see a single line: anchore-engine_1 | [service:api] 2018-06-05 20:29:04+0000 [-] Site (TLS) starting on 8228

Other than above I see no indication of issues with passing in bad keypaths or mismatched keys. This almost implies my yaml category/properties are bad.

What did you expect to happen:

Startup with TLS1.3 (or perhaps v1.2 cause python) protocol active.

Any relevant log output from /var/log/anchore:

In logs I see a single line: anchore-engine_1 | [service:api] 2018-06-05 20:29:04+0000 [-] Site (TLS) starting on 8228

Nothing other than this. I've grep'd logs for https, ssl, etc. and other than https://ancho.re references that's it.

Here is output from openssl handshake:

m-c02w20yrhtdg:config m0k00lj$ openssl s_client -showcerts -debug -msg -connect localhost:8228
CONNECTED(00000005)
write to 0x7f973241d490 [0x7f973280d000] (318 bytes => 318 (0x13E))
0000 - 16 03 01 01 39 01 00 01-35 03 03 ad a2 d2 b2 97 ....9...5.......
0010 - 11 55 3d 5a d2 92 c9 54-10 47 d5 70 88 f5 3c 58 .U=Z...T.G.p..<X
0020 - 79 73 21 32 71 75 43 87-00 76 19 00 00 98 cc 14 ys!2quC..v......
0030 - cc 13 cc 15 c0 30 c0 2c-c0 28 c0 24 c0 14 c0 0a .....0.,.(.$....
0040 - 00 a3 00 9f 00 6b 00 6a-00 39 00 38 ff 85 00 c4 .....k.j.9.8....
0050 - 00 c3 00 88 00 87 00 81-c0 32 c0 2e c0 2a c0 26 .........2...*.&
0060 - c0 0f c0 05 00 9d 00 3d-00 35 00 c0 00 84 c0 2f .......=.5...../
0070 - c0 2b c0 27 c0 23 c0 13-c0 09 00 a2 00 9e 00 67 .+.'.#.........g
0080 - 00 40 00 33 00 32 00 be-00 bd 00 45 00 44 c0 31 [email protected]
0090 - c0 2d c0 29 c0 25 c0 0e-c0 04 00 9c 00 3c 00 2f .-.).%.......<./
00a0 - 00 ba 00 41 c0 11 c0 07-c0 0c c0 02 00 05 00 04 ...A............
00b0 - c0 12 c0 08 00 16 00 13-c0 0d c0 03 00 0a 00 15 ................
00c0 - 00 12 00 09 00 ff 01 00-00 74 00 0b 00 04 03 00 .........t......
00d0 - 01 02 00 0a 00 3a 00 38-00 0e 00 0d 00 19 00 1c .....:.8........
00e0 - 00 0b 00 0c 00 1b 00 18-00 09 00 0a 00 1a 00 16 ................
00f0 - 00 17 00 08 00 06 00 07-00 14 00 15 00 04 00 05 ................
0100 - 00 12 00 13 00 01 00 02-00 03 00 0f 00 10 00 11 ................
0110 - 00 23 00 00 00 0d 00 26-00 24 06 01 06 02 06 03 .#.....&.$......
0120 - ef ef 05 01 05 02 05 03-04 01 04 02 04 03 ee ee ................
0130 - ed ed 03 01 03 02 03 03-02 01 02 02 02 03 ..............

TLS 1.2 Handshake [length 0139], ClientHello
01 00 01 35 03 03 ad a2 d2 b2 97 11 55 3d 5a d2
92 c9 54 10 47 d5 70 88 f5 3c 58 79 73 21 32 71
75 43 87 00 76 19 00 00 98 cc 14 cc 13 cc 15 c0
30 c0 2c c0 28 c0 24 c0 14 c0 0a 00 a3 00 9f 00
6b 00 6a 00 39 00 38 ff 85 00 c4 00 c3 00 88 00
87 00 81 c0 32 c0 2e c0 2a c0 26 c0 0f c0 05 00
9d 00 3d 00 35 00 c0 00 84 c0 2f c0 2b c0 27 c0
23 c0 13 c0 09 00 a2 00 9e 00 67 00 40 00 33 00
32 00 be 00 bd 00 45 00 44 c0 31 c0 2d c0 29 c0
25 c0 0e c0 04 00 9c 00 3c 00 2f 00 ba 00 41 c0
11 c0 07 c0 0c c0 02 00 05 00 04 c0 12 c0 08 00
16 00 13 c0 0d c0 03 00 0a 00 15 00 12 00 09 00
ff 01 00 00 74 00 0b 00 04 03 00 01 02 00 0a 00
3a 00 38 00 0e 00 0d 00 19 00 1c 00 0b 00 0c 00
1b 00 18 00 09 00 0a 00 1a 00 16 00 17 00 08 00
06 00 07 00 14 00 15 00 04 00 05 00 12 00 13 00
01 00 02 00 03 00 0f 00 10 00 11 00 23 00 00 00
0d 00 26 00 24 06 01 06 02 06 03 ef ef 05 01 05
02 05 03 04 01 04 02 04 03 ee ee ed ed 03 01 03
02 03 03 02 01 02 02 02 03
read from 0x7f973241d490 [0x7f9732812600] (7 bytes => 7 (0x7))
0000 - 15 03 03 00 02 02 28 ......(
<<< TLS 1.2 Alert [length 0002], fatal handshake_failure
02 28
140735679509384:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure:/BuildRoot/Library/Caches/com.apple.xbs/Sources/libressl/libressl-22/libressl/ssl/s23_clnt.c:541:

no peer certificate available

No client certificate CA names sent

SSL handshake has read 7 bytes and written 318 bytes

New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated

What docker images are you using:

The one generated from your docker-compose file.

How to reproduce the issue:

Enable TLS for apiext and specify good (or bad!) filepaths.

Anything else we need to know:

We're using python 2.7.x on both mac and linux systems hitting this issue.

on the client, the error manifests as a confusing message from flask:

# curl -u admin:foobar -XDELETE -H 'content-type: application/json' 'http://localhost:8228/v1/images/by_id/3fd9065eaf02feaf94d68376da52541925650b81698c53c6824d92ff63f98353?force=false'
{
  "detail": "The server encountered an internal error and was unable to complete your request.  Either the server is overloaded or there is an error in the application.", 
  "status": 500, 
  "title": "Internal Server Error", 
  "type": "about:blank"
}

the issue is that the invoked function delete_image_by_imageId() is being wrapped by a prometheus metric routine which is being strict about passed in parameters. In this case, the function isn't specifying force= as a kwarg, and is bailing with the following exception in the logs:

2018-06-07 01:27:05+0000 [wsgi] [2018-06-07 01:27:05,767] ERROR in app: Exception on /images/by_id/3fd9065eaf02feaf94d68376da52541925650b81698c53c6824d92ff63f98353 [DELETE]
	Traceback (most recent call last):
	  File "/usr/lib/python2.7/site-packages/flask/app.py", line 1982, in wsgi_app
	    response = self.full_dispatch_request()
	  File "/usr/lib/python2.7/site-packages/flask/app.py", line 1614, in full_dispatch_request
	    rv = self.handle_user_exception(e)
	  File "/usr/lib/python2.7/site-packages/flask/app.py", line 1517, in handle_user_exception
	    reraise(exc_type, exc_value, tb)
	  File "/usr/lib/python2.7/site-packages/flask/app.py", line 1612, in full_dispatch_request
	    rv = self.dispatch_request()
	  File "/usr/lib/python2.7/site-packages/flask/app.py", line 1598, in dispatch_request
	    return self.view_functions[rule.endpoint](**req.view_args)
	  File "/usr/lib/python2.7/site-packages/connexion/decorators/decorator.py", line 66, in wrapper
	    response = function(request)
	  File "/usr/lib/python2.7/site-packages/connexion/decorators/validation.py", line 293, in wrapper
	    return function(request)
	  File "/usr/lib/python2.7/site-packages/connexion/decorators/decorator.py", line 42, in wrapper
	    response = function(request)
	  File "/usr/lib/python2.7/site-packages/connexion/decorators/parameter.py", line 195, in wrapper
	    return function(**kwargs)
	  File "/usr/lib/python2.7/site-packages/anchore_engine/subsys/metrics.py", line 53, in func
	    return f(*args, **kwargs)
	TypeError: delete_image_by_imageId() got an unexpected keyword argument 'force'
	

The fix is to properly define the function with the force= in its definition.

Other delete route (the non by_id routes used by the CLI) are unaffected.

Is this a request for help?: Yes

Is this a BUG REPORT or a FEATURE REQUEST? (choose one): BUG REPORT

Steps to Install Anchore suite
Created Postgres PAAS on Azure
Configured Postgres DB on config yamls
Installed anchore core engine and analyzer as pods on k8s cluster.

Installed Anchore CLI on k8 cluster master node.

anchore-cli system status
Service kubernetes_webhook (dockerhostid-xyz, http://localhost:8338): up
Service analyzer (dockerhostid-xyz, N/A): up
Service policy_engine (dockerhostid-xyz, http://localhost:8087): up
Service catalog (dockerhostid-xyz, http://localhost:8082): up
Service apiext (dockerhostid-xyz, http://localhost:8228): up
Service simplequeue (dockerhostid-xyz, http://localhost:8083): up

Engine Status: all_up

anchore-cli --version
anchore-cli, version 0.1.9

I added a azure container registry

anchore-cli registry list
Registry                           Type             User
buycscregstg.azurecr.io            docker_v2       <<user>>

When i try to add image using cli.. got below error:

anchore-cli image add buycscregstg.azurecr.io/buy/centos7:7.4
Error: image cannot be found/fetched from registry
HTTP Code: 404

In Anchore core engine logs:

[service:kubernetes-webhook] 2018-04-06 17:24:45+0000 [-] "127.0.0.1" - - [06/Apr/2018:17:24:44 +0000] "GET /v1/status HTTP/1.1" 200 61 "-" "python-requests/2.17.3"
[service:policy-engine] 2018-04-06 17:24:45+0000 [-] "127.0.0.1" - - [06/Apr/2018:17:24:44 +0000] "GET /v1/status HTTP/1.1" 200 61 "-" "python-requests/2.17.3"
[service:api] 2018-04-06 17:24:45+0000 [-] "127.0.0.1" - - [06/Apr/2018:17:24:44 +0000] "GET /v1/status HTTP/1.1" 200 110 "-" "python-requests/2.17.3"
[service:simplequeue] 2018-04-06 17:24:45+0000 [-] "127.0.0.1" - - [06/Apr/2018:17:24:44 +0000] "GET /v1/status HTTP/1.1" 200 404 "-" "python-requests/2.17.3"
[service:catalog] 2018-04-06 17:24:47+0000 [-] "127.0.0.1" - - [06/Apr/2018:17:24:46 +0000] "GET /v1/system/services/simplequeue HTTP/1.1" 200 721 "-" "python-requests/2.17.3"
[service:simplequeue] 2018-04-06 17:24:47+0000 [-] "127.0.0.1" - - [06/Apr/2018:17:24:46 +0000] "GET /v1/queues/policy_eval/qlen HTTP/1.1" 200 4 "-" "python-requests/2.17.3"
[service:simplequeue] 2018-04-06 17:24:47+0000 [-] "127.0.0.1" - - [06/Apr/2018:17:24:46 +0000] "GET /v1/queues/tag_update/qlen HTTP/1.1" 200 4 "-" "python-requests/2.17.3"
[service:simplequeue] 2018-04-06 17:24:47+0000 [-] "127.0.0.1" - - [06/Apr/2018:17:24:46 +0000] "GET /v1/queues/vuln_update/qlen HTTP/1.1" 200 4 "-" "python-requests/2.17.3"
[service:simplequeue] 2018-04-06 17:24:47+0000 [-] "127.0.0.1" - - [06/Apr/2018:17:24:46 +0000] "GET /v1/queues/repo_update/qlen HTTP/1.1" 200 4 "-" "python-requests/2.17.3"
[service:simplequeue] 2018-04-06 17:24:47+0000 [-] "127.0.0.1" - - [06/Apr/2018:17:24:46 +0000] "GET /v1/queues/analysis_update/qlen HTTP/1.1" 200 4 "-" "python-requests/2.17.3"
[service:simplequeue] 2018-04-06 17:24:47+0000 [-] "127.0.0.1" - - [06/Apr/2018:17:24:46 +0000] "GET /v1/queues/error_event/qlen HTTP/1.1" 200 4 "-" "python-requests/2.17.3"
[service:api] 2018-04-06 17:24:53+0000 [-] "10.247.5.201" - - [06/Apr/2018:17:24:52 +0000] "GET /v1 HTTP/1.1" 200 - "-" "python-requests/2.17.3"
[service:api] 2018-04-06 17:24:53+0000 [-] "10.247.5.201" - - [06/Apr/2018:17:24:53 +0000] "POST /v1/images?autosubscribe=True HTTP/1.1" 404 189 "-" "python-requests/2.17.3"
[service:catalog] 2018-04-06 17:24:53+0000 [_GenericHTTPChannelProtocol,61,127.0.0.1] [PoolThread-twisted.internet.reactor-0] [anchore_engine.auth.skopeo_wrapper/get_image_manifest_skopeo()] [ERROR] command failed with exception - command failed: cmd=/bin/sh -c skopeo inspect --raw --tls-verify=true --creds "${SKOPUSER}":"${SKOPPASS}" docker://buycscregstg.azurecr.io/buy/centos7:7.4 exitcode=1 stdout= stderr=time="2018-04-06T17:24:53Z" level=fatal msg="unauthorized: authentication required"
[service:catalog] 2018-04-06 17:24:53+0000 [_GenericHTTPChannelProtocol,61,127.0.0.1] [PoolThread-twisted.internet.reactor-0] [anchore_engine.auth.skopeo_wrapper/get_image_manifest_skopeo()] [WARN] CMD failed - exception: command failed: cmd=/bin/sh -c skopeo inspect --raw --tls-verify=true --creds "${SKOPUSER}":"${SKOPPASS}" docker://buycscregstg.azurecr.io/buy/centos7:7.4 exitcode=1 stdout= stderr=time="2018-04-06T17:24:53Z" level=fatal msg="unauthorized: authentication required"
[service:catalog] 2018-04-06 17:24:53+0000 [_GenericHTTPChannelProtocol,61,127.0.0.1] [PoolThread-twisted.internet.reactor-0] [anchore_engine.auth.docker_registry/get_image_manifest()] [ERROR] could not fetch manifest/digest: no digest/manifest from skopeo
[service:catalog] 2018-04-06 17:24:53+0000 [_GenericHTTPChannelProtocol,61,127.0.0.1] [PoolThread-twisted.internet.reactor-0] [anchore_engine.auth.docker_registry/get_image_manifest()] [ERROR] could not get manifest/digest for image using any auth method: (7.4):
[service:catalog] 2018-04-06 17:24:53+0000 [-] "127.0.0.1" - - [06/Apr/2018:17:24:53 +0000] "POST /v1/image?tag=buycscregstg.azurecr.io/buy/centos7:7.4 HTTP/1.1" 404 189 "-" "python-requests/2.17.3"
[service:kubernetes-webhook] 2018-04-06 17:25:04+0000 [-] "127.0.0.1" - - [06/Apr/2018:17:25:03 +0000] "GET /v1/status HTTP/1.1" 200 61 "-" "python-requests/2.17.3"
[service:policy-engine] 2018-04-06 17:25:04+0000 [-] "127.0.0.1" - - [06/Apr/2018:17:25:03 +0000] "GET /v1/status HTTP/1.1" 200 61 "-" "python-requests/2.17.3"

Hi Anchore Team,
I try to analyze images from a private registry. I added it to anchore using

anchore-cli registry add myregistry:443 foo bar --insecure

But still I get an error that anchore cannot get the image and the analysis fails:

[service:worker] 2018-02-07 15:04:00+0000 [-] [Thread-1605] [anchore_engine.auth.docker_registry/get_authenticated_cli()] [DEBUG] DOCKER CLI: making new auth CLI for user/registry: foo / myregistry:443
[service:worker] 2018-02-07 15:04:00+0000 [-] [Thread-1605] [anchore_engine.auth.docker_registry/get_authenticated_cli()] [DEBUG] DOCKER CLI: making auth CLI
[service:worker] 2018-02-07 15:04:00+0000 [-] [Thread-1605] [anchore_engine.auth.docker_registry/get_authenticated_cli()] [ERROR] DOCKER CLI auth err: 500 Server Error: Internal Server Error ("{"message":"Get https://myregistry:443/v1/users/: x509: certificate signed by unknown authority"}")
[service:worker] 2018-02-07 15:04:00+0000 [-] [Thread-1605] [anchore_engine.auth.docker_registry/get_authenticated_cli()] [ERROR] DOCKER CLI: unable to get docker cli - exception: 500 Server Error: Internal Server Error ("{"message":"Get https://myregistry:443/v1/users/: x509: certificate signed by unknown authority"}")
[service:worker] 2018-02-07 15:04:00+0000 [-] [Thread-1605] [anchore_engine.services.analyzer/perform_analyze_localanchore()] [ERROR] error on pull: 500 Server Error: Internal Server Error ("{"message":"Get https://myregistry:443/v1/users/: x509: certificate signed by unknown authority"}")
[service:worker] 2018-02-07 15:04:00+0000 [-] Traceback (most recent call last):
[service:worker] 2018-02-07 15:04:00+0000 [-]   File "/usr/lib/python2.7/site-packages/anchore_engine/services/analyzer/__init__.py", line 257, in process_analyzer_job
[service:worker] 2018-02-07 15:04:00+0000 [-]     image_data = perform_analyze(userId, manifest, image_record, registry_creds)
[service:worker] 2018-02-07 15:04:00+0000 [-]   File "/usr/lib/python2.7/site-packages/anchore_engine/services/analyzer/__init__.py", line 105, in perform_analyze
[service:worker] 2018-02-07 15:04:00+0000 [-]     return(perform_analyze_localanchore(userId, manifest, image_record, registry_creds))
[service:worker] 2018-02-07 15:04:00+0000 [-]   File "/usr/lib/python2.7/site-packages/anchore_engine/services/analyzer/__init__.py", line 179, in perform_analyze_localanchore
[service:worker] 2018-02-07 15:04:00+0000 [-]     raise err
[service:worker] 2018-02-07 15:04:00+0000 [-] APIError: 500 Server Error: Internal Server Error ("{"message":"Get https://myregistry:443/v1/users/: x509: certificate signed by unknown authority"}")
[service:worker] 2018-02-07 15:04:00+0000 [-] [Thread-1605] [anchore_engine.services.analyzer/process_analyzer_job()] [ERROR] problem analyzing image - exception: 500 Server Error: Internal Server Error ("{"message":"Get https://myregistry:443/v1/users/: x509: certificate signed by unknown authority"}")

How do I fix this?

hitting the ...8228/v1/ui/ route is bringing up the swagger UI, but the paths are not respecting the relative API version prefix that is being applied by twistd (introduced when adding the unauthenticated /health route).

NOTE: hitting the ui route without a trailing '/' is also failing, but is a appears to be a limitation of the swagger UI module itself (as the same behavior presents on other flask/connexion services in the system) - behavior is that one must use the the trailing '/' to get the UI module to load

This issue is to track a combination of behaviors in Anchore Engine and some load balancers that combines to cause a bug, though behavior of each is not really a bug in isolation.

Anchore Engine's API uses a body in some GET requests to pass filter information, such as tag or repository name that is not URL friendly. An example in the CLI command is:
anchore-cli image vuln docker.io/library/debian:latest

which results in an initial GET request to the API to do a tag lookup to find the image digest for that tag:

#> anchore-cli --debug image vuln docker.io/library/alpine:latest
DEBUG:urllib3.connectionpool:Starting new HTTP connection (1): localhost
DEBUG:urllib3.connectionpool:http://localhost:80 "GET /v1 HTTP/1.1" 200 0
DEBUG:anchorecli.clients.apiexternal:GET url=http://localhost/v1/images?history=false
DEBUG:anchorecli.clients.apiexternal:GET payload={"tag": "docker.io/library/alpine:latest"}
DEBUG:anchorecli.clients.apiexternal:GET insecure=True
DEBUG:urllib3.connectionpool:Starting new HTTP connection (1): localhost
DEBUG:urllib3.connectionpool:http://localhost:80 "GET /v1/images?history=false HTTP/1.1" 200 1480
DEBUG:anchorecli.clients.apiexternal:GET url=http://localhost/v1/images/sha256:8c03bb07a531c53ad7d0f6e7041b64d81f99c6e493cb39abba56d956b40eacbc/vuln?vendor_only=True
DEBUG:urllib3.connectionpool:Starting new HTTP connection (1): localhost
DEBUG:urllib3.connectionpool:http://localhost:80 "GET /v1/images/sha256:8c03bb07a531c53ad7d0f6e7041b64d81f99c6e493cb39abba56d956b40eacbc/vuln?vendor_only=True HTTP/1.1" 200 11
DEBUG:anchorecli.cli.utils:fetched httpcode from response: 200
os: available

Some LBs, notably GCP/GKE ALBs used for kubernetes Ingress controllers, will reject a body on a GET request, and thus not allowing the CLI and API to work as expected.

ANCHORE_CLI_URL=http://XX.XX.XX.XX/v1 anchore-cli --debug image vuln docker.io/alpine:latest os
DEBUG:urllib3.connectionpool:Starting new HTTP connection (1): XX.XX.XX.XX
DEBUG:urllib3.connectionpool:http://XX.XX.XX.XX:80 "GET /v1 HTTP/1.1" 200 0
DEBUG:anchorecli.clients.apiexternal:GET url=http://XX.XX.XX.XX/v1/images?history=false
DEBUG:anchorecli.clients.apiexternal:GET payload={"tag": "docker.io/alpine:latest"}
DEBUG:anchorecli.clients.apiexternal:GET insecure=True
DEBUG:urllib3.connectionpool:Starting new HTTP connection (1): XX.XX.XX.XX
DEBUG:urllib3.connectionpool:http://XX.XX.XX.XX:80 "GET /v1/images?history=false HTTP/1.1" 400 1555
Got response: <Response [400]>
Error: cannot use input image string (no discovered imageDigest): tag

The 400 response from the GCP LB (for example) is:

#> curl -d '{"tag":"docker.io/library/alpine:latest"}' -X GET http://XX.XX.XX.XX/v1/images?history=false
<!DOCTYPE html>
<html lang=en>
  <meta charset=utf-8>
  <meta name=viewport content="initial-scale=1, minimum-scale=1, width=device-width">
  <title>Error 400 (Bad Request)!!1</title>
  <style>
    *{margin:0;padding:0}html,code{font:15px/22px arial,sans-serif}html{background:#fff;color:#222;padding:15px}body{margin:7% auto 0;max-width:390px;min-height:180px;padding:30px 0 15px}* > body{background:url(//www.google.com/images/errors/robot.png) 100% 5px no-repeat;padding-right:205px}p{margin:11px 0 22px;overflow:hidden}ins{color:#777;text-decoration:none}a img{border:0}@media screen and (max-width:772px){body{background:none;margin-top:0;max-width:none;padding-right:0}}#logo{background:url(//www.google.com/images/branding/googlelogo/1x/googlelogo_color_150x54dp.png) no-repeat;margin-left:-5px}@media only screen and (min-resolution:192dpi){#logo{background:url(//www.google.com/images/branding/googlelogo/2x/googlelogo_color_150x54dp.png) no-repeat 0% 0%/100% 100%;-moz-border-image:url(//www.google.com/images/branding/googlelogo/2x/googlelogo_color_150x54dp.png) 0}}@media only screen and (-webkit-min-device-pixel-ratio:2){#logo{background:url(//www.google.com/images/branding/googlelogo/2x/googlelogo_color_150x54dp.png) no-repeat;-webkit-background-size:100% 100%}}#logo{display:inline-block;height:54px;width:150px}
  </style>
  <a href=//www.google.com/><span id=logo aria-label=Google></span></a>
  <p><b>400.</b> <ins>That’s an error.</ins>
  <p>Your client has issued a malformed or illegal request.  <ins>That’s all we know.</ins>

This ticket is to track work on migrating those parameters from the body of the GET request to query string parameters to avoid this issue.

The issue is that the last_updated timestamp is against the db record itself, rather than triggering off of the policy bundle content, so that even if a new bundle content is synced/loaded (but the ID does not update), the last_updated timestamp reported back through the API/CLI won't reflect this change

The fix will be to instead use the last_updated timestamp on the archive document itself (which is updated any time there is a 'put' that overwrites the old bundle content), which more accurately reflects when bundle content has been updated.

Hi anchore team,

I wanted to get started with the webhooks but somehow it doesn't work. I used webhook.site as an testing endpoint. But there is no request done by anchore-engine.

This is my webhook config:

webhooks:
#  webhook_user: 'user'
#  webhook_pass: 'pass'
  ssl_verify: False
  notification_retry_timeout: 30
  general:
    url: 'http://webhook.site/f96f3a0b-14fa-4c91-b4b8-a75b8c6d999e/general/<notification_type>'
#  policy_eval:
#    url: 'http://localhost:9090/policy_eval/<userId>'
#    webhook_user: 'mehuser'
#    webhook_pass: 'mehpass'
# special webhook for FATAL service events - system will store in DB if not enabled here
  error_event:
    url: 'http://webhook.site/f96f3a0b-14fa-4c91-b4b8-a75b8c6d999e/error_event/'

In the log I found nothing about a failed request.
All subscriptions are activated and I manually updated an image, pushed it to the registry and added it to the engine to reanalyze it.

Thanks,
Kaitsh

Is this a request for help?:

YES

Is this a BUG REPORT or a FEATURE REQUEST? (choose one):

BUG REPORT

Version of Anchore Engine and Anchore CLI if applicable:

anchore-cli, version 0.1.9
Name: anchore-engine
Version: 0.1.9

What happened:

Updated config.yaml as follows:

webhooks:
  ssl_verify: False
  general:
    url: 'http://localhost:8080/general/<notification_type>'
  tag_update:
    url: 'http://localhost:8080/tag_update'
  policy_eval:
    url: 'http://localhost:8080/policy_eval'
  error_event:
    url: 'http://localhost:8080/error_event/'

I also marked True for all subscr types for centos:latest tag

What did you expect to happen:

Some messages in logs regarding webhook invocation when images are scanned, etc. Not only are logs silent but my app doesn't show callbacks being hit.

Any relevant log output from /var/log/anchore:

Is silent regarding all webhooks except kubernetes. When I try to disable the k8s webhook logs go bonkers trying to restart it, etc.

What docker images are you using:

Yours

How to reproduce the issue:
Update config.yaml for webhooks per above and see they aren't called.

Anything else we need to know:
Nope!

I couldn't see this feature anywhere, I could be wrong, but if not I wanted to start a discussion of storing information about what the CVE database looked like at the time of a scan. This could be useful if you want to find out if a particular scan did or did not check for a CVE.

If the anchore-manager is invoked before any anchore tables exist, both the 'anchore' and 'user' tables are created, but only the 'system' user record is populated. Then, during regular anchore-engine startup, the code path for populating the other users defined in config.yaml is skipped (anchore record indicates no upgrade, all tables exist).

Fix is an update to the db init process in anchore-manager, to include a 'db_post_actions' section, which runs every time the service starts. This will avoid the above condition, if it occurs due to a process as described or similiar.

Anchore-engine <= 0.1.5 only supported the option to store archive documents in the main DB, even though early versions also supported a local FS option as well. We want to bring back this ability, and in addition the new implementation will better support future additional archive storage drivers to be added.

Is this a request for help?:

Yes

Is this a BUG REPORT or a FEATURE REQUEST? (choose one):

BUG REPORT

Version of Anchore Engine and Anchore CLI if applicable:
.2.1

What happened:

Tried to reset installation by nuking contents under aevolume/db directory and removing postgres/anchore docker images. Expecting startup from scratch via config.yaml and the docker-compose file.

Logs say there is an ssl handshake issue with ancho.re http site.

anchore-engine_1 | [service:policy_engine] 2018-05-30 00:45:05+0000 [-] [urllib3.connectionpool] [DEBUG] Starting new HTTPS connection (1): ancho.re
anchore-db_1 | WARNING: there is no transaction in progress

anchore-db_1 | WARNING: there is no transaction in progress
anchore-engine_1 | [service:policy_engine] 2018-05-30 00:45:05+0000 [-] [bootstrap] [ERROR] Preflight checks failed with error: ("bad handshake: Error([('SSL routines', 'ssl3_get_record', 'wrong version number')],)",). Aborting service startup

This prevents the policy engine from ever starting up it would appear.

What did you expect to happen:

Connection successfully made to required sites.

What docker images are you using:

The one produced by the docker-compose file

How to reproduce the issue:

Should hit any new server install.

Anything else we need to know:
Nope

Is this a request for help?:

Question. I wanted to write a go API for anchore-engine but I cannot find any API documentation. Is there one somewhere or should I juste read the CLI code?

Is this a BUG REPORT or a FEATURE REQUEST? (choose one):
Feature request

In 0.2.2dev, the new registry validation code will prevent adding credentials for dockerhub (registry docker.io) with the following error:

Error: cannot ping supplied registry with supplied credentials - exception: failed check to access registry (https://docker.io,*****) - exception: No JSON object could be decoded
HTTP Code: 406

this is due to the registry validator not translating the docker.io string into the actual dockerhub registry url (https://index.docker.io), as the other dockerhub handlers do. The fix is to add the translation logic to the ping_registry routine.

When using the nodocker driver on images with multiple content layers analysis is exponentially slower.

User reported with python:2.7 image
On my system with nodocker driver analysis is over 40 minutes, it is < 2 minutes with local driver.

Log snippet showing processing times for individual tar layers:

[root@ae39094f946d anchore]# grep Pass anchore-worker.log*
anchore-worker.log:2017-12-31 13:51:07+0000 [-] [Thread-254214] [anchore_engine.clients.localanchore_standalone/squash()] [DEBUG] Pass 1: /scratch/ee58dc21-4bc6-4fdd-883f-f2e83533725a/raw/339478b617282ad27ec5882252d893f7b930a73c04bbd0ccce09556f755480b3.tar
anchore-worker.log:2017-12-31 13:51:08+0000 [-] [Thread-254214] [anchore_engine.clients.localanchore_standalone/squash()] [DEBUG] Pass 1: /scratch/ee58dc21-4bc6-4fdd-883f-f2e83533725a/raw/c308c099d65443ad70019266d8a94af40fc4c2bb4c86b0bc8dfcd1d74258325f.tar
anchore-worker.log:2017-12-31 13:51:08+0000 [-] [Thread-254214] [anchore_engine.clients.localanchore_standalone/squash()] [DEBUG] Pass 1: /scratch/ee58dc21-4bc6-4fdd-883f-f2e83533725a/raw/f7e0c30e74c626e78d2cb2402848269b79c7fe04496ee8438aa662d58e436260.tar
anchore-worker.log:2017-12-31 13:51:29+0000 [-] [Thread-254214] [anchore_engine.clients.localanchore_standalone/squash()] [DEBUG] Pass 1: /scratch/ee58dc21-4bc6-4fdd-883f-f2e83533725a/raw/09f35bd58db288964a8bb8698b5f41bfb05df1758e54c2aad2f3fda3c38b240a.tar
anchore-worker.log:2017-12-31 13:52:13+0000 [-] [Thread-254214] [anchore_engine.clients.localanchore_standalone/squash()] [DEBUG] Pass 1: /scratch/ee58dc21-4bc6-4fdd-883f-f2e83533725a/raw/51d6678c3f0e0c6e2b58b51ad100912b7c0e4dfedf98a1808417216fd5d948e5.tar
anchore-worker.log:2017-12-31 14:11:54+0000 [-] [Thread-254214] [anchore_engine.clients.localanchore_standalone/squash()] [DEBUG] Pass 1: /scratch/ee58dc21-4bc6-4fdd-883f-f2e83533725a/raw/b313b08bab3b8bbcf0de4171a2a80a01e67fab094f272819b76a58705d21ab28.tar
anchore-worker.log:2017-12-31 14:20:54+0000 [-] [Thread-254214] [anchore_engine.clients.localanchore_standalone/squash()] [DEBUG] Pass 1: /scratch/ee58dc21-4bc6-4fdd-883f-f2e83533725a/raw/7b491c575b06601bb07a2d88bfc3ace6c6005edc1b4d8da3ba6e37e04e9592d6.tar
anchore-worker.log:2017-12-31 14:23:05+0000 [-] [Thread-254214] [anchore_engine.clients.localanchore_standalone/squash()] [DEBUG] Pass 1: /scratch/ee58dc21-4bc6-4fdd-883f-f2e83533725a/raw/f49cf87b52c10aa83b4f4405800527a74400fb19ea1821d209293bc4d53966aa.tar
anchore-worker.log:2017-12-31 14:36:54+0000 [-] [Thread-254214] [anchore_engine.clients.localanchore_standalone/squash()] [DEBUG] Pass 3: /scratch/ee58dc21-4bc6-4fdd-883f-f2e83533725a/squashed_tmp.tar

Tested in 0.2.1

Swagger for POST and PUT registries route is missing registry_pass

When the engine is configured to use IAM_AUTO mode (allow_awsecr_iam_auto = True in config.yaml) and a registry is added with 'awsauto' as username, if the registry is in another account from the account the role exists in the token is not configured correctly because the registryID (account ID of the registry) is not set in the get_authorization_token() call to get credentials.

To reproduce:

• Grant access to the engine account in the ECR repository policy in AWS, read-only.
• Run anchore-engine in aws iam auto mode and add a registry in a different account from the one the engine is running in.
• Try to analyze a tag in that repository. Will fail with auth issue.

To fix:
add registryIds=[aid] in the params the get_authorization_token() call for https://github.com/anchore/anchore-engine/blob/master/anchore_engine/auth/aws_ecr.py#L26

I'm not having luck with the engine starting up because it hits a preflight check that fails:

anchore-engine_1 | 2018-02-16 19:49:36,145 ERROR policy_engine_bootstrap - Preflight checks failed with error: ("bad handshake: SysCallError(104, 'ECONNRESET')",). Aborting service startup
anchore-engine_1 | Traceback (most recent call last):
anchore-engine_1 | File "/usr/bin/anchore-engine", line 128, in startup_service
anchore-engine_1 | raise Exception("process exited: " + str(rc))
anchore-engine_1 | Exception: process exited: 1

This certainly smells like a network issue, but I don't see how to debug it from outside the container.

I followed the documentation on how to run anchore locally using docker-compose, and look like it is running. When I run:

./anchore-cli  --url http://localhost:8228/v1 --insecure --u admin --p foobar evaluate check ubuntu:latest 

It failed with the error above. I also run system status and look like everything is up:

Service catalog (http://localhost:8082): up
Service apiext (http://localhost:8228): up
Service analyzer (N/A): up
Service simplequeue (http://localhost:8083): up
Service kubernetes_webhook (http://localhost:8338): up
Service policy_engine (http://localhost:8087): up

And I also look at the logs, but could not find anything relevant there.