Mirantis acquires amazee.io, the only ZeroOps Application Delivery Hub.   Read Blog Post  |  View Press Release  |  Visit amazee.io

Mirantis OpenStack for Kubernetes 22.3 delivers increased security and compliance, Ubuntu 20.04 support and scalability up to 10,000 VMs

Valentin Marenich - July 12, 2022
image

Committed to rapid innovation, Mirantis is pleased to announce the third major 2022 update of Mirantis OpenStack for Kubernetes (MOSK). In release 22.3, Mirantis OpenStack for Kubernetes makes it even easier for operators to handle updates. We also provide a number of security enhancements, including new default policy settings aligned with the latest OpenStack community best practices.

New clouds can be deployed with the latest server hardware

Starting with this release, Ubuntu 20.04 is now a supported operating system for nodes in greenfield MOSK deployments. Field-proven and stable, Ubuntu 20.04 provides newer hardware drivers and security patches, and supports enabling FIPS encryption, needed to build  FedRAMP and FIPS-compliant clouds. For existing clouds, Mirantis will provide an upgrade path from Ubuntu 18.04 later this year.

Cloud web UI hardened as per the community best practices for security

Delivering on our promise of building secure clouds, we continue to promptly implement all upstream community security guidelines. With MOSK 22.3, the web UI (OpenStack Horizon) is officially confirmed to follow all items on the upstream security checklist, which represents evolving best practices validated by the large global community of OpenStack users. Mirantis believes there are no small things in security, and we welcome questions from customers about checklist items.

Enhanced protection of security-sensitive cloud configuration parameters

Previously, many deployments included sensitive data such as SSL and TLS certificates, individual and external services credentials in the configuration file, creating the risk of exposure and hindering the sharing of the configuration for use in analysis, problem remediation, and for other purposes. Starting with MOSK 22.3, secrets can be kept separate from other configurations by using the new OpenStackDeploymentSecret object, which enables secure and straightforward management of this sensitive data.

Faster and more reliable updates for telco clouds

Best practice DevOps productivity guidelines advocate separating the preparation and execution phases of deployment. In line with this best practice, for MOSK 22.3, we’ve made available Tungsten Fabric (a core component supporting OpenStack guest virtual networking) Docker images for download and local caching before you begin an update. This eliminates any chance for update failure due to poor network conditions, and makes updates faster and more reliable.

Foundation to implement flexible access control models for the cloud

Identity and access management is a vital part of any enterprise system, including OpenStack. The default Identity management system in OpenStack is Keystone, which provides operators with identity, token, catalog, and policy services. Out-of-the box, Keystone provides three basic roles — admin, member, and reader — that can be assigned across:

  • domains - a collection of projects and users that define administrative boundaries for managing Identity entities

  • projects - main means of isolating resource access in OpenStack

  • system - deployment system: a collection of hardware (e.g., compute nodes) and services (e.g., Nova, Cinder, Neutron, Barbican, Keystone)

Given the number of possible customizations, things can get complicated pretty quickly. Before this release, all policies were maintained in a set of JSON files, which should be maintained and updated whenever a new feature/functionality arises.

Starting with MOSK 22.3, all defaults are specified in the code of a component or a feature, which basically means that all the defaults are kept up-to-date automatically for every change. Differences from default policies are now configured in the CRD file and automatically propagated to the services’ policy.yaml files. These can be empty if there is no need to change defaults, leaving less room for mistakes and simplifying future enablement of advanced authentication and access control functionality, such as scoped tokens and scoped access policies.

In upcoming releases, this functionality will enable much easier implementation of advanced access models.

Up to 10k virtual machines in a single cloud

MOSK is now officially capable of running 10,000 instances (virtual machines) under a single control plane, and our next official scale target is 15,000 instances. Increasing the supported scope is something we care about, and not just in an abstract way; one of our customers now runs, on average, 7,000 instances per cloud and we envision this number increasing to 10-12k by the end of this year.

However, despite increasing density, in order to achieve reliability and manageability at large scales, we recommend adopting a multi cloud (and multi-control plane) approach. This basically means that instead of squeezing all needed resources into a single cloud, we deploy a number of similar clouds, each with its own underlying k8s cluster and OpenStack control plane, and connect them using available MOSK features, such as cross-site data replication, BGP-VPN, and SSO capabilities.

In addition to key improvements outlined above, Mirantis OpenStack for Kubernetes 22.3 also adds other enhancements and stability fixes.  You can read more about the full set of changes in the MOSK 22.3 release notes.  We also welcome you to try Mirantis OpenStack for Kubernetes yourself — you can get started here — or contact our team to explore how Mirantis OpenStack for Kubernetes can help address your infrastructure challenges.


Valentin Marenich

Valentin Marenich is Product Manager for Mirantis OpenStack for Kubernetes.