Project

General

Profile

Actions

Idea #7534

closed

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

Added by Brett Smith over 8 years ago. Updated over 8 years ago.

Status:
Resolved
Priority:
Normal
Assigned To:
Radhika Chippada
Category:
API
Target version:
Start date:
11/10/2015
Due date:
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 1 (0 open1 closed)

Task #7688: Review branch 7534-superuser-tokenResolvedNico César11/10/2015Actions
Actions #1

Updated by Brett Smith over 8 years ago

  • Description updated (diff)
  • Category set to API
Actions #2

Updated by Tom Clegg over 8 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.
Actions #3

Updated by Brett Smith over 8 years ago

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

Updated by Brett Smith over 8 years ago

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

Updated by Brett Smith over 8 years ago

  • Description updated (diff)
Actions #6

Updated by Radhika Chippada over 8 years ago

  • Status changed from New to In Progress
Actions #7

Updated by Nico César over 8 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).

Actions #8

Updated by Radhika Chippada over 8 years ago

Moved the print statement from the library into the script.

Actions #9

Updated by Nico César over 8 years ago

review 263cd68f5ae4b114d3c1c89f84be46b0f64f9c9e

LGTM

Actions #10

Updated by Radhika Chippada over 8 years ago

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

Applied in changeset arvados|commit:efb5501e40de0d49c285db0d7a22ff8a8593832c.

Actions

Also available in: Atom PDF