IAM controls what can be done by whom. That “whom” can be e.g.:

  • a person accessing the web portal
  • an API key used by a client as e.g. the CLI, or Terraform

Once you have created a Role and defined a Policy, you can then proceed to create an API key or invite a new user to your Organization.

Users management

Users of an Organization are people that have access to the UI and can control or verify your cloud infrastructure and platform from the web portal.

See here for differences between Users and Organizations.

Owner Role

When creating a new Organization, would that be during registration or at a later point in time, the new Organization will be provisioned with a special default “Owner” IAM Role.

This Role cannot be modified or deleted, and is available to all Organizations. It contains an empty policy, meaning it allows all kind of operations on the platform.

The user that creates a new Organization becomes automatically its Owner: that is, it will be associated to the Owner Role.

Owner roles can also perform special actions, that might be shared with other special default roles, as e.g managing payments and billing.

An Organization can have more than one Owner, but always at least one Owner must be present. You can hence use the Owner role when you invite other people to your Organization, giving them the same privileges you have.

Billing Role

On top of the default “Owner” Role, any new Organization also gets a special “Billing”.

As for the “Owner” Role, the “Billing” role cannot be modified or deleted. With its “deny-all” policy, it’s only allowed to manage administrative and billing information. “Billing” role cannot manage any resources deployed on Exoscale, or perform organizational management.

Inviting new Users

If you want other people to have access to your Organization via the web portal, you can invite them to join it.

If the person you have invited, identified by their email, has already an Exoscale account, they will be simply added to your Organization. Otherwise they will receive an email with instructions on how to create an account on Exoscale, and once the process completed, they will have access to your Organization. No payment is required during this process, and there is no added cost for adding a user.

Generally, all users are subject to the IAM authorization flow. You need to define a proper IAM Role and its related IAM Policy in order to invite a new user in a role that is not Owner.

When inviting users, you will be able to select the target IAM Role for them, including the two default roles “Owner” and “Billing”.

It is of course possible to declare a more complex Policy, restricting e.g. IAM management, allowing some users to operate on only specific parts of the UI, or have only read access, and so on. Please refer to the IAM Policy Guide for more information.

Note

If you are familiar with user management at Exoscale prior of IAM, you can refer to that guide in order to see how a generic Tech role could be translated.

You can control the status of an invitation at any time, and while the invitation is pending, you can change the Role if you have changed your mind.

Owners, and users with IAM rights, can edit a Policy if the Role has been created as editable at any time.

As an Owner, it is possible to change the Role of a user, and to remove the user from your Organization at any time.

Note

Given the power and granularity of IAM Roles, the web portal does not adapt to what is allowed or not. A Role with a restricted Policy will still be shown a complete navigation menu, but will potentially receive a number of API errors denying requests for resources that have been denied in the Policy.

Actions performed by Users will be clearly identifiable in Audit Trail by the user UUID.

API Keys

As for users, API Keys can be created associating them a Role with its related Policy.

While the basic principles are the same as for Users, an API Key is intended to be used programmatically, does not give access to the web portal, and cannot be directly associated to a user.

When creating a new API Key, you can define the associated Role.

Contrary to Users, it is not possible to modify the IAM Role of a key. The key’s secret is shown only once at creation time, and cannot be recovered afterwards.

Actions performed by an API Key will be clearly identifiable in Audit Trail by the key itself.