Project

General

Profile

Actions

Feature #9262

open

[API] Associate admin privileges with token instead of user account

Added by Peter Amstutz almost 8 years ago. Updated 27 days ago.

Status:
New
Priority:
Normal
Assigned To:
-
Category:
-
Target version:
Story points:
-
Release:
Release relationship:
Auto

Description

From an IRC brainstorm:

Best practices is for admin users to not have full admin rights at all times to avoid mistakes, however creating separate admin/non-admin is confusing and inconvenient.

Proposed solution: associate primary admin rights with API token instead of the user account;. When API server checks if current user is an admin, it checks the token, not the user account.

In normal usage, the user is granted a "regular" token and regular user access control applies. However, the "admin" flag on the user account grants the ability to issue admin tokens with the admin flag.

Workbench gains a "log in admin" and "log out admin" options which switch between admin/non-admin user tokens for the same account.

Actions #1

Updated by Peter Amstutz almost 8 years ago

  • Description updated (diff)
Actions #2

Updated by Nico César almost 8 years ago

depoyments needs lot's of admin actions like, that happen in random order. Here are examples.

standard objects:

~$ prefix=`arv --format=uuid user current | cut -d- -f1`
~$ echo "Site prefix is '$prefix'" 
~$ all_users_group_uuid="$prefix-j7d0g-fffffffffffffff" 
~$ repo_uuid=`arv --format=uuid repository create --repository "{\"owner_uuid\":\"$prefix-tpzed-000000000000000\", \"name\":\"arvados\"}"`
~$ echo "Arvados repository uuid is '$repo_uuid'" 

~$ read -rd $'\000' newlink <<EOF; arv link create --link "$newlink" 
{
 "tail_uuid":"$all_users_group_uuid",
 "head_uuid":"$repo_uuid",
 "link_class":"permission",
 "name":"can_read" 
}
EOF
~$ project_uuid=`arv --format=uuid group create --group "{\"owner_uuid\":\"$prefix-tpzed-000000000000000\", \"name\":\"Arvados Standard Docker Images\"}"`
~$ echo "Arvados project uuid is '$project_uuid'" 
~$ read -rd $'\000' newlink <<EOF; arv link create --link "$newlink" 
{
 "tail_uuid":"$all_users_group_uuid",
 "head_uuid":"$project_uuid",
 "link_class":"permission",
 "name":"can_read" 
}
EOF

object creations:
~$ prefix=`arv --format=uuid user current | cut -d- -f1`
~$ echo "Site prefix is '$prefix'" 
~$ read -rd $'\000' keepservice <<EOF; arv keep_service create --keep-service "$keepservice" 
{
 "service_host":"keep0.$prefix.your.domain",
 "service_port":25107,
 "service_ssl_flag":false,
 "service_type":"disk" 
}
EOF

arv --format=uuid virtual_machine create --virtual-machine '{"hostname":"shell.bd44f.arvadosapi.com"}'

tokens for services

apiserver:~$ arv api_client_authorization create --api-client-authorization '{"scopes":["GET /arvados/v1/virtual_machines/zzzzz-2x53u-zzzzzzzzzzzzzzz/logins"]}'
  arv api_client_authorization create_system_auth \
    --scopes "[\"GET /arvados/v1/jobs/queue\",
               \"GET /arvados/v1/nodes\",
               \"PUT /arvados/v1/nodes\",
               \"PUT /arvados/v1/nodes/\",
               \"POST /arvados/v1/nodes\",
               \"POST /arvados/v1/nodes/\"]" 

We've been doing all this as users, and there is a trackable actions who did what and when. If we implement privileges "sudo style" we should not loose the trackability.

Also take in account the user experience from the admin perspective. If we're going down the path of self discovery services, each services should bee able to add itself to the api without admin intervention. or at least to have a period of time (i.e. a Deployment flag somewhere) that lowers the need of a token just to make things easier to make deployments. The flag could be turned off once the deployment is done, of course.

Actions #3

Updated by Tom Morris over 7 years ago

We should be careful to not make Ops any more difficult than it already is, but deployments are a very small fraction of our usage. Perhaps we can have a special deployment account or Ops team members can have accounts which have admin privileges permanently enabled if we can't find a good sudo-style implementation that works for deployments.

I agree with the general trend of having developers, at least, run with admin privileges turned off most of the time. Otherwise too many errors and performance issues get masked.

Actions #4

Updated by Peter Amstutz about 1 year ago

  • Release set to 60
Actions #5

Updated by Peter Amstutz 27 days ago

  • Target version set to Future
Actions

Also available in: Atom PDF