fix(iam): members migration MTA-6076 #5072
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
ldecarvalho-doc
added
type: new content
RoRoJ
approved these changes
Jun 5, 2025
Co-authored-by: Rowena Jones <36301604+RoRoJ@users.noreply.github.com>
bene2k1
approved these changes
Jun 5, 2025
crlptl
reviewed
Jun 5, 2025
| --- | ||
| meta: | ||
| title: IAM Guests to Members migration | ||
| description: Learn how to migrate IAM Guests to Members, including roles and API keys, with Scaleway's IAM introduction |
There was a problem hiding this comment.
We don't have "roles" as such - can we replace the word roles by permissions?
crlptl
reviewed
Jun 5, 2025
| A user (also known as an IAM user) is a human user in an Organization. Three types currently exist: | ||
|
|
||
| - **Owner**: You are the Owner of the [Organization](#organization) that was created with your account. | ||
| - **Guest**: You are a Guest when invited to another Organization of which you are not the Owner. |
There was a problem hiding this comment.
Maybe we can add something like.
You are a Guest when invited to another Organization of which you are not the Owner. As a prerequisite, you mustown your own Organization on the side
crlptl
reviewed
Jun 5, 2025
|
|
||
| | Feature | Guests | Members | | ||
| |:--------:|:---------:|:---------:| | ||
| | 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 each of their Organizations separately to access them. If they log into an Organization, then want to access a different one using the same email, they must log out of the former first. | |
There was a problem hiding this comment.
Nope this does not change :)
It is ot deployed yet but it will be deployed on the 18th
the capacity to switch between member and owner and guest accounts who share the same email address remains the same, with the same User experience (Organization switch) as today between owner and guests
crlptl
reviewed
Jun 5, 2025
| | 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 each of their Organizations separately to access them. If they log into an Organization, then want to access a different one using the same email, they must log out of the former first. | | ||
| | 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. | | ||
| | 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. | | ||
| | 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. | |
There was a problem hiding this comment.
More especially, email address, member name, and passwords can be edited by an IAM admin and MFA can be deactivated by an IAM admin
| | 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 each of their Organizations separately to access them. If they log into an Organization, then want to access a different one using the same email, they must log out of the former first. | | ||
| | 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. | | ||
| | 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. | | ||
| | 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. | |
There was a problem hiding this comment.
Suggested change
| | 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. | | |
| | 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 a 100% manageable resource - they can be created, updated, locked and deleted by Organization admins. | |
Very minor spelling mistake
| | 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. | | ||
| | 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. | | ||
| | 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. | | ||
| | 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. | |
There was a problem hiding this comment.
Suggested change
| | 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. | | |
| | 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 with the security requirements](/iam/how-to/comply-with-sec-requirements-member) set for the Organization to ensure their continuous access. | |
Match the page's name
| | 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. | | ||
| | 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. | | ||
| | 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. | | ||
| | 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. | |
There was a problem hiding this comment.
Suggested change
| | 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. | | |
| | 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 they exist solely in that 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. | |
Proposal, the text was weird to me
|
|
||
| ### What remains the same? | ||
|
|
||
| | Feature | for Members | |
There was a problem hiding this comment.
Suggested change
| | Feature | for Members | | |
| | Feature | For Members | |
| description: Learn how to migrate IAM Guests to Members, including roles and API keys, with Scaleway's IAM introduction | ||
| content: | ||
| h1: IAM Guests to Members Migration | ||
| paragraph: This page guides you through the process of migrating IAM Guests to Members, covering key aspects such as roles and API keys, following the introduction of IAM on Scaleway |
There was a problem hiding this comment.
following the introduction of IAM on Scaleway
Isn't this the "Scaleway's IAM introduction" like in the meta description?
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.