IAM Roles and Policies

Exoscale offers multiple ways to interact with the platform, e.g.:

• in a programmatic way, from either a command line, your favorite programming language, or some of our integrations to 3rd party tools.
• via the web portal, using a simple UI.

In all cases you will probably be confronted with Identity and Access Management (IAM). IAM defines who can do what on your platform, would that be a person or a service.

IAM is composed by 2 main building blocks:

• Roles, which act as a container for a single Policy and add some options on top of it
• Policies, which are a set of rules describing what can and what cannot be done

IAM Authorization flow

IAM decouples authorization from authentication. Therefore, we can split authorization through several levels or “gateways” for a single request.

• The Organization Policy applies to any User or API Key within an organization.
• The Role Policy is assigned to one or more API Keys or Users.

A request must be authorized at both levels to be processed by the platform. The Organization Policy defaults to an empty set of rules, allowing all operations to be performed.

IAM Roles

A Role is a way to store a Policy:

{
  "name": "my-new-role",
  "policy": {
    "default-service-strategy": "deny",
    "services": {
      "iam": {
        "type": "allow"
      }
    }
  }
}

In the example above, the role called "my-new-role" contains a Policy stating that all operations are denied except for IAM services, which are explicitly allowed.

A Role can have one and only one Policy. Roles can then be assigned to one or more API Keys or Users, applying the permissions stated in its Policy.

IAM Policies

A Policy is composed of

• The Services map - a separation of the authorization logic according to which service class the request belongs to.
• The Default Service Strategy - a default top-level allow or deny decision that applies when there is no entry in the services map for the service of the incoming API operation. For example: list-zones is an operation that belongs to the compute service - if compute is not present in the services map, the default service strategy will be applied.

{
  "default-service-strategy": "allow",
  "services": {
    "compute": {...},
    "dbaas": {...}
  }
}

Requests are evaluated in the context of the service class they belong to - Compute, SOS, DBaaS, etc - a Policy can define one of the following authorization bodies for each service:

• Nothing - in the absence of a specification, use the default service strategy
• Allow overrides the default service strategy - allow all requests.
• Deny overrides the default service strategy - deny all requests.
• Rule-based a more fine-grained approach to authorization