Language Selection

English French German Italian Portuguese Spanish

Red Hat: OpenShift Releases, FIPS 140-2 and More

Filed under
Red Hat
  • Introducing Multi-Cloud Object Gateway for OpenShift
  • Introducing OpenShift Container Storage 4.2
  • Introducing Red Hat OpenShift 4.3 to Enhance Kubernetes Security
  • What’s new in the OpenShift 4.3 console developer experience

    The developer experience is significantly improved in the Red Hat OpenShift 4.3 web console. If you have used the Developer perspective, which was introduced in OpenShift 4.2 Console, you are probably familiar with our streamlined user flows for deploying applications, the new Topology view, and the enhanced experience around OpenShift Pipelines powered by Tekton and OpenShift Serverless powered by Knative. This release continues to improve upon the features that were introduced in 4.2 and introduces new flows and features for the developer.

  • Self Service Speedbumps

    In my case, there is a flavor that almost matches; it has 10 GB of Disk space instead of the required 25. But I cannot use it.

    Instead, I have to use a larger flavor that has double the VCPUs, and thus eats up more of my VCPU quota….to the point that I cannot afford more than 4 Virtual machines of this size, and thus cannot create more than one compute node; OpenShift needs 3 nodes for the control plane.

    I do not have permissions to create a flavor on this cloud. Thus, my only option is to open a ticket. Which has to be reviewed and acted upon by an administrator. Not a huge deal.

    This is how self service breaks down. A non-security decision (link disk size with the other characteristics of a flavor) plus Access Control rules that prevent end users from customizing. So the end user waits for a human to respond

    In my case, that means that I have to provide an alternative place to host my demonstration, just in case things don’t happen in time. Which costs my organization money.

    This is not a ding on my cloud provider. They have the same OpenStack API as anyone else deploying OpenStack.

  • How RHEL 8 is designed for FIPS 140-2 requirements

    Deploying software in a large organization is a challenging task when it comes to providing a consistent and reasonable level of security. Any number of vendors are involved in delivering software that addresses numerous needs of the organization, and that combination of software includes numerous claims and security mechanisms. How can an organization be made aware that all deployed software systems contain generally accepted and state of the art in today’s standards cryptography? Should the organization receiving the software understand and review all the algorithms and protocols used by the software?

    Although, in the open source world the latter may be feasible, it is not always a reasonable or scalable option for the IT department of each and every organization. That is why in Red Hat Enterprise Linux, we seek to comply with the FIPS 140-2 standard. FIPS 140-2 is a joint effort between NIST and the Canadian Centre for Cyber Security (CCCS).

  • Design Sprints: the Red Hat Way

Red Hat ups its OpenShift Kubernetes hybrid-cloud game

  • Red Hat ups its OpenShift Kubernetes hybrid-cloud game

    When they're not working on Linux, Red Hat is making it darn clear that job one is the hybrid cloud by way of Kubernetes. In its latest steps to support this, Red Hat is releasing its Kubernetes-based Red Hat OpenShift 4.3 and Red Hat OpenShift Container Storage 4 to provide multi-cloud Kubernetes container support.

    OpenShift 4.3 is based on Kubernetes 1.16. Red Hat supports customer upgrades from OpenShift 4.2 to 4.3.

    Building on last fall's developer-friendly OpenShift 4.2, the new OpenShift release brings stronger platform security to Red Hat's Kubernetes take. Specifically, it brings the Federal Information Processing Standard (FIPS) compliant encryption (FIPS 140-2 Level 1) to OpenShift. FIPS validated cryptography is mandatory for US federal departments that encrypt sensitive data.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

More in Tux Machines

GNU Parallel 20200222 ('BrexitDay') released [stable]

GNU Parallel 20200222 ('BrexitDay') [stable] has been released. It is available for download at: No new functionality was introduced so this is a good candidate for a stable release. GNU Parallel is 10 years old next year on 2020-04-22. You are here by invited to a reception on Friday 2020-04-17. Read more

