|
| 1 | +--- |
| 2 | +meta: |
| 3 | + title: IAM Guests to Members migration |
| 4 | + description: Learn how Scaleway has migrated features including roles and API keys with the introduction of IAM |
| 5 | +content: |
| 6 | + h1: IAM Migration |
| 7 | + paragraph: Learn how Scaleway has migrated features including roles and API keys with the introduction of IAM |
| 8 | +tags: iam |
| 9 | +categories: |
| 10 | + - iam |
| 11 | + - console |
| 12 | +--- |
| 13 | + |
| 14 | +This document explains how user management changes with the migration of IAM Guests to Members. |
| 15 | + |
| 16 | +## IAM Users |
| 17 | + |
| 18 | +A user (also known as an IAM user) is a human user in an Organization. Three types currently exist: |
| 19 | + |
| 20 | +- **Owner**: You are the Owner of the [Organization](#organization) that was created with your account. |
| 21 | +- **Guest**: You are a Guest when invited to another Organization of which you are not the Owner. |
| 22 | +- **Member**: You are a Member when you are added to an Organization by an Owner or user with IAM Manager permissions. Members exist only within the specific Organizations in which they are created. |
| 23 | + |
| 24 | +Whereas Owners have full rights and access to all resources and features in their Organization, Guests and Members have only the rights and permissions given to them via [policies](#policy). |
| 25 | + |
| 26 | +## IAM Guests become IAM Members |
| 27 | + |
| 28 | +From June 2025, IAM Guests will become IAM Members. The migration process will be carried out in two phases: |
| 29 | + |
| 30 | + - **Phase 1** - Starting on the *18th of July 2025*, the [manual migration of Guests]() will be available in the Console to all Owners and users with [IAMManager permissions](/iam/reference-content/permission-sets) until |
| 31 | + - **Phase 2** - Starting in *July 2025*, Guests that have not yet become members will be automatically migrated. |
| 32 | + |
| 33 | +### What changes? |
| 34 | + |
| 35 | +The table below summarizes the key account and access management features that Scaleway offered prior to IAM, and if/how they change with the introduction of Members. For more information, see the relevant sections of this document below. |
| 36 | + |
| 37 | +| Feature | Guests | Members | |
| 38 | +|:--------:|:---------:|:---------:| |
| 39 | +| Login | Guests logged into their own accounts and could access all Organizations they were a part of via the console. | Currently, Members must log into their Organizations to access it. If they are logged into a different Organization with the same email, they must log out before logging into the other. | |
| 40 | +| Enforcement of MFA | It was not possible to enforce MFA if a Guest in your Organization had not enabled MFA in their account. Organization admins could send reminder emails, but had to wait for the Guest to enable MFA, or remove them from the Organization to complete the enforce process. | When MFA is enforced in the Organization, Members have a [grace period](iam/concepts/#grace-period) to enable MFA in their accounts. This period is set by the Organization admins and starts as soon as a new Member is added. If they fail to enable MFA within this period, their accounts are locked. | |
| 41 | +| Password renewal | Guests were not required to renew their passwords to stay in an Organization. | As a security measure, Organization admins can require Members to renew their passwords within a grace period. If a password was attributed to Members upon their creation, they must renew this password after their first login. | |
| 42 | +| User management | Guest accounts and personal Organizations could not be managed by anyone other than them. Their permissions on Organizations they were invited to are the prerogative of Organization admins. | Member accounts are an 100% manageable resource - they can be created, updated, locked and deleted by Organization admins. | |
| 43 | +| Organizations | Guests were users who had their own personal Organizations and were invited into another. They had full management rights on their accounts and Organizations. If they were removed from an Organization, they would continue to have a Scaleway account. | Members exist only within an Organization and can be present in solely said Organization. Members cannot own Organizations. They must [comply to the security requirements](/iam/how-to/comply-with-sec-requirements-member) set for the Organization to ensure their continuous access. | |
| 44 | + |
| 45 | + |
| 46 | +### What remains the same? |
| 47 | + |
| 48 | +| Feature | Guests | Members | |
| 49 | +|:--------:|:-------:|----------| |
| 50 | +| Single Sign-On (SSO) | Available | Available | |
| 51 | +| Credentials (Password, SSO, MFA) | - | Members who previously existed as Guests maintain the same credentials configuration as before. | |
| 52 | +| Access control | - | Like Guests, Members are granted permissions to the Organization by way of IAM policies. | |
| 53 | +| API keys | - | The processes for creating, viewing and deleting API keys remain the same. | |
| 54 | + |
| 55 | + |
| 56 | +## How to manually migrate a user from Guest to Member |
| 57 | + |
| 58 | +<Message type="important"> |
| 59 | + The migration does not effect any impacts to your production. |
| 60 | +</Message> |
| 61 | + |
| 62 | + |
| 63 | + |
0 commit comments