Role based access control

Modified: 04 Oct 2017 16:56 UTC

Access control allows you to control access to your data by specifying rules that describe who can access what and under what conditions. Rules can be broken down to four logical components.

NOTE: RBAC is not related to providing authority for non-account owners to raise Joyent support tickets. Please contact Joyent Support (https://help.joyent.com) if you wish to authorise additional people to raise support requests on your behalf.

Rules for access control for Triton are written with the Aperture access control language. With Aperture, you can define rules with each of the components above in a human-readable way.

For a request to be authorized, the principal, action, resource, and context for the request are evaluated against any relevant rules. If any of the rules grant access, the request is authorized. The Aperture evaluation engine is used to authorize requests.

When making a request as a user, a list of rules along with the request context is evaluated using Aperture. The list of rules comes from a set of roles that are relevant to this request. Relevant roles are the roles that

For a rule to evaluate to true, the action and conditions from the rule have to match the action and conditions from the request.

If any of the rules from the relevant roles evaluate to true (an OR across rules), the request is authorized.

As mentioned earlier, the policies' rules use Aperture Policy Language, with the following basic format:

<principals> CAN <actions> <resources> WHEN <conditions>.

In the case of CloudAPI or Manta (Triton's object storage and converged analytics solution), <principal> is always the user performing the request. Likewise, <resource> is the Manta object or CloudAPI URL of such request.

Therefore, Manta and CloudAPI's Aperture rules have the format:

        CAN <actions> WHEN <conditions>

By default, the access policy will DENY any attempt made by any account user to access a given resource, unless:

For example, a user with an active role read, which includes a policy rule like CAN listmachines and getmachines will not get access to resources like /:account/machines or /:account/machines/:machine_id unless these resources are role-tagged with the role read too.

Additionally, given that the <actions> included in the policy rule are just listmachines and getmachine, the user will be able to retrieve a machine's details provided by the GetMachine action, but will not be able to perform any other machine 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.