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.

Architecture overview

Traditional identity configurations in OpenStack, such as local Keystone user databases or direct LDAP integrations, introduce operational complexity, security risks, and scalability limits. Local authentication fragments identity management and prevents the use of enterprise security controls like MFA, centralized password policies, or lifecycle automation. Direct LDAP integrations, while centralizing credentials, still require service-specific configurations, dedicated bind accounts, and expose directory services directly to cloud components, increasing the attack surface and administrative overhead.

Federated authentication through identity providers such as Keycloak provides a modern, standards-based approach using OpenID Connect (OIDC) to bridge enterprise identity systems with OpenStack. This model centralizes user lifecycle management, enforces corporate security policies consistently, and simplifies the onboarding of new projects and users to the cloud through group-based authorization. It supports single sign-on (SSO), multi-factor authentication, and role-based access control with minimal manual intervention.

Major components and interactions

This section provides a high-level overview of the core components that enable federated authentication and authorization within a MOSK environment.

Enterprise directory (LDAP provider)

The enterprise directory acts as the central identity authority of the organization. Its primary function in this architecture is to authenticate users and define their group relationships according to corporate access policies. It exposes a standard LDAP interface that allows the central IAM system to verify credentials and retrieve identity attributes. The directory enforces organization-wide policies, such as password rotation, lifecycle management, and account security, ensuring consistent identity governance across all enterprise services, including the cloud platform.

MOSK central IAM (Keycloak)

Keycloak serves as the bridge between enterprise identity systems and the MOSK environment. It provides translation of LDAP-based identities into OpenID Connect (OIDC), a modern federation protocol for federated authentication. Acting as a single point of authentication, Keycloak enforces multi-factor authentication (MFA), single sign-on (SSO), and session management policies. A single Keycloak instance can act as a central IAM authority for multiple MOSK clusters, ensuring that authentication and identity claims are handled consistently across distributed environments.

MOSK Identity service (Keystone)

Keystone is responsible for access control and authorization within each MOSK cluster. It does not authenticate users directly but instead trusts the OIDC tokens issued by Keycloak. When a user presents an OIDC token, Keystone applies mapping rules to interpret the user identity and project membership. The Keystone function is to enforce cloud-level access policies that are consistent with the enterprise identity structure, without exposing internal directories or duplicating user data.

External cloud user onboarding system

These external systems or business processes orchestrate the cloud user identity lifecycle across the environment. When a user or a team requests access to the cloud, the system handles all necessary provisioning actions: creates or updates records in the enterprise directory, triggers synchronization in Keycloak, and establishes corresponding access structures in Keystone. This system ensures compliance with onboarding workflows, maintains synchronization across components, and removes manual administrative overhead. Such a system can be implemented based on a corporate ticketing system, automation scripts, or a third-party self-service portal.

Cloud user

A cloud user is the primary consumer of the MOSK environment. Before authenticating to the cloud, the user requests onboarding through an external onboarding system, initiating a standardized workflow that provisions the necessary resources in both the enterprise directory and OpenStack. Once onboarded, the user starts to interact with the cloud through the OpenStack CLI, dashboard, or cloud automation tools, such as Terraform, first, authenticating against Keycloak using corporate credentials. Upon successful authentication, Keycloak issues an OIDC token representing the user’s verified identity and memberships. The user software then presents this token to the target MOSK cluster Keystone endpoint to exchange it for an OpenStack token, which, in turn, authorizes operations on specific cloud projects and resources.

Data entities

This section outlines the principal data entities managed by each component in the federated authentication model and how these entities relate across systems. Understanding their roles ensures consistent and auditable identity management within MOSK deployments.

Enterprise directory (LDAP provider)

The enterprise directory serves as an authoritative repository of user and group information within the organization. It defines and maintains identity records that are consumed downstream by the federated authentication components:

• Users: individual identities, such as employees or contractors, that authenticate to corporate systems using credentials issued and managed by the organization.

• Groups: logical collections of users representing departments, roles, or access domains. Users can belong to multiple groups, and nested group membership is typically supported to simplify scalable access management.

• (Optional) Meta-group for cloud access: a designated container or organizational unit under which all cloud-related groups are organized using the membership relationship, allowing downstream systems, such as Keycloak, to scope synchronization to cloud-relevant users and groups in large corporate identity databases containing thousands of records, by filtering out records that are not associated with the meta group. For configuration details, refer to LDAP role mapping.

MOSK central IAM (Keycloak)

Keycloak serves as the central identity broker and federated identity provider within the MOSK ecosystem. It provides persistent representation of users and groups synchronized from the enterprise directory:

• Users: persistent records representing individual human identities synchronized from the enterprise directory. Each user in Keycloak corresponds to a directory user and retains references to key attributes, such as user name, email, and unique identifier. User lifecycle management (creation, update, deletion, password policies) remains the responsibility of the upstream directory, while Keycloak maintains synchronized replicas used for authentication and federation.

• Roles: persistent authorization objects representing access scopes or memberships derived from directory group relationships. Instead of mirroring directory groups directly, Keycloak maps them into roles through LDAP role mappers. These roles are typically organized under a dedicated client (for example, openstack) to clearly separate cloud-related access definitions from other enterprise applications.

• Role assignments: persistent associations between users and roles, automatically maintained during LDAP synchronization. These assignments reflect a user directory group memberships and define which OpenStack-related roles the user is entitled to upon authentication.

Through this structure, Keycloak bridges the LDAP model of the enterprise directory and the OpenID Connect (OIDC) federation expected by OpenStack. It stores synchronized user metadata and their role mappings, enforces enterprise authentication policies such as multi-factor authentication (MFA) and single sign-on (SSO), and issues OIDC tokens that encapsulate the user verified identity and associated roles.

MOSK Identity service (Keystone)

Keystone provides federated authentication and role-based authorization within each MOSK cluster. It consumes tokens issued by Keycloak and interprets the user federated identity and role information to determine access rights within OpenStack projects:

• Ephemeral users: session-based representations of federated identities derived from OIDC tokens issued by Keycloak. These user records are created dynamically at authentication time and are not available as persistent objects.

• Roles: static definitions of permission sets available within the cloud, for example, admin, member, reader. These roles are predefined by MOSK operators and remain consistent across all tenants and clusters.

• Groups, Projects, and Assignments: persistent authorization structures that define access boundaries within the MOSK cloud. These entities are provisioned automatically through the Keystone API by the external onboarding automation system during tenant onboarding.

  • Projects represent isolated environments for organizing workloads and resources, typically aligned with organizational or tenant boundaries.

  • Groups correspond to entities defined in the upstream identity system and must use names that match 1:1 with their corresponding LDAP groups to ensure correct mapping during authentication. Each project must have at least one associated group, for example, members of project X, to allow cloud users to access its resources. A common convention is to encode this relationship in the group name itself, for example, OPENSTACK_MYPROJECT1_MEMBER.

  • Assignments define the relationships between groups, projects, and roles, establishing what permissions each group has within a given project.

This model ensures that Keystone enforces access policies consistently while remaining fully decoupled from direct user and group management. All structural entities required for authorization are provisioned and maintained through standardized API-driven workflows executed by the external onboarding system.