I have the same issue it says api starting on port 6060 , but when I do a curl to the api as per the document it says connection refused on the port

vagrant@mesos:~$ docker logs 0a785dea594f
2015-11-14 17:28:07.227145 I | database: database at clairdata does not exist yet, creating it
2015-11-14 17:28:07.233576 I | api: starting Health API on port 6061.
2015-11-14 17:28:07.233685 I | api: starting API on port 6060.
2015-11-14 17:28:07.234212 I | updater: updater service started. lock identifier: 6ab22788-2a28-46b6-a9ad-157b6335aa23
2015-11-14 17:28:07.235608 I | updater: updating vulnerabilities
2015-11-14 17:28:07.235658 I | updater/fetchers: fetching Ubuntu vulneratibilities
2015-11-14 17:28:07.236212 I | updater/fetchers: fetching Debian vulneratibilities
2015-11-14 17:28:07.237239 I | updater/fetchers: fetching Red Hat vulneratibilities
2015-11-14 19:49:08.468191 E | updater/fetchers: could not download RHEL's update file: Get https://www.redhat.com/security/data/oval/com.redhat.rhsa-20110346.xml: EOF
2015-11-14 19:49:08.468214 E | updater: an error occured when fetching update 'Red Hat': could not download requested ressource.
2015-11-14 19:57:25.382972 N | database: Ignoring 15628 notifications
2015-11-14 19:57:25.400741 I | updater: update finished
2015-11-14 22:43:07.802206 I | api: starting Health API on port 6061.
2015-11-14 22:43:07.802432 I | api: starting API on port 6060.
2015-11-14 22:43:07.802608 I | updater: updater service started. lock identifier: 88365c0e-0f1d-4d9c-bffb-540e2c0aba1a
2015-11-14 22:43:07.818753 I | updater: updating vulnerabilities
2015-11-14 22:43:07.818829 I | updater/fetchers: fetching Red Hat vulneratibilities
2015-11-14 22:43:07.819124 I | updater/fetchers: fetching Ubuntu vulneratibilities
2015-11-14 22:43:07.820977 I | updater/fetchers: fetching Debian vulneratibilities
vagrant@mesos:~$ docker ps
CONTAINER ID        IMAGE                   COMMAND                  CREATED             STATUS              PORTS                      NAMES
0a785dea594f        clair                   "clair --db-type=bolt"   5 hours ago         Up 35 seconds       6060-6061/tcp              focused_leakey
8aef6bfcd3a7        saidimu/cayley:v0.4.0   "/bin/sh -c 'cayley i"   5 hours ago         Up 5 hours          0.0.0.0:11555->64210/tcp   stupefied_jepsen

vagrant@mesos:~$ curl -v localhost:6060
* Rebuilt URL to: localhost:6060/
* Hostname was NOT found in DNS cache
*   Trying ::1...
* connect to ::1 port 6060 failed: Connection refused
*   Trying 127.0.0.1...
* connect to 127.0.0.1 port 6060 failed: Connection refused
* Failed to connect to localhost port 6060: Connection refused
* Closing connection 0
curl: (7) Failed to connect to localhost port 6060: Connection refused

I got it working when I exposed the ports to the host from the vagrant vm i was running in
by running command http://localhost:11600/v1/versions got the output

{
"APIVersion": "1",
"EngineVersion": "1"
}


Hi,

@bracki You are almost there. Clair is simply a service, you now have to submit the layers of your images to it using this API Call, in the proper order. There is currently no one-liner tool to actually do it. I believe that it would be pretty easy script though: it would have to download every tarballs from the specific image you want to scan and call the HTTP API properly. Note that as you run Clair in a Docker container, you whether have to specify an URL to the tarballs or store the layers in a Docker volume that Clair can access and pass it an absolute path. Also, for now, the tarballs that have to be given are the ones that contains the filesystem diffs - not the enclosing ones containing the JSON metadata.

@amitmawkin I think that the ports are not mapped or the IP address is invalid.

yups that was the thing,

@Quentin-M one quick question does it has to be tar or it can inspect local docker images ?

@amitmawkin For the moment, Clair only supports tarballs input - the ones that contain the filesystem diffs and they have to be accessible from Clair (absolute/relative path or HTTP URL).

Basically, to inspect a local image, you have to docker save <IMAGE ID> it and then extract the resulting tar-gz archive. It will give you the filesystem diffs (layer.tar) for each layer composing the image. These are the tarballs that Clair accepts. Then you have to figure out the order of the layers with docker history --no-trunc <IMAGE ID> to be able to fill the appropriate API Call. Finally, because the tarballs have to be accessible from Clair inside its Docker container, you either have to store them on a webserver or mount a volume.

