Mirantis OpenStack for Kubernetes 22.4 brings peace of mind with OpenStack Yoga

MOSK 22.4 introduces new security and audit features, improved backups, latest-model Tungsten Fabric networking, and new MCC storage management functions, making it easier than ever to run resilient OpenStack clouds at scale

It is perhaps appropriate that the latest version of OpenStack, introduced with our 22.4 release, is code-named “Yoga” — as our 22.4 release is focused on helping you achieve peace of mind in your day to day infrastructure operations. In addition to introducing the next major version of OpenStack, we’ve added new security-related enhancements and ease-of-use features – continuing our focus on providing you with the most secure infrastructure possible, while simplifying your day to day operations.

A key value which Mirantis provides customers using OpenStack is the exhaustive hardening and validation process we perform on each version of the open source code. In addition to delivering the OpenStack components in a containerized fashion, we validate the code functionally, as well as from a performance and scalability perspective, fixing issues if required.

Hardening the open source base requires significant time and effort, which is why we do not deliver the latest OpenStack version to customers immediately upon release to the open source community. This hardening ensures our customers have a deployable, reliable distribution on which they can base their mission-critical operations. 

In this release we provide a technical preview of OpenStack Yoga and Tungsten Fabric 21.4, providing customers with the chance to preview and validate this new base in their environment. Full production of OpenStack Yoga in MOSK is planned for our 22.5 release later this year. 

Strong security is founded on well-defined security practices and methods. We can provide all the internal protections, but if they are not properly used then security won’t be reliable. With the 22.4 release, we are providing you with two precious commodities: information on how to best secure your cloud infrastructure, and also information on what is occurring in your infrastructure.

MOSK Security Guide

To help organizations navigate and utilize all the security features available in MOSK, we are extending our documentation with the Security Guide. This document provides extensive instructions for all common security-related needs. Written for security-minded operators and cloud architects, the guide will be significantly expanded over the course of the next few releases, with the first version of the document available now, and focused on Firewall Configuration and the ability to emit CADF notifications for auditing purposes (see below).

CADF records for cloud audit

Transparency and the ability to see who is doing what in your infrastructure is a key requirement in a mature enterprise environment. The Cloud Auditing Data Federation (CADF) specification defines a standardized vendor-agnostic format for event data, designed for use in cloud security auditing. Starting with the 22.4 release, all core MOSK services — Compute (Nova), Block Storage (Cinder), Images (Glance), Networking (Neutron), Orchestration (Heat), DNS (Designate), Bare Metal (Ironic), and Load Balancing (Octavia) are able to emit notifications in CADF format. The payload of each notification is a JSON structure that describes an action a user attempts to perform against the cloud API. MOSK can be configured to store the CADF notifications in StackLight together with other logs. From there one can easily forward the data to an external system for audit and threat analysis.

{
  "typeURI": "http://schemas.dmtf.org/cloud/audit/1.0/event",
  "initiator": {
    "typeURI": "service/security/account/user",
    "host": {
      "agent": "curl/7.22.0(x86_64-pc-linux-gnu)",
      "address": "127.0.0.1"
    },
    "id": "<initiator_id>"
  },
  "target": {
    "typeURI": "<target_uri>",
    "id": "openstack:1c2fc591-facb-4479-a327-520dade1ea15"
  },
  "observer": {
    "typeURI": "service/security",
    "id": "openstack:3d4a50a9-2b59-438b-bf19-c231f9c7625a"
  },
  "eventType": "activity",
  "eventTime": "2014-02-14T01:20:47.932842+00:00",
  "action": "<action>",
  "outcome": "success",
  "id": "openstack:f5352d7b-bee6-4c22-8213-450e7b646e9f",
}

Applications Credentials

Modern cloud applications rely on various automation tools for deployment and Day Twomanagement. The tools need to manipulate cloud resources just like human users. For example, Jenkins is the central component of the MOSK CI/CD system, and one of the things it does to validate every new release is to deploy several test applications using OpenStack Heat templates. Naturally, automation tools need to somehow authenticate in the cloud API, and using human user credentials is obviously not a good idea. Historically, dedicated “technical user” accounts were created for this purpose — though while introducing an additional administrative burden, this approach is not fully secure as it grants an automation tool more permissions than may actually be needed for it to do its job.

Application Credentials, introduced in MOSK 22.4, is the recommended way to grant permissions to automation tools and is a secure and easy alternative to dedicated “technical users.” 

