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

엔터프라이즈를 위한 AI 시작하기: 입문자용 가이드

이 입문자용 가이드에서 Red Hat OpenShift AI와 Red Hat Enterprise Linux AI로 AI 도입 여정을 가속화할 수 있는 방법을 알아보세요.

저자 소개

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

채널별 검색

automation icon

오토메이션

기술, 팀, 인프라를 위한 IT 자동화 최신 동향

AI icon

인공지능

고객이 어디서나 AI 워크로드를 실행할 수 있도록 지원하는 플랫폼 업데이트

open hybrid cloud icon

오픈 하이브리드 클라우드

하이브리드 클라우드로 더욱 유연한 미래를 구축하는 방법을 알아보세요

security icon

보안

환경과 기술 전반에 걸쳐 리스크를 감소하는 방법에 대한 최신 정보

edge icon

엣지 컴퓨팅

엣지에서의 운영을 단순화하는 플랫폼 업데이트

Infrastructure icon

인프라

세계적으로 인정받은 기업용 Linux 플랫폼에 대한 최신 정보

application development icon

애플리케이션

복잡한 애플리케이션에 대한 솔루션 더 보기

Virtualization icon

가상화

온프레미스와 클라우드 환경에서 워크로드를 유연하게 운영하기 위한 엔터프라이즈 가상화의 미래