Jump toUpdate content
This document explains how features including roles and API keys have been automatically migrated with the introduction of Identity and Access Management (IAM).
Identity and Access Management (IAM) brings a wealth of new features to your Scaleway account, allowing you to control and manage access in a much more fine-grained way than ever before. All existing configuration and functionality is automatically migrated into IAM for you, from the configuration of members and roles, to API keys.
The table below summarizes the key account and access management features that Scaleway offered prior to IAM, and if/how they change with IAM’s introduction. For more information, see the relevant sections of this document below.
|Feature||Before IAM||With IAM||Notes|
|API keys||✅||✅||Prior to IAM, API keys were scoped at Project level and gave full read/write access to the associated Project. With IAM, API keys are now scoped at Organization level and inherit the exact permissions of the bearer. Existing API keys are automatically migrated to preserve the same permissions with the introduction of IAM.|
|Owner||✅||✅||The Owner of an Organization continues to have full rights and access to their own Organization, with no additional steps required to achieve this.|
|Members||✅||❌||With IAM, this is replaced by the concept of guests / IAM users of an Organization. Members are automatically migrated to be IAM users of the Organizations where they were members before.|
|Roles||✅||❌||With IAM, this is replaced by concepts of groups and policies. Members’ rights are automatically migrated for them via their addition to groups with pre-defined policies attached, in accordance with the rights that their Roles previously gave.|
Organizations and Projects
Organizations and Projects existed pre-IAM, and continue with the introduction of IAM.
Organizations: When you create a Scaleway account, an Organization is automatically created, of which you are the Owner. As the Owner you automatically get full permissions and rights for your own Organization.
Projects: You can create multiple Projects within an Organization, to enable you to group your resources. Each Organization has at least one Project, called default, to which all resources you create (Instances, Kubernetes Kapsules, Elastic Metal servers etc) are added if no other Projects are created. When you create new Projects, you can choose which Project to add resources to.
Any Projects that existed in your Scaleway account pre-IAM continue to exist with the introduction of IAM.
Members and roles
Before IAM, you were able to invite other Scaleway users to be a member of your Organization. When you did this, you had to select a role for them. There were four possible roles, each with different rights and permissions: Owner, Administrator, Editor and Billing Administrator.
With the introduction of IAM, members and roles cease to exist. They are replaced by the notions of IAM users, groups and policies.
- With IAM, you can invite other Scaleway account holders to be IAM users of your Organization. Whereas you are the Owner of your own Organization, other users are guests within it.
- You can then give these users the exact permissions and access rights you want them to have via policies. Policies are highly flexible and allow you to accord permissions in a very fine-grained way, giving different rights for different resources, Projects or Organization-level features.
- You can also create groups of users, to facilitate giving the same set of rights to many users at the same time.
Check out our documentation to find out how to invite users to your Organization, create groups and create policies.
Any Scaleway users who were members in an Organization pre-IAM have been automatically added to that Organization as IAM users.
In addition, three groups have been automatically created in each Organization. Users have been automatically added to the appropriate group, based on the role they had in that Organization pre-IAM. The groups are as follows:
- Administrators (mapping to the Administrator role)
- Billing Administrators (mapping to the Billing Administrator role)
- Editors (mapping to the Editor role)
For each group, a corresponding policy has been created, defining rules that give the same rights that their roles gave prior to the introduction of IAM.
Any pending invitations to your Organization are cancelled during the migration process. You can invite these users again if they still need to join your Organization.
Each user could create one or multiple API keys in order to use the Scaleway API. API keys were scoped at Project level, and gave full read/write access to the Project with which they were associated. Owners, Administrators and Editors could all generate API keys for a Project of an Organization, and use those API keys for any read/write operation on any resource in that Project.
With IAM, API keys are no longer scoped at Project level. Instead, API keys are associated with a single IAM user or IAM application, and inherit all their permissions from this user or application.
Each user can therefore generate one or several API keys in each of their Organizations, and these API keys give them whatever permissions have been accorded to them in that Organization via policies. Owners’ API keys therefore give them full read/write/delete access to everything in their Organization, while IAM users’ API keys may be more limited depending on the policies that have been set for them. Check out our API key documentation for more information.
In order to facilitate the migration of existing Project-scoped API keys to the new IAM system, IAM applications have been used.
An IAM application is a non-human user in an Organization. IAM applications may be used to create an API key that is not linked to a particular human user, to give programmatic access to resources.
- All API keys previously associated with a Project in an Organization have been attached to a newly-created IAM application in that Organization.
- For each application, a corresponding policy has been created and attached, defining rules that give the same rights to the Project as prior to the introduction of IAM. This ensures that anyone still using this API key continues to benefit from the same permissions as before.
This means that all pre-existing API keys are now attached to IAM applications, leaving IAM users without any API keys directly attached to themselves. You may decide yourself whether to leave these automatically-created IAM applications and policies in place, edit the policies to change permissions as required, or generate new API keys for individual users to define rights per-user via the creation of new policies for those users.