Mirantis Container Cloud (MCC) becomes part of Mirantis OpenStack for Kubernetes (MOSK)!

Now, the MOSK documentation set covers all product layers, including MOSK management (formerly Container Cloud). This means everything you need is in one place. Some legacy names may remain in the code and documentation and will be updated in future releases. The separate Container Cloud documentation site will be retired, so please update your bookmarks for continued easy access to the latest content.

Workflows

This section describes the end-to-end workflows of identity and access management in the integrated MOSK environment.

The process consists of the following main phases:

  • Onboarding, where access entities are provisioned and synchronized

  • Authentication, where a cloud user performs federated login and gains access to OpenStack resources

Onboarding workflow

The onboarding workflow defines how new users or teams are granted access to the OpenStack environment. It ensures that all identity entities across systems - LDAP, Keycloak, and Keystone — are aligned and ready before the first login.

Onboarding workflow:

  1. Access request initiation. A cloud user (or a team owner) requests creation or update of a cloud project through the external onboarding system, for example, a self-service portal or ticketing workflow. The user also specifies the list of colleagues who need to have access to the project.

  2. Enterprise directory update:

    • The onboarding system creates or updates project-specific groups in the enterprise LDAP directory.

    • The groups membership defines who is allowed to access the corresponding OpenStack project. The user accounts specified in the request in step 1 get added to the groups.

    • Each such group must satisfy the configured LDAP filter, ensuring it is included in the synchronization scope of Keycloak.

  3. Keycloak synchronization:

    • The Keycloak LDAP federation provider detects the new or updated group during periodic or on-demand synchronization.

    • Through the LDAP role mapper under the os client, the group is converted into a corresponding Keycloak role.

    • The mapping ensures that users who are members of the LDAP group automatically inherit the matching role in Keycloak.

  4. OpenStack Keystone entity provisioning:

    • The onboarding system invokes Keystone APIs to create or update a corresponding project, group, and group-role assignments.

    • Group names in Keystone must exactly match the LDAP/Keycloak role names to ensure correct mapping at login.

    • This step finalizes the user access definition from a structural perspective, no manual Keystone administration is required.

At the end of the onboarding workflow, all relevant identities and access structures are prepared:

  • Groups representing OpenStack projects exist in the enterprise directory and match the synchronization filter. Requested users are members (memberOf) of the groups.

  • Users and roles reflecting the user group memberships are synchronized to Keycloak.

  • Matching projects, groups, and assignments exist in Keystone. No user authentication has yet occurred at this stage.

Authentication workflow

The authentication workflow describes the runtime sequence that occurs when a user logs in to the OpenStack environment. This process is fully automated and follows the OpenID Connect Authorization Code Flow (also known as, Authorization Code Grant Type).

Authentication workflow:

Note

The description below is simplified and does not cover all the details of OIDC communications happening under the hood.

  1. User login:

    • The cloud user initiates login either through the OpenStack CLI or Horizon.

    • The user is redirected to the Keycloak login page under the iam realm.

  2. Authentication in Keycloak:

    • The user authenticates with their corporate credentials stored in the enterprise LDAP directory.

    • Keycloak enforces any configured enterprise policies, such as multi-factor authentication (MFA).

    • Upon successful login, Keycloak issues an OIDC token for the user that contains the claims iam_username, email, and iam_roles.

  3. Token exchange with Keystone:

    • The OIDC token is presented to Keystone federation endpoint.

    • Keystone validates the token against public signing keys of Keycloak and extracts the expected OIDC claims.

  4. Federated mapping and role resolution:

    • Keystone applies the federation mapping using:

      • iam_username - user name

      • email - user email

      • iam_roles - group memberships

    • Keystone creates an ephemeral record to represent the logged-in user.

    • Based on the groups contained in iam_roles, Keystone assigns the user to corresponding projects and roles.

    • A scoped OpenStack token is then issued, stating the user access to the authorized projects.

  5. Access to cloud resources:

    • The scoped token is used by the user CLI or web session to perform operations on OpenStack resources, such as instances, volumes, networks, and so on.

    • The token remains valid until its expiration, after which the user must reauthenticate through Keycloak.