• 管理users和permissions
    • Managing users and permissions
      • 概念
        • 权限
        • 上下文
      • 角色
      • 默认角色
      • 迁移
      • Bootstrapping

    管理users和permissions

    Managing users and permissions

    从tsuru0.13.0版本开始，引入了新的用户和权限管理机制。这个新的机制允许更好地控制每个用户可用的动作。当尝试允许更大的权限时，可以避免需要每次交互来判断新的可用权限。

    为了获得这个目标，一些概念需要在下面解释一下：

    概念

    权限

    tsuru包含一个固定的权限号，权限号可能在每次发布时会改变。为列出所有可用的权限，应该使用tsuru permission-list命令。

    在tsuru中的权限工作在水平的形式，且使用点符号来代表。授权获取高层次的权限意味着接入了所有下面的权限。

    比如，考虑下面的权限：

    • app.update.env.set
    • app.update.env.unset
    • app.deploy
      如果用户只有获取app.update.env.set的权限，那么只有这个特殊的动作是可用的。然而，也可能授权更大的app.update权限，允许用户set和unset环境变量，但是不能部署应用。如果我们想允许用户执行一个应用的所有相关的动作，更大的权限app可以被使用。

    上下文

    当给用户应用权限，必须在一个上下文去做。每个权限声明了在哪个上下文可以使用。可能的上下文可以通过使用命令tsuru permission-list来获取。当权限富裕一个用户，需要一个上下文和赋予给选定的上下文的值。可用的上下文的例子如下：

    • team
    • app
    • global
      如果用户有app.deploy的权限，为名为myteam的team，意味着他们只能部署myteam可以接入的应用。同样，可能带有app上下文赋予用户相同的app.deploy权限，为名为myappname。这意味着用户可以部署这个名为myappname的特定的应用。

    这个global上下文是一个特殊的情形。它允许所有的权限，意味着权限一直可以生效。在之前的场景中，如果用户有带有global上下文的app.deploy权限，意味着他们可以部署任何应用。

    角色

    为了更好地管理权限，不可能直接赋予用户权限。首先你必须创建一个包含想要的权限的角色，然后赋予这个角色一个上下文的值，这可以适用于一个或者更多用户。

    下面的命令可以用来管理角色和权限，然后赋予用户权限：

    • 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
      关于每个命令的更多的细节可以参考client documentation。

    增加一个角色，然后赋予它给一个用户的典型例子如下：

    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. +-------------------+---------------------------------------+-------------------------------------+

    从现在开始，名为myuser@corp.com的用户可以读取和重启所有属于名为myteamname的应用。

    默认角色

    当一些事件在偶然在tsuru上发生时，可能把默认角色赋予用户。这种事件的例子是user-create和team-create命令。所有可能事件的列表可以通过执行tsuru role-default-list命令获取。在一个事件中，可以使用命令tsuru role-default-add和tsuru role-default-remove来包含或移除新的角色。

    默认角色的一种常见使用方法是在0.13.0之前的版本上复制tsuru的行为。新的用户应该一直被允许创建新的team和被允许在新创建的team上创建新的应用。

    为了使用默认的角色达到这个目的，首先两个角色需要被创建，我们称之为team-creator和team-member。team-creator应该使用global上下文和包含team.create权限。team-member应该使用team上下文和包含app权限。

    使用这些创建的角色，我们只需要把他们作为默认值，在合适的事件上：

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

    迁移

    当你已经有安装了的的tsuru，有必要创建角色，然后赋予所有存在的用户，否则他们不能在tsuru中执行任何动作。

    为了让这个过程更简单，我们创建了一个迁移来帮助这种转换。这个迁移的目标是粗糙地给存在的用户已经在tsuru上拥有的相同的权限集合。为了实现这个目标，需要创建三种不同的角色：admin、team-member和team-creator。

    admin角色会有一个全局的上下文给root权限，并且会赋予给在tsuru.conf文件中描述的admin-team的所有成员。这些用户可以在任何地方做任何事情了。

    team-member角色有一个team上下文和以下的权限：

    • app
    • team
    • service-instance
      还会赋予给用户所属的team中的所有用户。

    team-ceator角色只会包含带有global上下文的team.create权限，也会赋予给所有的用户。

    角色team-creator也会被赋予默认角色，当新的用户被创建。team-member角色会是默认角色，被赋予一个用户当他们创建一个新的team时。

    执行这个迁移是可选的。如果你选择执行，只需要：

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

    Bootstrapping

    对于新的tsuru安装，第一个创建的用户应该有root权限的角色。为了创建这个用户，tsuru守护进程应用（tsuru）创建了一个新的命令。这个命令应该在它安装后马上被执行：

    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)

    原文: http://doc.oschina.net/tsuru-paas?t=52803