Skip to content

Users

Uniqueness

Every user in the Controller (across all Orgs) is associated with a unique email address. A user can be associated with one or more Orgs (tenants).

Local vs SSO Users

Users can either be "Local Users" or "IdP Users".

Local Users

  • Lifecycle of these users is fully managed in the Controller.
  • Typically limited to privileged super/root users such as Org Admins.
  • Are locally authenticated by the controller.
  • Ensure you enable and require MFA in your Org for all local users.

IdP Users

  • Lifecycle of these users is fully managed in the customer's Identity Provider (IdP).
  • Typically for all non-privileged users such as developers, operations personnel etc.
  • Authentication and MFA is performed by the configured Identity Provider such as Okta, Azure AD etc.

The sequence diagram below shows the high level workflow that can used to secure user access using MFA. 

flowchart TD
    A[User Access Request] --> B{Type of User}
    B -->|Local User| C[Prompt for MFA]
    C --> E[Calculate Role]

    B -- SSO User ----> D[IDP Authenticates User]
    D --> E[Calculate Role]
    E --> F[RBAC Powered Access]

User Profile

Users can access/view their configured profile.

  • Click on the Email Address on the top right
  • Select Profile

Access User Profile

The user can now view their profile which describes what they are allowed to do on the platform.

Example 1

In this example, the user has

  • Access to All Projects in an Organization
  • Has the Role "Organization Admin"

View User Profile

Example 2

In this example, the user has

  • Access to the "Staging" Project
  • Has the Role "Project Admin" for the "Staging" Project

View User Profile

Onboarding Users

The user onboarding workflows are different for Local versus SSO Users. Only "Organization Admins" have the privileges to handle user lifecycle management.

Local Users

Every user in the Controller is associated with a unique email address. Users in an Org can have email addresses from different domains. This can be critical for Organizations that may

(a) Outsource operational tasks to a 3rd party entity especially for 24x7 coverage.

(b) Be required to provide Read Only access to an external auditor.

An admin of an existing Org can invite a new user to their Org. The new user is sent an email with a "temporary password" and instructions on how to access the Application Console. After logging in with the temporary password, the user will be required to create a new password for their account.

The temporary password is valid only for 72-hours.

SSO Users

Users that will access the Console are managed in the configured Identity Provider (IdP). Follow the documentation for SSO Integration for exact steps.

Machine Users

Users that only need to access the Controller programmatically using the APIs or CLI. This is well suited for CI systems such as Jenkins etc that will use the RCTL CLI to interact with the Controller.

  • As an Org Admin, navigate to the Users menu under System
  • Create New User
  • Ensure "Console Access" is disabled
  • Provide a username

Create Machine User

To generate and download the "access key and secret" for the machine user, as an Org Admin

  • Click on "Manage Keys"
  • Copy/Paste the generated access key and secret
  • Configure the RCTL CLI and test access to the controller

Create User

  • As an Org Admin, navigate to the Users menu under System
  • Provide the user's email address, first and last name
  • Select the "Groups" the user needs to belong to

By default, all local users belong to the "local users" group. Although access to this group allows the user to login into the Console, they will not have access to any resources.

Create User

Manage User Access

Logged in as an Organization Admin

  • Click on the User
  • The user details can be updated if required
  • Click on Groups to update the user's group assignments
  • Click on Projects to update the user's project assignments

View User Details

Admins can view and manage the entire list of locally managed users in their Organization.

  • In the Console, click on System
  • Click on Users

View All Users

Username

The username column displays the unique email address the user has to use to access the Console and their full name if it was provided during user creation.

Projects

This column displays all the Projects the user is authorized to access, the assigned role for the project and the group they belong to.

Last Access

This column displays the timestamp when the user last accessed the Controller.

Actions

A number of actions on the user can be performed. For example, the user can be deleted, user details edited etc.

Offboarding Users

Once users are created, admins are allowed to deactivate and delete users.

Deactivate User

The user will be temporarily blocked from being able to access the Controller via all channels (browser, CLI or REST API). This action is fully reversible by an Organization or Project Admin.

The Organization admin can deactivate a user by removing them from all Projects. In the example below, notice the reference to "No Projects assigned".

Deactivated User

When the deactivated user attempts to login, they will be presented with the following message.

Deactivated User

Delete User

The user will be permanently blocked from being able to access the Controller via all channels (browser, CLI or REST API). This action is NOT reversible and the user is permanently removed from the Org.

Important

Deletion or deactivation of a user from one Org does not block the user from accessing other Orgs they are allowed to access.

Revoke Kubeconfig