Applications Credentials provide several benefits — perhaps most importantly, they are secure. Human users can delegate a selected subset of their own permissions to an application, granting it restriced access to a project, which can be revoked ton schedule or on demand. Also, it makes the process more self-service — now each user can manage application access completely on their own, without having to bother cloud administrators.

We know your job is tough enough — so we continue to focus on ways to simplify your infrastructure management with MOSK. In this release we’ve added five new features to help make your life easier.

MCC UI improvements for storage management

The storage subsystem is one of three pillars of any cloud, and naturally cloud operators want to have a clear and easily accessible view into its state. Recognizing this need, we have enhanced the Mirantis Container Cloud (MCC) web user interface to provide a summary view of Ceph clusters that represent the storage part of almost every MOSK or general purpose K8s deployment. Cloud operators can now easily find Ceph cluster name, ID, health status, and progress of rebalancing as well as the number and status of object storage daemons (OSDs) running. 

Soon we will be extending the UI with additional views that will let authorized users see and manipulate Ceph cluster components.

“Restart required” indicator for cluster machines

Restart of cluster machines is sometimes required as part of an update process — for example, when a newer version of the host operating system is installed. At Mirantis, we believe that “inevitable” does not have to mean disruptive. In the previous 22.3 release, we added flexibility for operators by letting them decide when exactly they wanted to reboot each machine in the cluster. With the 22.4 release, we have made this process even more convenient by adding a simple way for operators to see if a restart of a specific node is required at the moment — this indicator is now exposed as a part of the status attribute of Machine object in cluster API and in future releases we will also make this flag visible in the MCC UI.

Configurable Region Names

For cloud operators with a global presence, who often run multiple clouds each deployed in a separate geographical region, there is a need to simplify the experience for users managing several clusters (i.e. groups of API endpoints) at once. To help users distinguish their multiple clouds, OpenStack provides the concept of ‘region name,’ a globally unique symbolic identifier that is a part of each cloud configuration. A cloud user passes the region name parameters to various application automation tools (such as Terraform, OpenStack CLI, etc) when they wish to specify which of the clouds they are working with.

MCC allows for the management of multiple clouds from a single pane of glass, but previously the MOSK cluster region name could not be changed — creating challenges for managing multiple OpenStack deployments.

With MOSK 22.4 we have added the ability to configure the name of an OpenStack region during its initial deployment — now users can navigate across multiple clouds using meaningful names — perhaps as geographic locations (e.g. “fra” — Frankfurt, “ams” — Amsterdam) or by purpose (“stage”, “prod”).

Auto-restart of Tungsten Fabric vRouters after cloud update

The vRouter is the key component of the Tungsten Fabric data plane, one of two Software Defined Networking backends offered by MOSK. vRouter and its sibling services are present on each compute node and are responsible for forwarding network packets between virtual machines running in the cloud. 

In previous versions of MOSK, the cloud operator had to manually restart vRouter services after updating a Tungsten Fabric-enabled cluster to a newer MOSK version. With the 22.4 release, we have automated this process in the update procedure, so that once the update completes, vRouters are automatically restarted without need for manual intervention.

Backup OpenStack database to an external NFS share

In the 22.4 release, we are providing a technical preview of the capability to store the OpenStack database backup data externally, outside of the cloud. As an alternative to using a volume in the cloud’s Ceph cluster, the cloud operator can now use standard parameters in OpenStackDeployment CR to configure the database backup job to mount a NFS share and put the data there. Previously, this has only been possible as a customization. This allows administrators to easily push the database backup to an external repository for purposes of disaster recovery of the OpenStack infrastructure. In the future, we will be looking to add support for other file storage protocols, like S3. 

In addition to the benefits outlined above, Mirantis OpenStack for Kubernetes 22.4 adds a number of other enhancements and stability fixes. You can read more about the full set of changes in the MOSK 22.4 release notes. 

We welcome you to experience Mirantis OpenStack for Kubernetes yourself — you can easily give it a try with TryMOSK, a hosted MOSK trial deployment. With TryMOSK you will have access to a complete and ready-to-use Mirantis OpenStack for Kubernetes cloud running on top of real hardware with sufficient scale to deploy a few real applications and experience the power of MOSK. Get started today, or contact our team to explore how Mirantis OpenStack for Kubernetes can help address your infrastructure challenges.