New Security Features in Red Hat OpenStack Platform 17.1
Here in this blog, we are going to learn the New Security Features in Red Hat Open stack Platform 17.1.
Memcached in encryption
Tokens and authentication replies are kept in the cache as raw data when using memcached. Tokens and authentication answers become viewable if the cache is hacked. This worry is reduced by encrypting memcached material. Aodh, Barbican, Cinder, Glance, Gnocchi, Heat, Ironic, Neutron, Nova, and Panko are some of the OpenStack services that enable memcached protection; all of these services employ keystone middleware for authentication.
Role-based access control that is secure (SRBAC)
The SRBAC security approach for OpenStack enables businesses to implement stringent, granular access control policies to safeguard their OpenStack deployments. It benefits a number of use cases, such as data center security, compliance and auditing, multi-tenancy, and workload isolation, and offers benefits including granular control, easier administration, greater security, improved workflow, and scalability.
SRBAC increases functionality, enhances auditability, and reduces attack surfaces by extending granular Role-Based Access Control of authorization across OpenStack services. This has been a long-standing requirement for OpenStack, whose operators frequently want to offer a read-only view for particular users (like auditors). In Red Hat OpenStack Platform 17.1, SRBAC offers a read-only role for projects (note: this is a day-one choice).
Advantages of fernet tokens for consumers
The advantages of using Fernet tokens might not be obvious right away, but they guarantee that the user’s information is secure and that their experience is quick, easy, and safe. By encrypting the user’s critical information while in transit and shielding it from potential attacks, Fernet tokens contribute to the security of the Keystone user’s data.
With the quick and simple generation of fernet tokens, users may quickly access their applications without having to wait for protracted authentication procedures. Fernet tokens have the major benefit of being decryptable locally by another service after Keystone produces them. To verify the tokens supplied by users for different token kinds, the other service must communicate with Keystone. The receiving service doesn’t have to travel to Keystone twice because to Fernet tokens.
Federation with OpenID Connect
In OpenStack, the term “federation” describes the capacity to authenticate and authorize users across several domains or systems. In the context of OpenStack, federation often entails relying on an external identity provider (IdP) rather than just the internal Keystone identity service to manage user authentication and authorisation.
OpenID Connect (OIDC), an authentication system built on top of the OAuth 2.0 protocol, is one option to achieve federation in OpenStack. OIDC allows for the usage of an external IdP for user authentication and role assignment based on mapping criteria.
Users can access OpenStack using their external IdP credentials once federation has been set up and activated. Keystone can allow a user’s access to OpenStack resources using the data supplied by the IdP.
Overall, by enabling users to log in using their current credentials and removing the need for users to keep several sets of login credentials, federation with OpenID Connect in OpenStack can offer a more smooth and secure user authentication and authorization experience.
ISO/IEC 19790 Federal Information Processing Standards (FIPS)-140
Enable FIPS 140-3-compliant, ISO/IEC 19790-level strong encryption in Red Hat OpenStack Platform (this is a decision that needs to be made right away).
The American National Institute of Standards and Technology (NIST) created the FIPS cryptography standards, which are widely regarded as a security standard. FIPS mode provides a high level of assurance for encryption, digital signatures, and secure communications by confirming that cryptographic techniques and modules used inside OpenStack adhere to accepted standards. This aids in preventing unwanted access to and tampering with sensitive data, including user credentials, private keys, and communication channels.
FIPS-certified cryptographic systems must be used in many businesses, notably those that deal with sensitive data, like healthcare, finance, and government. Running OpenStack in FIPS mode demonstrates that the system complies with accepted cryptographic standards, assisting enterprises in fulfilling their compliance obligations.
The move to OpenStack strong encryption will have an impact on partners and customers who are operating solutions on or on top of Red Hat OpenStack Platform. If the customer uses their own cryptographic libraries and modules within their solution (the yellow boxes), a third-party solution that brings its own security within may be what the customer wants. The third-party solution must use FIPS-level cryptography whenever it wants to communicate with the platform or operating system through a cryptographic call; otherwise, the call will be unsuccessful.
Delivering FIPS-140 (ISO/IEC 19790) support for Red Hat OpenStack Platform is a component of the platform’s overall FIPS enablement; nonetheless, to ensure smooth operation, you must rigorously test your environment with all of its non-Red Hat components.
As of Red Hat OpenStack Platform 17.1, there are just four OpenStack-related parameter changes that are applied to the deployments in FIPS-140 mode, aside from changing the underlying RHEL to use FIPS-approved cryptographic algorithms:
Wrap up
Learn more about Red Hat’s compliance efforts and support for government standards here (the piece on Red Hat Enterprise Linux 9 applies to Red Hat OpenStack Platform 17.1).
Here is further information on Red Hat Enterprise Linux’s FIPS-140 cryptography profiles.