Hope it helps. I will try to write a script to ease analyzing local images next week.

Hello.

See https://github.com/coreos/clair/tree/master/contrib/analyze-local-images

Cool.

But no matter what I try:

# ./analyze-local-images --endpoint 192.168.99.100:6060 -my-address 192.168.99.100 d409400f4348

2015/11/20 23:05:23 - Could not save image: Cannot connect to the Docker daemon. Is the docker daemon running on this host?

You are using boot2docker/DockerMachine, right ?

I think that your environment is not set. What does it say when you simply run docker ps in your terminal ? I personally have these keys in my env:

DOCKER_HOST=tcp://192.168.99.100:2376
DOCKER_CERT_PATH=/Users/mentalow/.docker/machine/machines/default
DOCKER_TLS_VERIFY=1

Also, I believe that -my-address would be 192.168.99.1 as specified in the README - it should be the IP address that you would use inside a Docker container to reach the host machine (your Mac).

I've tried running analyze-local-images against a few images, including images that were deliberately vulnerable to heartbleed, but it just says the images are safe, any idea why that would be?

@dmwoods38 Did you wait for the updater to finish its initialization? In other words, did the logs say I | updater: update finished ?

@Quentin-M thanks, that must be the issue, seems to be stuck on the initialization.

@dmwoods38 The first update takes a long time, it downloads from Internet and inserts in the database a lot of data. The recent 46f356e and 46fffdf makes it slightly faster. You can increase the log level to know when it finishes to fetch vulnerabilities and start to insert them in the database.

@Quentin-M Why is it even possible to analyze images as long as the updates haven’t finished? I think it would be a better user experience if the analysis would fail with a corresponding error message until it can provide meaningful results.

For me, all my images are SAFE also,

in the log, I see

notifier: notifier service is disabled
2015-12-24 11:13:37.642965 I | api: starting main API on port 6060.
2015-12-24 11:13:37.643350 I | api: starting health API on port 6061.
2015-12-24 11:13:37.643675 I | updater: updater service started. lock identifier: 6f354c30-61cb-41d6-bcd2-293f2fa5ca9c
2015-12-24 11:13:37.644145 I | updater: updating vulnerabilities
2015-12-24 11:13:37.644439 I | updater/fetchers: fetching Ubuntu vulneratibilities
2015-12-24 11:13:37.644929 I | updater/fetchers: fetching Debian vulneratibilities
2015-12-24 11:13:37.646499 I | updater/fetchers: fetching Red Hat vulneratibilities
2015-12-24 11:26:37.126069 N | database: Ignoring 17052 notifications
2015-12-24 11:26:37.127726 I | updater: update finished
2015-12-24 11:55:47.249150 I | api: 201 POST /v1/layers (248.506873ms)
2015-12-24 11:55:47.267603 I | api: 201 POST /v1/layers (15.946751ms)
2015-12-24 11:55:47.288604 I | api: 201 POST /v1/layers (1.092048ms)
2015-12-24 11:55:47.409350 I | api: 201 POST /v1/layers (1.04387ms)
2015-12-24 11:55:47.463825 I | api: 201 POST /v1/layers (50.454678ms)
2015-12-24 11:55:47.465877 I | api: 201 POST /v1/layers (713.721µs)
2015-12-24 11:55:47.467327 I | api: 201 POST /v1/layers (645.129µs)
2015-12-24 11:55:47.469136 I | api: 201 POST /v1/layers (838.474µs)
2015-12-24 11:55:47.470503 I | api: 200 GET /v1/layers/ca14d88c9b9e9ce4f7dc3eb410a4571487eb8f28f3f2c875b7f4d26eaf65f94b/vulnerabilities?minimumPriority=Low (530.379µs)

And the result:

analyze-local-images -endpoint "http://192.168.99.100:6060" -my-address "192.168.99.1" ca14d88c9b9e
Saving ca14d88c9b9e
Getting image's history
Setting up HTTP server (allowing: 192.168.99.100)
Analyzing 8 layers
- Analyzing 0bf0561619131d3dc0432a2b40a9438bd48f4a84e89ff128cc5147a089c114e4
- Analyzing 1796d1c62d0c3bad665cc4fbe4b6a051e26c22f14aa5e0e2490e528783764ca0
- Analyzing e24428725dd6f8e354a0c6080570f90d40e9e963c6878144291c6ba9fd39b25f
- Analyzing 89d5d8e8bafb6e279fa70ea444260fa61cc7c5c7d93eff51002005c54a49c918
- Analyzing 36bf15b0ff5a08f70bb8f6ac55d51f48c443ac909cf06aa2211ede0669486a17
- Analyzing 78129506baa155f2baac744e1ee70f2cbfd45ca6495fa4c4ac22d90eb5e9f260
- Analyzing 7b82b1da56e610929d5df33ecb155b91871bbbed3df12382852deee31a2480c1
- Analyzing ca14d88c9b9e9ce4f7dc3eb410a4571487eb8f28f3f2c875b7f4d26eaf65f94b
Getting image's vulnerabilities
Bravo, your image looks SAFE !

