More robust authentication

[itaysk]

Currently the Helm repo standard is to use anonymous HTTP or HTTP Basic authentication. This is a proposal to support a more robust authentication scheme with Chart Museum. Hopefully it will be embraced by Helm. If it won't, it still shouldn't affect Chart Museum's compliance with the Helm repo standard since this is an additional functionality on top of the standard functionality.

This was originated from the discussion around Multi-tenancy to Chart Museum, but it's a good feature for single-tenant users also hence this issue to kick-off this discussion as well.

OAuth/JWT clarification:
OAuth2 is the common protocol for API authorization. It defines a set of scenarios (flows) that each describe how the client, server (resource server) and authorization server can work together to allow a client application to obtain an access token to some protected resources. The result of this auth dance is a token which the client can use for accessing the resources. The most common type of token is JWT, which is basically a signed JSON document with an agreed upon schema. When a user gets hold of a valid JWT (by following OAuth2, or by any other means), they will present it to the server which will validate the token, after which point the request is authenticated, and may proceed to making authorization decisions which are out of scope for now.

Chart Museum is a server that hosts charts. In OAuth2 lingo it is a resource server which rely on some other party to issue tokens. If we look at Docker Registry for reference, it seem to take similar approach of promoting OAuth2, but the open registry implementation (distribution) does not implement the entire flow (at least not as part of core), it expects the token to be issued by another component.

Taking this approach has the following benefits:

• Doesn't require a database (as requested by early adopters) but make it optional
• Cleanly integrate into hosting environments
• Leverage existing OAuth/JWT frameworks

To implement this, Chart Museum needs to accept JWT token:

• bootstrap CM using certain configuration like: trusted authorization server URL, valid signing keys, etc
• add a middleware that will enforce auth
• extract the token from the Authorization header
• validate the token
• examine allowed actions for this token (scopes)
• allow/disallow the request (disallow should return 401 with information on the required authentication)

References:

• OAUTH2 vs JWT: https://community.apigee.com/questions/21139/jwt-vs-oauth.html
• Docker Hub OAuth2: https://docs.docker.com/registry/spec/auth/token/
• Simple JWT validation as Gin middleware: https://github.com/gin-gonic/contrib/tree/master/jwt
• JWT verifivation details: https://auth0.com/docs/api-auth/tutorials/verify-access-token
• Docker registry (distribution) reference implementation of authorization server: https://github.com/docker/distribution/tree/master/contrib/token-server
• Docker Registry oss authorization server: https://github.com/cesanta/docker_auth
• Sample setup of Docker Registry, Docker Authorization Server, and Identity Provider: https://github.com/kwk/docker-registry-setup

[jdolitsky]

@itaysk thanks for the detailed set of requirements!

@liamawhite @SlickNik do you have anything to add here?

[jdolitsky]

@technosophos @bacongobbler @mattfarina @jzelinskie

Hopefully it will be embraced by Helm. If it won't, it still shouldn't affect Chart Museum's compliance with the Helm repo standard since this is an additional functionality on top of the standard functionality.

Lets align this with the Helm 3 repo proposals as they relate to auth

[bacongobbler]

Just adding a fly-by comment, but assuming that this is adding additional functionality and not removing (or amending) the existing client/repo auth model for Helm, this could be tackled in core during the Helm 2.0 timeline. It doesn't have to be punted down the line to Helm 3. :)

Definitely agree that we should probably visit this proposal when we come to Helm 3 repo discussions.

[jdolitsky]

Like where your heads at!

[SlickNik]

This is all great stuff -- thanks for kicking off the discussion @itaysk and @jdolitsky! I agree that following a similar model to docker/distribution makes sense in this regard. In addition to this, one thing that would be good to flesh out is the scheme and grammar for supported resource scopes.

There is some good documentation about the scopes supported by the docker registry at https://github.com/docker/distribution/blob/master/docs/spec/auth/scope.md -- this would be a good starting point to have the discussion around what resource scopes we should support / enforce in ChartMuseum.

[jzelinskie]

Let's not forget OCI: the distribution protocol for OCI is in a proposal state. I haven't gone over it enough to know what it carves out around auth, but the closer we can map to that, the better.

[jdolitsky]

@jzelinskie yes, please link that here

[jzelinskie]

Here's the proposal: opencontainers/tob#35