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

Starting with MOSK 25.2, 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.

Federal Information Processing Standards (FIPS)

This section describes enabling and maintaining FIPS compliance in Mirantis OpenStack for Kubernetes (MOSK). It covers the concepts of FIPS compliance and certification, the importance of compliance, and how the latter applies to the host operating system, container runtime and Kubernetes components, and OpenStack and supporting infrastructure services.

What is FIPS?

The Federal Information Processing Standards (FIPS) are a set of publicly announced standards developed by the U.S. National Institute of Standards and Technology (NIST). They define security and interoperability requirements for cryptographic modules, data protection, and system integrity.

One of the most widely recognized is FIPS 140-3, which specifies security requirements for cryptographic modules used to protect sensitive information. It ensures that encryption algorithms, key management processes, and cryptographic implementations meet rigorous testing and validation standards.

FIPS compliance vs. FIPS certification

FIPS compliance requires that a system is configured to use only FIPS-approved algorithms and FIPS-certified cryptographic modules. Compliance is typically self-declared by the organization.

FIPS certification indicates that a cryptographic module has been formally tested and validated by NIST under the Cryptographic Module Validation Program (CMVP) and appears on the official NIST list.

To sum up, certification applies to cryptographic modules, while compliance applies to how you configure and use them.

Why FIPS compliance is important

FIPS compliance is mandatory for U.S. federal agencies and many organizations in regulated sectors, including healthcare, finance, and defense. It helps reduce security risks, ensures the use of validated cryptography, and demonstrates alignment with recognized government standards.

FIPS compliance is also a foundational prerequisite for higher-level certifications, such as the Federal Risk and Authorization Management Program (FedRAMP) — a U.S. government program that standardizes security assessment, authorization, and continuous monitoring for cloud services used by federal agencies.

Achieving FedRAMP certification:

  • Confirms adherence to stringent, prescriptive security controls

  • Simplifies procurement by federal agencies

  • Enables service operation in highly regulated markets

For MOSK, enabling FIPS compliance is a critical first step toward meeting FedRAMP and similar high-assurance security requirements. FedRAMP certification can significantly expand the value proposition for cloud providers by opening access to U.S. federal customers and other highly regulated industries and markets where verified security assurances are essential.

FIPS compliance in MOSK clouds

Enabling FIPS compliance in a MOSK deployment ensures that all cryptographic operations across control, data, and management planes use FIPS-certified modules and FIPS-approved algorithms.

Because MOSK integrates multiple software components, including Kubernetes, OpenStack services, and supporting infrastructure, FIPS readiness must be addressed holistically, covering the host operating system, container runtime, Kubernetes components, and OpenStack services. In addition, since MOSK is a highly flexible solution that supports diverse architectures and offers extensive customization capabilities in the field, achieving FIPS compliance requires a case-by-case approach that accounts for the specific characteristics of each MOSK deployment. However, major common building blocks apply broadly, and this section outlines the primary areas and approaches to achieving compliance:

  • Host operating system

    • All MOSK nodes (control, compute, and infrastructure) must run in the FIPS mode at the host operating system level. This ensures that system cryptographic libraries (for example, OpenSSL, libgcrypt) are FIPS-certified and non-approved algorithms are disabled.

  • Container runtime and Kubernetes components

    • Container runtimes, such as containerd and Docker, must be configured to leverage FIPS-certified libraries.

    • Kubernetes components, which include API server, controller manager, scheduler, and kubelet, must perform TLS and other cryptographic operations using FIPS-certified libraries.

  • OpenStack and supporting infrastructure services

    • All MOSK services, such as Identity (OpenStack Keystone), Images (OpenStack Glance), Block Storage (OpenStack Cinder), and Compute (OpenStack Nova), must use FIPS-approved ciphers for API endpoints and internal communication.

    • Python and Java components must rely on FIPS-validated cryptographic providers.

    • Databases, message queues, load balancers, and storage systems must use FIPS-approved cryptographic algorithms for encryption in transit and at rest.

Host operating system

MOSK relies on Ubuntu as the host operating system. Canonical provides FIPS 140-certified Linux kernels and cryptographic libraries, including OpenSSL, libgcrypt, and GnuTLS, through the Ubuntu Pro subscription (formerly known as Ubuntu Advantage). NIST-accredited labs validate these packages, and subscribers can use them in environments that require official FIPS compliance.

FIPS-certified Ubuntu availability

FIPS certification of the Linux kernel and cryptographic libraries often lags behind the release of a new Ubuntu LTS version and its introduction into MOSK. The certification process under the NIST Cryptographic Module Validation Program (CMVP) can take several months. As a result, organizations deploying FIPS-certified environments may need to use slightly older certified kernel versions instead of the latest LTS kernels. This trade-off guarantees compliance but may limit access to newer kernel features, performance improvements, and expanded hardware support.

