Under the Hood
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.
The "subject", or the identity the rule applies to e.g. Bob the Contractor. Principals in the Joyent Cloud are users.
The "verb", or the action a user takes e.g., PutObject, CreateJob
The "object", or target of the action e.g., machine, Manta object
Any extra constraints e.g. "between 08:00-17:00", "from eu-ams1"
Rules for access control for Joyent Cloud 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,
<principal> is always the user performing the request.
<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
GRANTSaccess to that resource
For example, a user with an active role
read, which includes a policy rule
CAN listmachines and getmachines will not get access to resources like
/:account/machines/:machine_id unless 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 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.