Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Repository token API #175

Open
rvolosatovs opened this issue Jun 14, 2022 · 3 comments
Open

Repository token API #175

rvolosatovs opened this issue Jun 14, 2022 · 3 comments
Labels
enhancement New feature or request

Comments

@rvolosatovs
Copy link
Member

rvolosatovs commented Jun 14, 2022

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.

@rvolosatovs rvolosatovs added the enhancement New feature or request label Jun 14, 2022
@MikeCamel
Copy link
Member

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
Copy link
Member Author

rvolosatovs commented Jun 14, 2022

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
Copy link
Member

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants