Idea #7534
closed[API] Allow administrators to retrieve an effective superuser token after installation
Description
Functional requirements: Once the API server is installed, the administrator should be able to run a script or Rake task that writes out the API token on stdout. This API token must be attached to a trusted API client (i.e., it can manipulate other API tokens), and must be owned by the "root" user (i.e., zzzzz-tpzed-000000000000000).
Ideally if a token already exists that meets these criteria, it returns that, to avoid a proliferation of superuser tokens.
This will simplify deployment of new clusters.
Implementation¶
Extend the existing program./script/create_superuser_token.rb
- Instead of using
api_client_id: 0when creating a new token, find_or_create an ApiClient withurl_prefix=="ssh://root@localhost/"andis_trusted==true - Instead of creating a new token every time, use find_or_create to reuse an existing unexpired token with the relevant
api_client_id, if one exists.
lib/create_superuser_token.rb like we did with #6859)
- Call once → get new token whose api_client has
is_trusted==true - Call twice → get the same token twice, not two new ones
- Call once, expire the returned token, call again → get a new unexpired token
- If a token is supplied on the command line, and it isn't a valid token, use that string as the new api_token when creating the new ApiClientAuthorization
- If a token is supplied on the command line, and it is a valid token, just print it: don't create a new token, don't create an ApiClient record, don't update the
api_client_idof the existing token.
Updated by Brett Smith over 10 years ago
- Description updated (diff)
- Category set to API
Updated by Tom Clegg over 10 years ago
- Story points set to 1.0
Implementation¶
Extend the existing program./script/create_superuser_token.rb
- Instead of using
api_client_id: 0when creating a new token, find_or_create an ApiClient withurl_prefix=="ssh://root@localhost/"andis_trusted==true - Instead of creating a new token every time, use find_or_create to reuse an existing unexpired token with the relevant
api_client_id, if one exists.
lib/create_superuser_token.rb like we did with #6859)
- Call once → get new token whose api_client has
is_trusted==true - Call twice → get the same token twice, not two new ones
- Call once, expire the returned token, call again → get a new unexpired token
- If a token is supplied on the command line, and it isn't a valid token, use that string as the new api_token when creating the new ApiClientAuthorization
- If a token is supplied on the command line, and it is a valid token, just print it: don't create a new token, don't create an ApiClient record, don't update the
api_client_idof the existing token.
Updated by Brett Smith over 10 years ago
- Target version changed from 2015-10-28 sprint to Arvados Future Sprints
Updated by Brett Smith over 10 years ago
- Assigned To set to Radhika Chippada
- Target version changed from Arvados Future Sprints to 2015-11-11 sprint
- Description updated (diff)
Updated by Radhika Chippada over 10 years ago
- Status changed from New to In Progress
Updated by Nico César over 10 years ago
I see on the tests that the superusertoken is being printed, is there a way to avoid this? besides being aesthetically ugly to see the tests to break in several lines (but we have several of those.. )
I just want to prevent a potential supertoken information leak if someone is running tests and the test output is public (like a Jenkins job for example).
Updated by Radhika Chippada over 10 years ago
Moved the print statement from the library into the script.
Updated by Nico César over 10 years ago
review 263cd68f5ae4b114d3c1c89f84be46b0f64f9c9e
LGTM
Updated by Radhika Chippada over 10 years ago
- Status changed from In Progress to Resolved
- % Done changed from 0 to 100
Applied in changeset arvados|commit:efb5501e40de0d49c285db0d7a22ff8a8593832c.