If required, admins can revoke a user's existing Kubeconfig (e.g. user lost their laptop with the Kubeconfig file). Once revoked, the user can download a new Kubeconfig to become productive again.

Revoke Kubeconfig

Download Kubeconfig

API type users can download the Kubeconfig using the Download Kubeconfig option

Download Kubeconfig

SSO Users

Administrators can also view the list of users that access the Controller via Single Sign On (SSO). Since these users are managed in the configured Identity Provider, they cannot be removed. However, admins can tune/configure certain aspects of what the SSO user can do.

IdP Users

Manage Groups

An IdP user might not be a part of any group at login and hence they won't have access to any of the projects. On login, that user gets placed in a gated area where they cannot access any projects.

Manage Keys

Clicking on the Manage Groups option shows the list of both IDP and other group(s) to which the users are added. IDP Groups represent the groups from incoming SAML request. The existing/new users can also be manually added to any groups within the organization. This allows the user(s) to be a part of both IDP and any other group(s)

To add users to a group,

  • Click Assign Group and select the required group(s) from the drop-down
  • Click Add
  • The users can be removed from a group any time using the Delete icon. The deleted groups from SAML request are re-added to the users again when they login

Manage Keys

If there are no groups under Managed Groups i.e assigned by org admin, the user will be a part of the IDP group.

Manage Keys

Use the Manage Keys icon to generate and download the API key and secret for the IdP user, as an Org Admin. Copy/Paste the generated access key and secret. This helps to configure the RCTL CLI and test access to the controller

Manage Keys

Kubeconfig Settings

Admins can configure/tune a specific SSO user's kubeconfig validity. A good example is when temporary access for a certain time period needs to be provided to a specific user. Admins can also require SSO users to have an active, authenticated session with the Console before they can use the downloaded Kubeconfig file.

IdP User Kubeconfig Settings

Revoke Kubeconfig

If required, admins can revoke a SSO user's existing Kubeconfig (e.g. user lost their laptop with the Kubeconfig file). Once revoked, the SSO user can download a new Kubeconfig to become productive again.

IdP User Revoke Kubeconfig

Authentication

Local users are authenticated and authorized by the Console. Authentication of SSO Users is performed by the integrated IdP such as Okta, Ping etc.

Password Complexity

All approved users in the Controller are required to create passwords that are a minimum of 8 characters in length.

MultiFactor Authentication (MFA)

We support and strong recommend the use of TOTP based MFA Authenticators to secure admin access to the Application and Ops Console. Once Admins enable MFA for their Org, all users in the Org will be required to use MFA. They will be automatically steered into a MFA enrollment workflow the next time they attempt to login.

Session Expiration

After a successful login, the user session is valid for 24-hours and will be required to authenticate again.

Default Blueprints

Enabling Default Blueprints allows all the roles to use the default blueprints and deploy them to clusters. Disabling this option allows ONLY org admins to use the default blueprints and no other user roles have that permission.

Auto Lockout Policy

Catalog Setting

Org Admins can enable or disable Catalog Setting to show/hide the apps from default-bitnami and default-helm Repository.

Auto Lockout Policy

Auto Lockout

Org Admins can optionally configure and enable an Org wide policy to automatically lockout users after "x" consecutive invalid login attempts in the specified time period. The defaults are "5" consecutive, invalid attempts in a 15-min time period.

Auto Lockout Policy

Auto Logout

Org Admins can optionally configure and enable an Org wide policy to automatically logout users after "x" minutes (default of 60-minutes) of no activity.

Auto Logout Policy

Self Service Password Reset

Users who have forgotten or misplaced their passwords can regain access to their Org via a self-service password reset workflow. They will be sent a password reset link via email (valid for 72-hours) that will allow them to reset their password.

API Keys

In addition to browser based access to the Console, users can also access the platform via the RCTL CLI and REST APIs. Access is secured via "API Keys". In order to manage their API Keys, users have to click on "My Tools" and Select "Manage Keys"

Manage Keys

  • API keys are uniquely generated for every user
  • Users can have one or many API keys associated with their Identity
  • Users can generate new APIs keys at any time.
  • Users can also delete API keys anytime.

API Authentication

All API calls are performed over a https protected, secure channel. Every API call is authenticated and access is authorized based on the user's role. An immutable audit trail is maintained centrally for all actions performed via APIs. 

sequenceDiagram
    participant API Caller
    participant Rafay Platform
    Note right of API Caller: https
    rect rgb(191, 223, 255)
    API Caller->>Rafay Platform: API Request (API Key)
    Note right of Rafay Platform: AuthN, AuthZ & Audit
    Rafay Platform-->>API Caller: Response
    end