Cloud Services

ModernOps configuration

User invitations
Published On Sep 04, 2024 - 11:25 AM

User invitations

Discover how to use IAM to invite new users to your platform and assign them roles, access groups, and access policies.
The main benefit of inviting users with the IAM model is that you get to onboard your users very quickly, so they can start using the platform with the required level of access level that you grant them.
You have the capability to add them with a
Viewer
 Administration role binding access only, which is the default permission, or you can enhance the level of access by refining it via Access Groups and Access Policies.
The following permissions are needed to be able to invite users to your platform. The
Platform Administrator
 role, which is the out-of-the-box role granted to you when the account is first created, is the only role that includes all these permissions. Alternatively, as a
Platform Administrator
, you can create Custom Roles and assign them the permissions needed to invite users.
Permission
Description
iam.invitations.view
Allow to view invitations
iam.invitations.create
Allow to create invitations
iam.invitations.update
Allow to update invitations
iam.invitations.resend
Allow to resend pending invitations
iam.invitations.delete
Allow to delete invitations

Accessing the Users page

The IAM Users page allows you to invite new users to the platform and manage their permissions quickly and efficiently.
To invite new users, follow these steps:
  1. Access the IAM page.
  2. Select Users from the left navigation bar of the page. The users page opens.
  3. Click Add New.
  4. Select Invite Users. The Invite Users page opens.
Step 1: Enter Email Address(es)
  1. Optionally, click the
    Invitation advanced settings
     down arrow to be able to change:
    • The email invitation language (if different from the default).
    • The identity provider (if different from the primary).
  2. Enter the email address or group of email addresses of the users (separated by a comma or space).
  3. Click
    Invite
    , at the bottom right side of the
    Summary
     pane if you want to invite the user with only the default permissions.
If the user is invited directly with no additional Access Policies or Access Groups, the default permissions assigned are:
  • Access Policy:
     Basic Access Policy with limited Platform permissions granted through a Viewer out-of-the-box existing Role.
  • Additional role binding:
     Viewer.
Later, you can add the user to an existing Access Group or you can add an Access Policy directly to the user.
Alternatively, if you want to grant the user with more permissions, other than the default, instead of clicking Invite, click
Continue
 to add those Access Groups and Policies.
Step 2: Add users to Access Group(s)
  1. Select one or more Access Groups by clicking
    Add
    . If no Access Groups have been created, the list may be empty.
  2. Click
    Continue
    .
Step 3: Additional Access Policies
  1. Select a service from the dropdown menu.
  2. Select the scope.
    • All Resources:
       The scope for that Access Policy covers all resources within the IAM platform.
    • Resources based on selected attributes:
       The scope for that Access Policy is based on Access Tags and Attributes.
  3. Select the Platform role or roles required.
    • A tag number lets you know how many permissions are associated to that specific role. Click said tag number to learn about the permissions' descriptions.
    • If you need to tailor the permissions that you need to add to a user, you can create your own Custom Roles.
  4. Click
    Add
    .
You can optionally add more Access Policies that can be reviewed in the Summary Pane. The
Summary Pane
 displays the parameters you have chosen to give your new user. Here, you can remove or update an Access Policy before you click
Invite
 to finish. This could mean that the user can have different Access Policies to navigate through the different subscriptions. For example, one
Viewer Platform
 Access Policy, and one
Administrator DevOps Intelligence
 Access Policy.
The new
User
 has been invited. You can now manage the invitation in the pending invitations  tab, until the user has accepted and activated the account.
To facilitate invitations and save time, the system allows to send bulk invitations by adding up to 100 email addresses separated by comma or space.

Administration role bindings and Core App roles

Behavioral Caveats
  • Administration role binding
     is a construct from the previous Role Based Access Control (RBAC) model that will continue to be temporarily available until the new authorization model is fully adopted. A role binding grants the permissions defined in a role to a user or set of users. It holds the user record and a reference to the role being granted as defined in RBAC. Currently, role bindings will continue to grant permissions for certain apps that are still supporting the legacy RBAC while it adopts the new authorization model, for example DevOps Intelligence.
To manage the role bindings for the apps that continue to support the legacy RBAC, follow these steps:
  1. Access the IAM page.
  2. From the
    Users
     list, select the User whose role you want to manage. The
    Member Details
     page opens.
  3. Scroll to the
    Members Resources
     section and click the
    overflow menu
    .
  4. Select
    Manage Role Binding
     and make the required updates.
    • Core App roles
       are a legacy construct that are assigned to users to provide access to specific role-based functions within subscriptions using Role-Based Access Controls (RBAC) for enabling the right level of access as needed. Currently, App roles will continue to be supported by some applications while it adopts the new authorization model, for example Cost and Asset Management (CAM), Enterprise Marketplace, and AIOps.

Administration Platform roles

The different Administration Platform roles available when inviting users are groupings of permissions that allow the assigned users to perform a limited set of actions depending on their business needs.
This enables a Role-based access control (RBAC) that maps a user to a role. The RBAC role defines the type of access that an identity with the RBAC role can take against a resource. RBAC roles are usually defined based on job responsibilities within an organization. The RBAC role grants the access that is needed for an identity to do its job. This is a simple model because IAM administrators manage the mapping of RBAC roles to an identity. RBAC roles setup is normally simpler than Attribute-based access control (ABAC) initial setup.
When inviting users, you are presented with the following Administration Platform roles:
  • Administrator
    : has full administrative access to IAM. This is the only role that can invite, edit and delete users from the Platform. It is the role given to the first user of the platform.
  • Editor
    : has limited administrative access to IAM.
  • Viewer
    : can view public IAM information and take action on their user IdP preferences.
  • Operator
    : has limited administrative access to IAM, as well as performing platform actions required to configure and manage services.
To learn more about the specific permissions and descriptions for each of the roles, navigate to the Roles page in your Kyndryl Modern Operations Applications and follow these steps:
  1. Access the IAM page.
  2. Select
    Roles
     from the left navigation bar of the page. The Roles page opens and a list of roles become available.
  3. Click the tag number that appears next to the Role name, and you will be able to scroll through all permissions and descriptions assigned to that specific role.

Understanding the Editor and Operator roles

Hierarchically,
Operator
 and
Editor
 have a different approach, and their position in the hierarchy depends on the lens you use to look at them. While
Operator
 is higher than Editor in the goal to perform actions in Administration to enable and operate services or subscriptions,
Editor
 is higher than Operator in the goal of helping the Administrator managing the platform but without full privileges.
Operator
: is able to perform platform actions required to configure, enable and operate services and subscriptions, such as CRUD connections (Operator currently can only View/Test Connections) or update existing Resource Groups. Subscriptions also need to focus on contributing with app permissions required for this role to configure, enable and operate those services and applications.
Editor
: is able to perform all edit actions in Administration Services , delete users, delete invitations, Access Policies, IdP create/delete. Subscriptions also contribute with app permissions to this role but with a different approach from that one of the Operator.
Do you have two minutes for a quick survey?
Take Survey