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 시작하기: 입문자용 가이드
저자 소개
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.
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.
채널별 검색
오토메이션
기술, 팀, 인프라를 위한 IT 자동화 최신 동향
인공지능
고객이 어디서나 AI 워크로드를 실행할 수 있도록 지원하는 플랫폼 업데이트
오픈 하이브리드 클라우드
하이브리드 클라우드로 더욱 유연한 미래를 구축하는 방법을 알아보세요
보안
환경과 기술 전반에 걸쳐 리스크를 감소하는 방법에 대한 최신 정보
엣지 컴퓨팅
엣지에서의 운영을 단순화하는 플랫폼 업데이트
인프라
세계적으로 인정받은 기업용 Linux 플랫폼에 대한 최신 정보
애플리케이션
복잡한 애플리케이션에 대한 솔루션 더 보기
가상화
온프레미스와 클라우드 환경에서 워크로드를 유연하게 운영하기 위한 엔터프라이즈 가상화의 미래