The diagram above shows how different IAM concepts mentioned on this page interact with one another.
A user account refers to a human who owns a Scaleway account. Your account bears your personal information and authentication methods required to access the Scaleway console. When you create your Scaleway account, an Organization is automatically created with you as the designated Owner.
An application (also known as an IAM application) is a non-human user in an Organization. IAM applications can be used when you want to create an API key that is not linked to a user, to give programmatic access to resources.
Note that applications cannot, by definition, have access to the Scaleway console, as they have only an API key and no account themselves (they are not accounts).
An API key is a unique identifier, used to authenticate requests made to the Scaleway API. An API key consists of an access key and a secret key. The access key is like a unique ID or username, and is not a sensitive piece of information. The secret key is more sensitive as it is like a password to authenticate the access key.
Previously, an API key was associated with a single Scaleway Project. The API key therefore had full read/write access to all resources in that Project, and only that Project.
With the introduction of IAM, an API key is now associated with an IAM user or application. This allows fine-grained access to be defined for the IAM user bearing the API key across different Organizations, Projects, and resources.
A group (also known as an IAM group) is a grouping of users and/or applications. Creating groups allows you to attach policies to multiple users and/or applications at the same time.
You are the Owner of the Organization that is created with your Scaleway account. However, when you are invited to another Organization of which you are not the Owner, you are a Guest in that Organization.
Similarly, you can invite other users to be Guests in your Organization. Whereas Owners have full rights and access to all resources and features in their Organization, Guests have only the rights and permissions given to them via policies.
Identity and Access Management allows you to share access to the management of your Scaleway resources in a controlled and secure manner.
This is achieved by inviting users to be Guests in your account’s Organization, and creating policies that define in a very fine-grained way exactly what permissions they should have for which resources in which of your Projects or across your whole Organization.
Similarly, you may participate as a Guest in someone else’s Organization, where you will have the precise rights that they accord to you using policies.
You can also create non-human users in your Organization, called IAM applications, in order to give applications programmatic access to your Scaleway resources.
An Organization is made of one or several Projects. When you create your Scaleway account, an Organization is automatically created, of which you are the Owner. When you create IAM rules, you can set their scope at Organization level.
This means you can give access to features managed at Organization level, like billing and IAM, to users, applications, and groups in your Organization.
The Organization ID identifies the Organization created with your account. It can be found on your Organization dashboard, in the Settings tab.
You are the Owner of the Organization that is created with your Scaleway account. Owners have full rights and access to all resources and features in their Organization. See also Guest.
A permission is a granular right, which is checked to determine whether to give access to an API endpoint. Permissions are grouped into permission sets to facilitate access management within policies.
Permission sets are the main components of IAM rules. They consist of sets of one or multiple permissions.
Permission set names contain descriptions that clearly explain their purpose. For example, a permission set that grants access to all actions you can perform on Instances is called: InstancesFullAccess.
Permissions sets (e.g.InstanceReadAccess) and their scope (e.g. “on Project A only”) make up IAM rules, which define the access rights that a principal (user, group, or application) should have.
Policies control user rights by defining one or more rules to apply to the attached principals (users, groups, or applications). A policy rule has two parts: permission set and scope.
For each policy rule, you specify one or more permission sets (e.g. “list all Instances”) and their scope (e.g. “on Project A only”). This therefore defines the actions that the principles can carry out on resources within the scope.
You can carry out actions on Scaleway Object Storage resources either via the Scaleway console, or via a third-party API or CLI, such as the AWS CLI, MinIOClient or Rclone. While the Scaleway console gives you the option to specify the Scaleway Project to carry out your Object Storage actions in, this option is not available via third-party API/CLI tools. These tools are based on a standard Amazon S3 programming interface, which does not accept Project ID as a parameter. Therefore, when you create a Scaleway API key with IAM, you are prompted to specify the API key’s preferred Project for Object Storage. This API key will always use this Project when carrying out Object Storage actions via any API/CLI. See our page on using API keys with Object Storage for more information.
A principal is the target of a policy. They acquire the rights and permissions defined in the policy. A principal can be an IAM user, an IAM application or an IAM group. Each policy can have a maximum of one principal attached to it.
Projects are groupings of Scaleway resources. Every Scaleway Organization has a default Project, and you can create new projects if necessary. By grouping resources into Projects, you can then define access differently for each Project.
For example, if IAM users within your Organization are working on building two different systems with Scaleway resources, you can group the resources for each system into different Projects. This then allows you to restrict IAM users’ access to only the Project they are working on. It also facilitates the separation of billing between Projects.
A Scaleway resource is either a product or a feature in the Scaleway Ecosystem. Examples of resources include Instances, Private Networks, Kubernetes Kapsule and Flexible IPs, to name a few.
A rule (also known as an IAM rule) is the part of a policy that defines the permissions of the policy’s principal, and the scope of these permissions. A policy can have one or many rules. Each rule consists of:
A scope, which defines where the permission sets should apply. At Scaleway, a scope can be at Project or Organization level.
One or more permission sets (e.g. “list all Instances”). A permission set consists of one or multiple permissions to perform actions on resources or features. Each permission set has a clear description, e.g. InstancesFullAccess, InstancesReadOnly, DatabaseFullAccess, BillingReadOnly.
The rule below defines various levels of access to different resources in Project A. The principal (user, group, or application) can create, list, delete and manage Instances and Databases, but for Object Storage can only list and read the resources:
A scope defines where permission sets should apply within a policy. At Scaleway, a scope can be at Project or Organization level.
Tags are key/value pairs that help you organize your users.
Keep in mind that:
key and valueA user (also known as an IAM user) is a human user in an Organization. They can be of two types:
Within each Organization, different IAM users can have different rights (defined through policies) to perform actions on resources.