Enabling Ubuntu Pro FIPS on hosts

To enable FIPS mode on Ubuntu hosts in MOSK clusters, you need an Ubuntu Pro subscription. Canonical provides certified Linux kernels and cryptographic libraries through dedicated FIPS repository channels, such as fips-updates (recommended), fips, and fips-preview.

Canonical documents the procedures for attaching a subscription, enabling the appropriate repository, and installing FIPS-certified packages. Operators should follow the official guidance published in the Canonical FIPS documentation.

After completing the steps described there, reboot hosts and validate compliance.

Managing Ubuntu Pro configuration in MOSK

You can manage Ubuntu Pro FIPS settings manually on each host through the CLI or centrally through configuration management systems. In MOSK, this process is best automated through the built-in host operating system configuration subsystem. Use the package module to manage installation of the FIPS kernel and cryptographic libraries. This ensures consistent deployment across all nodes, simplifies lifecycle management of FIPS packages, and integrates seamlessly with MOSK declarative configuration model.

Handling host OS upgrades in FIPS-enabled clusters

Upgrading Ubuntu hosts running in FIPS mode follows the same process as non-FIPS hosts but requires careful attention to compliance. Not every kernel in standard Ubuntu repositories is FIPS-certified. Attempting to use an uncertified kernel will break compliance.

Always upgrade using the fips-updates channel to ensure certified modules continue to receive security patches. After each host operating system upgrade, validate compliance by checking that FIPS is still enabled on the kernel and verifying package versions against Canonical certification documentation. If inconsistencies appear, re-enable Ubuntu Pro.

Test upgrades in a staging environment first to confirm both functionality and compliance before deploying to production.

Container runtime and Kubernetes components

MOSK relies on Mirantis Container Runtime (MCR) and Mirantis Kubernetes Engine (MKE) to provide a secure, production-grade Kubernetes underlay. To ensure FIPS compliance at this layer, both the container runtime and the Kubernetes control plane must perform all cryptographic operations through FIPS-certified libraries.

On the runtime side, MCR provides a FIPS 140-2 certified variant available through a dedicated update channel. Operators deploying MOSK in regulated environments should ensure that the FIPS-enabled build of MCR is installed, as documented in the MCR FIPS documentation. Environments using containerd instead of Docker also retain compliance, as containerd inherits its cryptographic functions from the same validated libraries when the FIPS-enabled variant of MCR is in place.

At the orchestration layer, MKE works seamlessly with MCR in FIPS mode. Mirantis has held FIPS 140-2 validation for MCR, MKE, and k0s since 2021, providing an integrated FIPS-capable solution across the container runtime and Kubernetes control plane. For details, see Businesswire Announcement.

For details on enabling and verifying FIPS mode in MKE, refer to MKE security documentation.

For MOSK operators, ensuring FIPS compliance at the container and orchestration layers primarily involves aligning the host operating system with FIPS requirements, deploying the certified MCR variant, and following the official guidance from Mirantis for runtime and Kubernetes configuration.

OpenStack and infrastructure services

Beyond the host operating system and Kubernetes base, FIPS compliance in a MOSK cloud also applies to the OpenStack control plane and the supporting services such as databases, message queues, load balancers, storage, and networking. To stay compliant, all these services must handle encryption, secure communication (TLS), and key management using FIPS-approved libraries.

Most OpenStack services rely on system-level cryptography through Python or OpenSSL. When MOSK runs on FIPS-enabled hosts, these services automatically use FIPS-validated cryptography. For more information, see OpenStack Technical Committee FIPS goal, which outlines the community-wide effort to run OpenStack services in FIPS mode by default and ensure that cryptographic operations across the stack comply with FIPS 140 standards.

Supporting services, such as MariaDB, RabbitMQ, Memcached, and Ceph, must also comply with FIPS rules. These programs typically inherit cryptographic behavior from the host operating system.

Networking in MOSK can be provided by Tungsten Fabric/OpenSDN as an option. Components such as virtual routers and control plane services rely on the same cryptographic libraries as the host. On FIPS-enabled hosts, these networking systems automatically use validated libraries for encryption, authentication, and secure communication between agents, controllers, and analytics services.

MOSK SSL/TLS proxy for API endpoints

Available since MOSK 23.3

TLS encryption for OpenStack APIs, networking, and any other services that expose endpoints through the Kubernetes ingress has been enhanced with a built-in SSL/TLS proxy. This proxy is part of MOSK ingress networking and performs user-to-cloud encryption with a FIPS-validated cryptographic module to ensure that external API traffic always complies with FIPS 140-2 requirements.