The diagram above shows how different IAM concepts mentioned on this page interact with one another.
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.
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.
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:
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 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.
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:
- Projects group your Scaleway resources (e.g. Instances, Object Storage buckets, Managed Databases etc.) together. An Organization may have many Projects, or just one default Project. If you choose to define scope at Project level, you can select one, many, or all Projects. When you then define the permission sets for this scope, you can give access to different resources within the Project(s).
- An Organization is made of one or several Projects. Billing, IAM, Project management and support are all managed at Organization level, so choose the Organization scope to give access to these features.
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.
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:
- Project A
- PERMISSION SET
- InstancesFullAccess, ObjectStorageReadOnly, DatabasesFullAccess
A user (also known as an IAM user) is a human user in an Organization. They can be of two types:
- Owner: You are the Owner of the Organization that was created with your account.
- Guest: You are a Guest when invited to another Organization of which you are not the Owner. Similarly, you can invite other users to be Guests in your Organization.
Within each Organization, different IAM users can have different rights (defined through policies) to perform actions on resources.