Using flat-manager for private app repo

[Robert McQueen]

On Thu, 2019-05-02 at 11:13 -0500, Dan Nicholson wrote:
> On Tue, Apr 30, 2019 at 11:11 AM Alexander Larsson <alexl at redhat.com>
> wrote:
> > But yeah, I see what you mean. Its basically what happens now
> > except
> > the current limit is on a per-repo basis, and it would need to be
> > changed to per-commit or per-ref or something more finegrained. It
> > means each single download would need to hit the master server
> > though,
> > which seems like it could be a performance problem. I think we
> > should
> > try our very best to make it at least possible to move the
> > authentication to the edge.
> 
> This is definitely the weakest part of this scheme. We're highly
> dependent on our CDN at Endless for making access fast. Requiring
> connections through to the origin would slow things down.

Sure it would slow them down... for the metadata (commits, delta
superblocks), but we can still access these via the CDN and mark the
caching as dependent on the presented token. All of the big stuff such
as objects will be cached as normal through the CDN.

And if it's a read-only determination (checking an entitlement, etc)
that doesn't need to update any shared state, it's /very/ horizontally
scalable. We can just run more flat-managers in more places to handle
the load and use the CDN config (or nginx frontends, etc) to split
between the metadata objects being served from flat-manager and
everything else from disk. So even if we did need a flat-manager to
make some decision for each commit metadata hit, I didn't imagine it
would be that hard to scale.

If you /do/ have a super fancy CDN with arbitrary edge logic (some like
Cloudflare have like JS lambdas - you could teach it to maintain a ref-
>commit mapping etc) you could eventually disperse this determination
too. But I didn't consider it to be a substantial bottleneck enough to
design flat-manager out from the picture from the start - more
something to design/optimise later.

> So, probably there is a way to make the CDN edge server handle
> authorization, although it would be specific to the CDN provider.
> That
> said, I think it should be possible to deploy a private app store
> without also requiring on a CDN. In other words, I think it should be
> possible to handle the authorization at both the origin and edge
> server.

Agreed here. Whatever the scheme is I think flat-manager (if that's the
actual origin service) would ideally contain a complete/reference
implementation of it which is then disabled when acting as the CDN
origin, or you don't actually run the CDN origin via flat-manager if
your CDN /can/ do the scheme.

> 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.

Potentially we could do the two discoveries in one step - user
entitlement (you can get these refs, yes or no) and ref -> commit
mapping (those refs are currently these commits, or these URLs that you
should be able to get).

user -> API server: authenticated(I would like ref)
API server -> user: OK! token(ref -> object/.../foo.commit,
delta/bar/superblock, delta/baz/superblock)
user -> download: fetch object/.../foo.commit with token
...

It seems desirable to me that we could alleviate our
CDN/server/origin/edge/thing from the need to do either a user
entitlement or a ref->commit lookup, so a JWT that has all of that
stuff listed in it is very cool. However, I agree with Alex that we
need to make them specific to a certain retrieval and short-lived.

So as the thing that can resolve refs to commits, flat-manager could
hand out those temporary tokens via it's API - or a separate service
that is ostree aware. Either way it would need an API to check the user
entitlement somehow. (A cachable "user x wants ref y, yes or no?"
backend. Or maybe just "get me the current permitted refs for user x".)

> --
> Dan

Cheers,
Rob

> _______________________________________________
> Flatpak mailing list
> Flatpak at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/flatpak