IAM Migration

This document explains how features including roles and API keys have been automatically migrated with the introduction of Identity and Access Management (IAM).

Summary

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.

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

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 IAM

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.

Migration

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.

Note

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.

API keys

Before IAM

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

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.

Migration

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.

Note

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.