Role based access control

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.

• Principal: The "subject", or the identity the rule applies to e.g. Bob the Contractor. Principals in the Triton are users.
• Action: The "verb", or the action a user takes e.g., PutObject, CreateJob
• Resource: The "object", or target of the action e.g., machine, Manta object
• Context: Any extra constraints e.g. "between 08:00-17:00", "from eu-ams1"

NOTE: RBAC is not related to providing authority for non-account owners to raise MNX support tickets. Please contact MNX support (https://portal.mnxsolutions.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

• are part of the user's limit set of roles, and
• are active for the request, whether by default or explicitly specified, and
• are in the list of role tags on the resource.

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:

• that resource is tagged with a role
• that role is active
• that role has a policy
• that policy contains a rule which explicity GRANTS access to that resource

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.