API: add POST based API

[philips]

For playing around with clair it would be much nicer if I could POST the image for analysis instead of going through hoops, as analyze-local-images does, to pull from a web server. This is a local development nicety but I bet it would make it easier for people to participate. It certainly tripped me up while I tried to use analyze-local-images.

[jzelinskie]

This is might be a little tricky because we'd have to be able to determine all of the metadata usually passed in the JSON body of a POST to /v1/layers from whatever blob we get over the wire. What formats would the images be (docker save and rkt image extract)? I'm adding the design tag to this issue.

[philips]

@jzelinskie seems like a query param, content-type, or path could differentiate that stuff.

[jakedt]

There's also always multipart. @philips would that work or is the construction of the multipart request too high of a barrier for local development?

[jgsqware]

Hello, you could have a look at github.com/wemanity-belgium/hyperclair.

It try to address that problem, with an easier cli to interact with clair

[Quentin-M]

Related to #148.

Data detectors are used to detect the filesystem of container layers. Therefore, there's a bit of a container spec dependency there. However, this logic currently applies to single layers and can't be used to detect multiple layers / organize them. I don't want to add extra spec dependencies (i.e. reading a manifest) in another subsystem of Clair. Thus, we might want to extend its purpose.

[Quentin-M]

As @jgsqware mentioned, what about at least posting the content of individual layers? That would remove the need of having an HTTP server able to serve layer, and thus, simplify Clair's integration and security management. In that case, Hyperclair/clairctl would still ease of proper image posting.

It should be an easy change and non-breaking in regard to the API.

[Quentin-M]

I still think that we may definitely accept images as well, maybe through another API call. To do so, we might extend the worker.DataDetector interface and wrap worker.Process.

[jgsqware]

Agree with @Quentin-M, it should be 2 different way to upload. The advantage i can see of pushing image than layer tarball, is to avoid to push so layer already pushed to clair.

[jgsqware]

However, the work of metadata extraction from images/manifests is already done in clairctl, so we can move it quite easily to a process in clair

[Quentin-M]

True. While accepting posted layers would ease usage (as explained above), accepting posted images would ease usage even further, to the point where no client side logic would be required anymore, however, users might end up pushing data that have already been analyzed (which may or may not be a drawback for some use cases). In my opinion, both solutions could be provided by Clair eventually. At first, we should accept posted layers (no API change, little code change) and get #164 in.

[jgsqware]

for POST layer: what do you prefer:

• POST v1/layers (with multipart) (need to evaluate if it breaks current POST method)
• POST /v1/layers/sha256:123587453 (with multipart to send needed info like parent...)

[ghost]

Two queries:

1. Does latest clair release support POSTing of layers/images instead of starting HTTP server etc?

2. One of the comments above says hyperclair (clairctl) solves this issue, how does the issue get solved is clair doesnt support the POST api?

Any pointers would be helpful. This is one of the reasons we are not using clair as the infra team sees this as a security issue.

[hdonnay]

We’re declaring bug bankruptcy as part of the release process for a new major version of Clair. Please open a ticket in our issue tracker if you feel this still needs to be addressed, and we'll triage as part of our v4 development process. Thanks!