Re: [BuildStream] Artifact cache authentication/metrics

[Jürg Billeter <j bitron ch>]

On Wed, 2018-08-15 at 13:44 +0900, Tristan Van Berkom via BuildStream-
list wrote:
> First of all, sorry that your email went unanswered, I tried to catch
> up with unanswered emails yesterday and this one fell off the grid.
>
> On Sat, 2018-08-04 at 12:52 +0100, Adam Jones via BuildStream-list
> wrote:
> > And that currently to push the server you have to maintain a list
> > of authorized certificates, under authorized.crt. But apart from
> > that i am not sure how granular you can be.
>
> Certificates are complex beasts; as I understand you can do all sorts
> of elaborate things with them, like use a certificate to create a child
> certificate, having the power to later revoke the child certificate (I
> can imagine this being interesting for a participating organization to
> grant permission and later revoke permission for it's members, without
> requiring access to the artifact server host to update it).
>
> Again, certs fall into that networking territory where I have developed
> a natural aversion to any knowledge retention; maybe the above
> functionalities requires a certificate authority service to work.
>
> I am unsure if any of that kind of functionality is possible with the
> way BuildStream itself uses the certificates to authenticate at the
> endpoints.
>
> Care to ring in here Jürg ?

The configured client certificates are passed to gRPC as client root
certificates. I expect subordinate certificates (signed by one of the
configured client root certificates) to work but I haven't tried that
myself so far.

> Fancy certificate features aside, granularity can still be down to each
> user; although in most setups as far as I can see, it is less
> interesting to have individual developers pushing artifacts, and much
> more interesting to have build servers build things, while developers
> benefit from only having to download, and only having to build locally
> the things which they want to test and experiment with.

Yes, the idea was to have something reasonably straight forward to
configure for the typical use case where only build servers (and maybe
a couple of privileged users) require push access.

> The certs only authorize upload, and download never requires
> authentication of any sort from the perspective of the http service
> itself; I believe this is why we mention in the docs that a sysadmin
> versed in the dark arts of networking, could set it up behind a
> reverse proxy in such a way as to ensure only authenticated users can
> see the `http` service at all.

While that's how the example in the documentation is set up, it is
possible to specify client certificates also for a pull-only instance
of `bst-artifact-server`, if only authenticated users should be allowed
access.

Jürg