Actions
Feature #14262
closed[Controller] Specify runtime_token when creating container requests on a remote cluster
Start date:
10/24/2018
Due date:
% Done:
100%
Estimated time:
(Total: 0.00 h)
Story points:
2.0
Release:
Release relationship:
Auto
Description
When a client asks its home cluster to create a CR on a remote cluster, the resulting container should have privileges -- but the remote cluster cannot create a runtime token by itself that is capable of reading collections from any other cluster. Instead, the home cluster, when proxying the request, should use the runtime_token field to supply a token for the container to use.
When proxying a "create container request" request to a remote cluster, the controller should:- Check whether the current token is a local token with
scopes=["all"]
(if not, skip the rest) - Check whether a
runtime_token
was already supplied by the caller (if so, skip the rest) - Create a new api_client_authorizations record, with an expiry time set to
(now + blob_signature_ttl)
, and use that asruntime_token
in the proxied request
Updated by Tom Clegg over 6 years ago
- Related to Feature #14260: [API] Add "runtime_token" field to container_requests added
Updated by Peter Amstutz over 6 years ago
- Related to Feature #14200: [API] Reduce privilege exposure via API tokens in multi-cluster workflows added
Updated by Peter Amstutz about 6 years ago
- Assigned To set to Peter Amstutz
- Target version set to 2018-10-17 sprint
Updated by Peter Amstutz about 6 years ago
- Target version changed from 2018-10-17 sprint to Arvados Future Sprints
Updated by Peter Amstutz about 6 years ago
- Target version changed from Arvados Future Sprints to 2018-10-17 sprint
Updated by Peter Amstutz about 6 years ago
- Status changed from New to In Progress
- Target version changed from 2018-10-17 sprint to 2018-10-31 sprint
Updated by Peter Amstutz about 6 years ago
- Target version changed from 2018-10-31 sprint to 2018-11-14 Sprint
Actions