GNU/Linux in Crostini Form

  • Using 'LXPanel' as a UI for Crostini

    If you are used to a menu-driven user interface in Linux or find the Chrome OS application launcher not quite to your liking for accessing Crostini Linux applications then one option you could try is LXPanel. The panel generates a menu for installed applications automatically from '*.desktop' files and can itself be incorporated in its own '.desktop' file which if pinned to the Chrome OS shelf can also be used as a means to start the 'penguin' container after booting. Unfortunately it is not quite perfect as the panel is displayed in the middle of the screen and doesn't respond well to changing its position under geometry in its panel settings. However you can toggle its visibility by clicking the panel's icon on the shelf. Also closing the panel (by right clicking the icon) only closes the 'LXPanel' application in Chrome OS so to terminate it fully you need to use 'killall lxpanel' in a terminal session.

  • Linux apps on Chromebooks may be reason enough for external GPU support

    We’ve been tracking a device known only as ‘Mushu’ for about a month at this point, and it brings with it a very specific and interesting addition to the Chrome OS ecosystem: a discrete GPU (or dGPU for short). When we first reported on this device being in development, I suggested that I don’t see a ton of use cases for a Chromebook with a dGPU for most users. Without a proper video editor or tons of ways to play locally-stored games, its hard to make a case for dGPUs when existing Chromebooks are already so fast at what they do.

NVIDIA's Ray Tracing Approach in Vulkan

  • NVIDIA talk up bringing DirectX Ray Tracing to Vulkan

    With Ray Tracing becoming ever more popular, NVIDIA have written up a technical post on bringing DirectX Ray Tracing to Vulkan to encourage more developers to do it. The blog post, titled "Bringing HLSL Ray Tracing to Vulkan" mentions that porting content requires both the API calls (so DirectX to Vulkan) and the Shaders (HLSL to SPIR-V). Something that's not so difficult now, with the SPIR-V backend to Microsoft's open source DirectXCompiler (DXC). Since last year, NVIDIA added ray tracing support to DXC's SPIR-V back-end too using their SPV_NV_ray_tracing extension and there's already titles shipping with it like Quake II RTX and Wolfenstein: Youngblood. While this is all NVIDIA-only for now, The Khronos Group is having discussions to get a cross-vendor version of the Vulkan ray tracing extension implemented and NVIDIA expect the work already done can be used with it which does sound good.

  • NVIDIA Demonstrates Porting Of DirectX Ray-Tracing To Vulkan

    NVIDIA has written a new technical blog post on bringing HLSL ray-tracing to Vulkan with the same capabilities of DirextX Ray-Tracing. This effort is made feasible by Microsoft's existing open-source DirectXCompiler (DXC) with SPIR-V back-end for consumption by Vulkan drivers. Last year NVIDIA contributed to the open-source DXC support for SPV_NV_ray_tracing. This in turn with the open-source tooling allows converting DXR HLSL shaders into SPIR-V modules for Vulkan.

Vulkan Survey and AMDVLK, AMD Targets GNU/Linux

  • LunarG's Vulkan developer survey results out now - Vulkan also turns 4

    LunarG, the software company that Valve sponsors who work on building out the ecosystem for the Vulkan API recently conducted a Vulkan developer survey with the results out now. Before going over the results, just a reminder that Vulkan just recently turned four years old! The 1.0 specification went public on February 16, 2016. Since then, we've seen some pretty amazing things thanks to it. We've had Linux ports that perform really nicely, the mighty DXVK translation layer advanced dramatically, to the vkBasalt post-processing layer and so on—there's been a lot going on. However, as a graphics API do remember it's pretty young and has a long life ahead of it. As for the LunarG survey: there were 349 replies to it, and while not a huge amount it gives us an interesting insight into what some developers think and feel about how Vulkan is doing as a whole. Overall, it gives quite a positive picture on the health of Vulkan with over 60% feeling the overall quality of the Vulkan ecosystem as "Good" and almost 20% rating it as "Excellent".

  • AMDVLK 2020.Q1.2 Released With Vulkan 1.2 Support

    AMDVLK 2020.Q1.2 is out as the first official AMD open-source Vulkan Linux driver code drop in one month. AMDVLK has been off its wagon this quarter with their previous weekly/bi-weekly code drops of AMDVLK but that just means the v2020.Q1.2 is quite a big one. First up, AMDVLK 2020.Q1.2 now is supporting Vulkan 1.2 that debuted back in January and with Mesa's RADV Radeon Vulkan driver already having supported it for weeks.

  • Radeon Pro Software for Enterprise 20.Q1.1 for Linux Released

    AMD's Radeon Pro Software for Enterprise 20.Q1.1 Linux driver release was made available this week as their newest quarterly driver installment intended for use with Radeon Pro graphics hardware.