管理users和permissions

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

权限

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-remove
• tsuru role-list
• tsuru role-permission-add
• tsuru role-permission-remove
• tsuru role-assign
• tsuru role-dissociate
  关于每个命令的更多的细节可以参考client documentation。

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

从现在开始，名为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权限。

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

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

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

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

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

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

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

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

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