And I use the Dockerfile shown on the Readme of Clair.
I've tried also with different images

I've also tried with

curl http://192.168.99.100:6060/v1/layers/ca14d88c9b9e9ce4f7dc3eb410a4571487eb8f28f3f2c875b7f4d26eaf65f94b/vulnerabilities?minimumPriority=Critical

Response:

{
Vulnerabilities: [ ]
}

It is maybe not abnormal. You can verify a bunch of things with:

curl http://192.168.99.100:6060/v1/layers/ca14d88c9b9e9ce4f7dc3eb410a4571487eb8f28f3f2c875b7f4d26eaf65f94b/parent

curl http://192.168.99.100:6060/v1/layers/ca14d88c9b9e9ce4f7dc3eb410a4571487eb8f28f3f2c875b7f4d26eaf65f94b/os

curl http://192.168.99.100:6060/v1/layers/ca14d88c9b9e9ce4f7dc3eb410a4571487eb8f28f3f2c875b7f4d26eaf65f94b/packages

curl http://192.168.99.100:6060/v1/layers/ca14d88c9b9e9ce4f7dc3eb410a4571487eb8f28f3f2c875b7f4d26eaf65f94b/vulnerabilities?minimumPriority=Negligible

Bravo to you @Quentin-M. After installing analyze-local-images and making sure I ran Clair with -v /tmp:/tmp it worked just fine to tell me all of our images are safe. Do you happen to have an unsafe image lying around so I could load it and make sure I'm not getting all false positives? Maybe it is a matter of creating my own CVE that falsely records a good image as unsafe? Ideas on how to do that?

@candita
You can try aerospike 3.7.0.2, it is one of the official repos, it has 31 CVE warnings in my test.

In my experience, you should start 'clair' and wait for a while until you find there are enough CVE files in /tmp/.

@liangchenye - aerospike 3.7.0.2 also gave me the result that the image was safe, so I'll open up a new discussion.

Can I ask - if we add layers of an image using the api, what is the secret to making sure that the layers are inserted in the correct historical order? docker history shows very approximate dates, and if all layers were from the same day, what is the correct way to determine the order to post them into clair?

@candita Layers shows in the order when you do docker history (the first layer in the list is the final one, the latest is the base image). Take a look at the contrib tool and how it does that.

I actually had reviewed the history method in the tool and was wondering if it was correct because I couldn't get that algorithm to work using the curl commands directly, see below for a selected summary.
In the transcript below I am copying the base image layer into /tmp/aero/[layerid] in the container, then exec ls to make sure it is there, then I POST the layer, but still cannot GET the os, packages, or vulnerabilities.

docker cp layer.tar mycontainer:/tmp/aero/c950d63587be10331540688387593721eb728628b75cdaf1dcf266188dfc6e6b

docker exec -it mycontainer ls /tmp/aero/c950d63587be10331540688387593721eb728628b75cdaf1dcf266188dfc6e6b/
layer.tar

curl -X POST -H "Content-Type: application/json" http://192.168.99.101:6060/v1/layers -d '{"ID":"c950dd63587be10331540688387593721eb728628b75cdaf1dcf266188dfc6e6b", "Path":"/tmp/aero/c950d63587be10331540688387593721eb728628b75cdaf1dcf266188dfc6e6b/layer.tar","ParentID":""}'

The log showed:
2015-12-30 15:46:12.708126 I | api: 201 POST /v1/layers (1.229753086s)

curl 192.168.99.101:6060/v1/layers/c950d63587be10331540688387593721eb728628b75cdaf1dcf266188dfc6e6b/os
{"OS":""}

curl 192.168.99.101:6060/v1/health
{"database":{"IsHealthy":true},"updater":{"IsHealthy":true,"Details":{"LatestSuccessfulUpdate":"2015-12-30T15:29:10Z"}}}

curl 192.168.99.101:6060/v1/versions
{"APIVersion":"1","EngineVersion":"1"}