Repository token API

[rvolosatovs]

We should add support for specifying a repository-wide token. Such token is generated by the Drawbridge and returned to the caller via the API. It serves a second factor during certificate-based auth.
A token is only ever shown once in the response of the HTTP(s) request generating it.

The backend should store the hash of the token as repository-wide state. https://github.com/profianinc/drawbridge/blob/9cdedb3900c78ef72c346cd8c6ec29e112e49789/crates/type/src/repository/config.rs is a good candidate model for this, it should probably be renamed to RepositoryState or RepositoryData.

The relationship of tokens to repositories is many-to-one. There can be [0; N] tokens associated with a repository.

Once at least one token is generated for a repository, a valid token must be presented to the Drawbridge API for artifact fetching with certificate-based auth.

Perhaps we should disallow certificate-based auth for all repositories by default on creation and have a manual switch to make a repository public. That means that all repositories are created as private by default, but with no tokens generated, which means it's not possible to access the artifacts with any other mode of auth than a supported user auth (only Github at the time of writing). Then the user has a choice of either generating a token to use for accessing the Drawbridge repository from an Enarx instance and communicating that token to the instance via some out-of-band protocol or making the repository public.

The token itself is opaque base64url-encoded token from the user's perspective. We may in the future want to add a concept of a scope to the token, in which case we may consider using e.g. JWT internally for this, however at present there is no such need and we can handle this in a fully backwards-compatible fashion as long as the tokens themselves are fully opaque to the user.

At fetch time with certificate-based auth, the token itself is communicated in the header of the HTTP(s) request as a Bearer token.

[MikeCamel]

I'd like to have a clear distinction between uses for authentication/authorisation. Let's create some clear nomenclature to differentiate between the various APIs:

1. adding/removing/updating applications/deployments (a user-based set of actions, though may be automated, of course)
2. accessing deployments (a Keep-based set of actions).

To which are we referring here?

[rvolosatovs]

I'd like to have a clear distinction between uses for authentication/authorisation. Let's create some clear nomenclature to differentiate between the various APIs:

1. adding/removing/updating applications/deployments (a user-based set of actions, though may be automated, of course)

2. accessing deployments (a Keep-based set of actions).

To which are we referring here?

A token is only ever used for 2 and shared with the host, it is used for authorization only. It does not convey any information about identity.
It is created by the user via a supported mode of authentication and authorization in 1 as part of repository state management.

[npmccallum]

@MikeCamel The token is visible to the CSP and enables the CSP to deploy in Enarx. This prevents a random attacker, not the CSP, from launching the workload in their own, possibly instrumented, hardware.

Both the token and attestation certificate are required to deploy.