RBAC: Users, Roles & Policies
While the behaviour of the main account remains the same, including the SSH keys associated with it, it's now possible to have multiple Users subordinate to the main account. Each of these users have a different set of SSH Keys. Both the users and their associated SSH keys have the same format as the main account object (and the keys associated with it).
It's worth mentioning that the
loginfor an account's users must be different only between the users of that account, not globally. We could have an account with login "mark", another account "exampleOne" with a user with login "mark", another account "exampleTwo" with another user with login "mark", and so forth.
"name": "restart instances"
"name": "restart instances",
"CAN rebootmachine if requesttime::time > 07:30:00 and requesttime::time < 18:30:00 and requesttime::day in (Mon, Tue, Wed, THu, Fri)",
"description": "This is completely optional"
Our recommendation is to limit each policy's set of rules to a very scoped collection, and then add one or more of these policies to each group. This aids easily reusing existing policies for one or more roles, allowing fine-grained definition of each role's abilities.
<principals> CAN <actions> <resources> WHEN <conditions>.
You should refer to the Aperture documentation for the complete details about the different possibilities when defining new rules. This section will only cover a limited set strictly related to CloudAPI's usage.
In the case of CloudAPI,
<principal>will be always the user performing the HTTP request. Likewise,
<resource>will always be the URL of such request, for example
We add one or more roles to a resource to explicitly define the active roles a user trying to access a given resource must have. Therefore, we don't need to specify
<principal>in our rules, since it'll always be defined by the role-tags of the resource the user is trying to get access to. For the same reason, we don't need to specify
<resource>in our rules.
Therefore, CloudAPI's Aperture rules have the format:
CAN <actions> WHEN <conditions>
By default, the access policy will
DENYany attempt made by any account user to access a given resource, unless:
- that resource is tagged with a role
- that role is active
- that role has a policy
- that policy contains a rule which explicity
GRANTSaccess to that resource
For example, a user with an active role
read, which includes a policy rule like
CAN listmachines and getmachineswill not get access to resources like
/:account/machines/:instance_idunless these resources are role-tagged with the role
Additionally, given that the
<actions>included in the policy rule are just
getmachine, the user will be able to retrieve an instance's details provided by the GetMachine action, but will not be able to perform any other instance actions (like StopMachine). However, if the role has a rule including that
<action>(like StopMachine), or the user has an additional role which includes that rule, then the user can invoke that action too.
As an aside, the active roles of a user are set by the
default_membersattribute in a role. If three different roles contain the "john" user (amongst others) in their default-members list, then the "john" user will have those three roles as active roles by default. This can be overridden by passing in
?as-role=<comma-separated list of role names>as part of the URL, or adding a --role flag when using a node-smartdc command; provided that each role contains that user in their
memberslist, then those roles are set as the currently-active roles for a request instead.
CloudAPI uses replication and caching behind the scenes for user, role and policy data. This implies that API reads after a write on these particular objects can be up to several seconds out of date.
For example, when a user is created, CloudAPI returns both a user object (which is up to date), and a location header indicating where that new user object actually lives. Following that location header may result in a 404 for a short period.
As another example, if a policy is updated, the API call will return a policy object (which is up to date), but GETing that URL again may temporarily return a outdated object with old object details.
For the time being, please keep in mind that user, role and policy creation/updates/deletion may potentially take several seconds to settle. They have eventual consistency, not read-after-write.