Managing users and permissions

Starting with tsuru 0.13.0 a new mechanism for managing users and permissionswas introduced. This new mechanism allows for fine-grained control on whichactions are available for each user. While at the same time trying to allowbroad permissions avoiding the need for interaction every time a new permissionis available.

To achieve this goal some concepts will be explained below.

Concepts

Permissions

tsuru includes a fixed number of permissions that may change on each release.To list all available permissions the command tsuru permission-list shouldbe used.

Permissions in tsuru work in a hierarchical fashion and are typicallyrepresented using a dot notation. Granting access to a top-level permissionimply access to all permissions below it.

As an example, consider the following permissions:

  • app.update.env.set
  • app.update.env.unset
  • app.deploy
    If a user have access only to app.update.env.set only this specific actionis available to them. However, it’s also possible to grant access to the broaderapp.update permission which will allow users to both set and unsetenvironment variables, but not deploy the applications. If we want to allow auser to execute all actions related to an application, the even broaderpermission app can be used.

Contexts

When applying permissions to a user one do so in regard to a context. Eachpermission declares which contexts can be used and it’s possible see theavailable contexts using the command tsuru permission-list. When apermission is assigned to a user it needs a context and a value for the chosencontext. Examples of available contexts are:

  • team
  • app
  • global
    If a user have the app.deploy permission for the team named myteamit means that they can only deploy applications which myteam has access. Thesame way, it’s possible to assign the same app.deploy permission to a userwith the context app for one application named myappname. This means theuser can now deploy this specific application called myappname.

The global context is a special case. It’s available to all permissions andmeans that the permission always applies. In the previous scenario, if a userhave the app.deploy permission with a global context it means that theycan deploy any application.

Roles

To better manage permissions it’s not possible to directly assign permissions tousers. First you have to create a role including wanted permissions and thenapply this role in regard to a context value to one or more users.

The following commands are available to manage roles and permissions and assignthem to users:

  • tsuru permission-list
  • tsuru role-add
  • tsuru role-remove
  • tsuru role-list
  • tsuru role-permission-add
  • tsuru role-permission-remove
  • tsuru role-assign
  • tsuru role-dissociate
  • tsuru role-info
    More details about each command can be found in the client documentation.

An example of the typical scenario for adding a new role and assigning it to auser is the following:

  1. $ tsuru role-add app_reader_restarter team
  2. Role successfully created!
  3. $ tsuru role-list
  4. +----------------------+---------+-------------+
  5. | Role                 | Context | Permissions |
  6. +----------------------+---------+-------------+
  7. | AllowAll             | global  | *           |
  8. +----------------------+---------+-------------+
  9. | app_reader_restarter | team    |             |
  10. +----------------------+---------+-------------+
  11. $ tsuru role-permission-add app_reader_restarter app.read app.update.restart
  12. Permission successfully added!
  13. $ tsuru role-list
  14. +----------------------+---------+--------------------+
  15. | Role                 | Context | Permissions        |
  16. +----------------------+---------+--------------------+
  17. | AllowAll             | global  | *                  |
  18. +----------------------+---------+--------------------+
  19. | app_reader_restarter | team    | app.read           |
  20. |                      |         | app.update.restart |
  21. +----------------------+---------+--------------------+
  22. $ tsuru user-list
  23. +-------------------+------------------+-------------+
  24. | User              | Roles            | Permissions |
  25. +-------------------+------------------+-------------+
  26. | admin@example.com | AllowAll(global) | *(global)   |
  27. +-------------------+------------------+-------------+
  28. | myuser@corp.com   |                  |             |
  29. +-------------------+------------------+-------------+
  30. $ tsuru role-assign app_reader_restarter myuser@corp.com myteamname
  31. Role successfully assigned!
  32. $ tsuru user-list
  33. +-------------------+---------------------------------------+-------------------------------------+
  34. | User              | Roles                                 | Permissions                         |
  35. +-------------------+---------------------------------------+-------------------------------------+
  36. | admin@example.com | AllowAll(global)                      | *(global)                           |
  37. +-------------------+---------------------------------------+-------------------------------------+
  38. | myuser@corp.com   | app_reader_restarter(team myteamname) | app.read(team myteamname)           |
  39. |                   |                                       | app.update.restart(team myteamname) |
  40. +-------------------+---------------------------------------+-------------------------------------+

From this moment the user named myuser@corp.com can read and restart allapplications belonging to the team named myteamname.

Default roles

It’s possible to have default roles that are applied to a user when some eventhappens on tsuru. Example of such events are user-create andteam-create. A list of all possible events can be found running the commandtsuru role-default-list. Commands tsuru role-default-add and tsuru
role-default-remove should be used to include or remove new roles in an event.

A common use for default roles would be replicating the behavior of tsuru onversions prior to 0.13.0. A new user would always be allowed to create a newteam and would also be allowed to create new applications on the newly createdteam.

To achieve this with default roles first two roles need to be created, let’scall them team-creator and team-member. team-creator would use theglobal context and include the team.create permission. team-memberwould use the team context and include the app permission.

With these roles created we only need to add them as default on the appropriateevent:

  1. $ tsuru role-default-add --user-create team-creator --team-create team-member

Adding members to a team

When managing teams, It’s very common to add new members to a team or add membersto a new team. To do this on Tsuru you’ll need to use role-assign command, asfollows:

  1. $ tsuru role-assign <role> <user@email.com> <team>

Migrating

When you already have an existing tsuru installation it will be necessary tocreate roles and assign them to all existing users, otherwise they will nolonger be able to execute any action in tsuru.

To make this process easier we created a migration to help with the transition.The goal of this migration is to roughly give all existing users the same set ofpermissions they already had on tsuru. To accomplish this it’ll create 3different roles: admin, team-member and team-creator.

The admin role will have a global context for the root permission and willbe assigned to all users that are members to the admin-team described intsuru.conf file. This users will be able to do anything, anywhere.

The team-member role will have a team context and the followingpermissions:

  • app
  • team
  • service-instance
    And will be assigned to all users for each team name the user is a member of.

The team-creator role will only include the team.create permission witha global context and will also be assigned to all users.

Also the role team-creator will be assigned as a default role when a newuser is created. And the team-member role will be the default role assignedto a user when they create a new team.

Running this migration is optional. If you choose execute it simply run:

  1. $ tsurud [--config <path to tsuru.conf>] migrate --name migrate-roles

Bootstrapping

For a new tsuru installation the first user created should have a role with aroot permission. To create this user a new command was created in the tsurudaemon application (tsurud) and should be executed right after itsinstallation:

  1. $ tsurud [--config <path to tsuru.conf>] root-user-create myemail@somewhere.com
  2. # type a password and confirmation (only if using native auth scheme)

原文: https://docs.tsuru.io/1.6/managing/users-and-permissions.html