Using flat-manager for private app repo

[Alexander Larsson]

On Fri, May 3, 2019 at 2:15 PM Dan Nicholson <nicholson at endlessm.com> wrote:
>
> On Fri, May 3, 2019 at 3:44 AM Alexander Larsson <alexl at redhat.com> wrote:
>
> > > One thing that could be useful is an API endpoint that takes a ref and
> > > returns a list of commit and delta superblock URL paths. Then the
> > > authorization server could generate the proper signed URLs in the
> > > format the CDN needed after determining that the user was allowed to
> > > access a specific ref. I don't know, I haven't quite been able to
> > > figure out how this would go.
> >
> > I'm not sure what this would be used for. This is like moving to the
> > client the set of urls you're required to supply a token for. But that
> > seems backwards, it is the CDN (or proxy or whatever) that need to
> > know if a url needs a token, we can't trust the client in this. How
> > did you imagine this API being used?
>
> Because I believe the CDN signed URLs need to happen in the
> authorization server or the CDN itself, and neither would have this
> application specific knowledge.

I guess this depends in general on how flexible the CDN is wrt its
support of token verification. I was hoping we could avoid doing the
exact mapping to url ahead of time and just use a signed token that
represent all urls related to the app, because that is less prone to
races between the entitlement lookup and the actual ostree pull. But,
if that is not possible we'd have to generate ahead of time the exact
list of files that are allowed.

> > We do however need to know this. But I don't think you ever need this
> > full list? Instead what the client does is look at the summary file,
> > figures out which commit and delta uris to download, and then just
> > does it, passing in the token the auth server gave it (for this ref)
> > to every such request. Then the CDN/flat-manager needs to know if this
> > particular ref requires a token, and if so which token.
> >
> > This can happen in two ways:
> > 1 ) The check happens directly in flat-manager, where it just returns
> > a 403 error if the token is missing
> > 2) The check happens in the CDN, but it has no idea initially, so it
> > proxies the request to flat-manager, and flat-manager knows which/if
> > any token is needed, and returns the result + a header telling the cdn
> > which token it needs to apply.
> >
> > This is how we support both direct and CDNed access control. Maybe
> > flat-manager has a known list of CDN ip address sources where it does
> > 2, and otherwise it does 1. Or maybe the CDN sets some magic secret
> > when proxying.
>
> I don't see how 2 could work generally. If the CDN has an
> authentication requirement (say, a signed URL), then the CDN will just
> respond with a 403 if the incoming request isn't appropriately signed.
> It won't pass the request through to the origin since that would be
> the opposite of requiring authentication at the edge. I believe the
> only way this would work would be for the authorization server to know
> about the CDN authentication scheme and send back tokens that both the
> CDN and flat-manager understand.

Yeah, looking at the cloudfront signed url things it seems we need to
know the exact urls. And in fact, we can't use a generic header for
the entire pull operation but have to use a different one depending on
which url ostree happened to use (i.e. delta vs commit object). That
seems to imply that we need to have the entire list of possible signed
urls, feed it to ostree and have ostree pick the right when doing the
request.

> > 2) Support in flat-manager to extract the ref bindings for commit and
> > delta superblock files
>
> Yeah. I was already looking at this a bit. What I've done in the past
> (https://github.com/ostreedev/ostree-releng-scripts/pull/12) is to
> just walk each ref and keep a map of commits to refs (or vice versa).
> I hadn't thought about using the ref bindings, but that's even faster.
> A 3rd option I thought about was keeping a table in the database with
> this info.

Just use the ref bindings. Its fast, and robust. Keeping it in the db
is just a recipe for things going out of sync.

> Do you have any objection to pulling in the libostree crate in
> flat-manager. I'd much rather use the ostree API for this kind of
> stuff than open coding GVariant parsing (bravo to you for that!).

I prefer to have the code pure rust. It makes it much easier to build
and deploy. I think most of the GVariant parsing code required is
there already, and I can fill out the rest as needed. Its really not a
lot of code.

> > 3) Support in flat-manager to optionally verify ref binding vs the
> > token (this should probably use a separate secret from the one used
> > for auth:ing the build APIs, and probably a different, simpler token
> > format).
>
> I don't think you really need a separate secret - just because you
> used it to generate 2 different types of tokens, the risk of losing
> them is the same. But I don't think coming up with a token format
> specifically for this use case is best.

But you have to put the secret on the entitlement machine, so that it
can sign the tokens. Having this secret on two machines seems more
risky to me.

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                Red Hat, Inc
       alexl at redhat.com         alexander.larsson at gmail.com