Iscriviti per attivare i feed RSS

Red Hat OpenShift AI version 2.21 and later versions are now designed for Federal Information Processing Standards (FIPS). This achievement underscores our commitment to providing an enterprise-grade AI platform with a strong security posture that enables organizations to deploy and manage AI workloads with the highest levels of trust and compliance.

This is the first in a 2-part blog series of the introduction of this new FIPS capability. Part 1 describes what’s being done with OpenShift AI, and part 2 will be a practical discussion of FIPS in AI platforms for the US Federal Sector. 

The benefits for our customers

This "designed for FIPS" designation for OpenShift AI offers a number of  benefits, particularly for organizations with strict security and compliance requirements:

  • Increased testing: All releases of OpenShift AI after version 2.21 will undergo additional testing on OpenShift clusters in FIPS mode.
  • Streamlined compliance: For government agencies and regulated industries, working in a FIPS environment has been simplified. OpenShift AI provides the necessary foundation for AI operations on an OpenShift cluster in FIPS mode.
  • Consistency across hybrid cloud: Whether you're running OpenShift AI on-premises or in a FIPS-enabled cloud environment, you can expect consistent security and compliance capabilities.

What does "designed for FIPS" mean?

For many government agencies and regulated industries, adherence to FIPS 140 is not just a best practice—it's a strict mandate. FIPS sets rigorous standards for cryptographic modules, so sensitive data is protected with validated encryption methods.

When we say OpenShift AI is "designed for FIPS," it signifies that the underlying components have been built and tested so when OpenShift AI is deployed on a FIPS-enabled OpenShift cluster, its cryptographic operations will use the FIPS-validated cryptographic modules provided by the underlying Red Hat Enterprise Linux (RHEL) operating system.

The journey to "designed for FIPS" for OpenShift AI

Achieving this designation is a testament to the dedication and expertise of our engineering teams. It involved a comprehensive effort to verify that every layer of OpenShift AI aligns with FIPS requirements. Key to this were three critical undertakings:

1. Upgrading to Universal Base Image (UBI) 9

The foundation of OpenShift AI's container images has been entirely upgraded to Red Hat Universal Base Image (UBI) 9. UBI 9, built on RHEL 9, brings with it a host of security enhancements and, crucially, a robust FIPS-ready cryptographic stack. By standardizing on UBI 9, we ensure that the cryptographic primitives used by OpenShift AI's components are backed by the FIPS 140-validated modules present in RHEL 9. This provides a secure and consistent base for all OpenShift AI workloads.

2. Setting relevant Go compiler flags for FIPS compliance

Many components within OpenShift AI are written in Go. To make sure that these Go binaries correctly use RHEL's FIPS-validated cryptographic libraries, our engineering team set all relevant Go compiler flags. This means that instead of using Go's standard cryptographic module, our compiled binaries correctly integrate with and utilize the FIPS-validated OpenSSL libraries provided by RHEL. This is a fundamental requirement for software operating in FIPS mode, so cryptographic operations are performed according to the stringent FIPS standards.

3. Increasing focus on release testing on clusters in FIPS mode

For several releases, we have tested OpenShift AI on FIPS clusters, but not all components were built to exclusively use FIPS-validated cryptographic modules. Therefore, our testing primarily focused on verifying OpenShift AI functionality on such clusters. Now, with components designed for FIPS compliance—potentially failing if non-FIPS cryptographic operations are attempted—our testing in this mode has increased in importance. 

With the OpenShift AI 2.21 release we have added some enhancements to our testing. First we run a static validation to make sure all our container images are built following the rules outlined above. Second, we run a full set of existing regression tests to verify that inter-component communication is error free. Third, we run a basic sanity test—using known published workshops like the Fraud Detection workshop with some modifications—to confirm we are only communicating with endpoints that support the Transport Layer Security (TLS) requirements.

An example of where this increased focus on testing highlighted a difference between FIPS and non-FIPS environments was where OpenShift AI on a FIPS-enabled cluster needs to interact with an external system. For example, if artifacts are being stored in an external object storage service, this external service will need to provide the ability to connect using either TLS v1.2 with EMS support, or TLS v1.3. For more information about this and to learn what options are available if a scenario occurs where neither of these options are available, see the following article from Red Hat: The TLS Extended Master Secret and FIPS in Red Hat Enterprise Linux.

Looking ahead

The "designed for FIPS" status for Red Hat OpenShift AI is a significant step forward in our commitment to delivering AI solutions with heightened security and simplified compliance tools. We understand the ongoing evolution of government and industry regulations, and we'll continue to invest in strengthening the security and compliance of our offerings.

We encourage our customers in regulated industries to explore the new capabilities of Red Hat OpenShift AI and use its “designed for FIPS” foundation to accelerate their AI initiatives with confidence. For more detailed information on configuring FIPS mode with OpenShift Container Platform and OpenShift AI, please refer to our official documentation.

Stay tuned for more innovations as we continue to push the boundaries of enterprise AI, always with security and trust at the forefront.

Other resources

resource

Definizione della strategia aziendale per l'IA: una guida introduttiva

Leggi questa guida introduttiva per scoprire come Red Hat OpenShift AI e Red Hat Enterprise Linux AI possono accelerare il percorso di adozione dell'IA.

Sugli autori

James first started at Red Hat in 2008 as a technical support engineer. Now he spends most of his time fondly looking at a vim editor in tmux session on a dark themed terminal and generally enjoys creating new software projects to solve problems.

Read full bio

Gerard works as a software engineer on the OpenShift AI team at Red Hat. He is very enthusiastic about free and open source software, security, and the environment.

Read full bio

Scott works as a software quality engineer on the OpenShift AI team at Red Hat.

Read full bio
UI_Icon-Red_Hat-Close-A-Black-RGB

Ricerca per canale

automation icon

Automazione

Novità sull'automazione IT di tecnologie, team e ambienti

AI icon

Intelligenza artificiale

Aggiornamenti sulle piattaforme che consentono alle aziende di eseguire carichi di lavoro IA ovunque

open hybrid cloud icon

Hybrid cloud open source

Scopri come affrontare il futuro in modo più agile grazie al cloud ibrido

security icon

Sicurezza

Le ultime novità sulle nostre soluzioni per ridurre i rischi nelle tecnologie e negli ambienti

edge icon

Edge computing

Aggiornamenti sulle piattaforme che semplificano l'operatività edge

Infrastructure icon

Infrastruttura

Le ultime novità sulla piattaforma Linux aziendale leader a livello mondiale

application development icon

Applicazioni

Approfondimenti sulle nostre soluzioni alle sfide applicative più difficili

Virtualization icon

Virtualizzazione

Il futuro della virtualizzazione negli ambienti aziendali per i carichi di lavoro on premise o nel cloud