Story #7534

[API] Allow administrators to retrieve an effective superuser token after installation

Added by Brett Smith about 6 years ago. Updated almost 6 years ago.

Status:
Resolved
Priority:
Normal
Assigned To:
Radhika Chippada
Category:
API
Target version:
Start date:
11/10/2015
Due date:
% Done:

100%

Estimated time:
(Total: 0.00 h)
Story points:
1.0

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: 0 when creating a new token, find_or_create an ApiClient with url_prefix=="ssh://root@localhost/" and is_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.
Add tests (might require moving the code into 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
Preserve existing behavior
  • 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_id of the existing token.

Subtasks

Task #7688: Review branch 7534-superuser-tokenResolvedNico César

Associated revisions

Revision efb5501e
Added by Radhika Chippada almost 6 years ago

closes #7534
Merge branch '7534-superuser-token'

History

#1 Updated by Brett Smith about 6 years ago

  • Description updated (diff)
  • Category set to API

#2 Updated by Tom Clegg about 6 years ago

  • Story points set to 1.0

Implementation

Extend the existing program ./script/create_superuser_token.rb
  • Instead of using api_client_id: 0 when creating a new token, find_or_create an ApiClient with url_prefix=="ssh://root@localhost/" and is_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.
Add tests (might require moving the code into 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
Preserve existing behavior
  • 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_id of the existing token.

#3 Updated by Brett Smith about 6 years ago

  • Target version changed from 2015-10-28 sprint to Arvados Future Sprints

#4 Updated by Brett Smith almost 6 years ago

  • Assigned To set to Radhika Chippada
  • Target version changed from Arvados Future Sprints to 2015-11-11 sprint
  • Description updated (diff)

#5 Updated by Brett Smith almost 6 years ago

  • Description updated (diff)

#6 Updated by Radhika Chippada almost 6 years ago

  • Status changed from New to In Progress

#7 Updated by Nico César almost 6 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).

#8 Updated by Radhika Chippada almost 6 years ago

Moved the print statement from the library into the script.

#9 Updated by Nico César almost 6 years ago

review 263cd68f5ae4b114d3c1c89f84be46b0f64f9c9e

LGTM

#10 Updated by Radhika Chippada almost 6 years ago

  • Status changed from In Progress to Resolved
  • % Done changed from 0 to 100

Applied in changeset arvados|commit:efb5501e40de0d49c285db0d7a22ff8a8593832c.

Also available in: Atom PDF