Mirantis Container Cloud (MCC) becomes part of Mirantis OpenStack for Kubernetes (MOSK)!

Starting with MOSK 25.2, the MOSK documentation set covers all product layers, including MOSK management (formerly MCC). This means everything you need is in one place. The separate MCC documentation site will be retired, so please update your bookmarks for continued easy access to the latest content.

Center for Internet Security (CIS) benchmarks for host OS¶

The Center of Internet Security (CIS) benchmarks for Ubuntu provide prescriptive operating system (OS) hardening guidance aligned with common regulatory frameworks and help reduce host-level risk. CIS-aligned hardening reduces the cluster attack surface and establishes a uniform baseline across nodes, minimizing configuration drift and operational risk.

Running a Ubuntu host OS that is CIS-compliant out of the box delivers a secure, audit-ready baseline on day one: nodes are hardened by default, reducing attack surface and configuration drift across management and workload clusters. Because the baseline is pre-codified, it makes upgrades, reprovisioning, and compliance measurement in the field predictable and low-effort.

CIS-Ubuntu compliance in MOSK¶

MOSK relies on Ubuntu as the host OS for all bare-metal servers comprising management and MOSK clusters. The benchmark results below reflect the default, out-of-the-box state of the provisioned host. Scores in field clusters may differ based on cluster-specific customizations, for example, enabled services, network settings, or documented exceptions.

The summary of the latest validation results for Ubuntu CIS benchmark is as follows:

Benchmark	Tenable CIS Ubuntu Linux 22.04 LTS Server L1 v2.0.0, revision 1.10
Pass Rate	87%
MOSK release	25.2
Operating system	Ubuntu 22.04
Scanner Tool	Nessus version 10.9.0, build R20004

Note

For clusters that are based on Ubuntu 24.04, the validation is ongoing and the results will be published in one of the following releases.

Exceptions¶

The controls below did not pass this benchmark and are documented exceptions - either not applicable to the MOSK architecture or pending for further analysis. In field deployments, these items can be mitigated on a per-cluster basis, taking into account the specifics of the environment.

Caution

Compliance results can vary across different environments depending on configuration tests, such as server disk partitioning.

Control	Description	Comment
1.1.1.8	Ensure usb-storage kernel module is not available	Cluster-specific. The module can be safely disabled in the field. Further investigation is pending to get it removed out of the box.
1.1.2.1.1	Ensure `/tmp` is a separate partition	Cluster-specific. Disk partitioning is configured at the time of cluster deployment.
1.1.2.2.4	Ensure `noexec` option set on `/dev/shm` partition	Potentially disruptive to the normal functioning of the product. Further investigation is pending.
1.2.2.1	Ensure updates, patches, and additional security software are installed	Environment-specific. Cloud operators schedule cluster upgrades in line with the MOSK release cadence along with local policy and regulatory needs. The update cadence of product component versions balances currency and stability.
1.3.1.2	Ensure AppArmor is enabled in the bootloader configuration	By default, AppArmor is enabled on the host OS level. The bootloader configuration is not yet enforced by the product, but can be customized in the field.
1.4.1	Ensure bootloader password is set	Bootloader password management is not yet supported by the product, but can be manually performed in the field.
2.1.18	Ensure web server services are not in use	Exception. Local NGINX is deployed as a part of MOSK and as a proxy to download container images and other artifacts.
3.3.1	Ensure IP forwarding is disabled	Exception. IP forwarding is required by Kubernetes to operate.
3.3.2	Ensure packet redirect sending is disabled	Potentially disruptive to the product. Further investigation is pending.
3.3.5	Ensure `icmp` redirects are not accepted	Potentially disruptive to the product. Further investigation is pending.
3.3.6	Ensure secure `icmp` redirects are not accepted	Potentially disruptive to the product. Further investigation is pending.
3.3.7	Ensure reverse path filtering is enabled	Potentially disruptive to the product. Further investigation is pending.
3.3.9	Ensure suspicious packets are logged	Not applicable. The control explicitly requires Uncomplicated Firewall (UFW), which is not compatible with Docker and Kubernetes. In MOSK, suspicious packets are logged through other means.
4.1.3	Ensure `ufw` service is enabled	Not applicable. Uncomplicated Firewall (UFW) has compatibility issues with Docker and Kubernetes.
4.1.4	Ensure `ufw` loopback traffic is configured	The control explicitly requires Uncomplicated Firewall (UFW), which is not compatible with Docker and Kubernetes. Any alternative solution is potentially disruptive to the product. Further investigation is pending.
4.1.6	Ensure `ufw` firewall rules exist for all open ports	The control explicitly requires Uncomplicated Firewall (UFW), which is not compatible with Docker and Kubernetes. Further investigation is pending.
4.1.7	Ensure `ufw` default deny firewall policy	The control explicitly requires Uncomplicated Firewall (UFW), which is not compatible with Docker and Kubernetes. Further investigation is pending.
5.4.1.5	Ensure inactive password lock is configured	Further investigation is pending.
5.4.2.4	Ensure root password is set	Environment-specific. Managing root passwords is not yet part of MOSK architecture and needs to be enforced manually.
5.4.3.2	Ensure default user shell timeout is configured	Potentially disruptive to the product. Further investigation is pending.
5.4.3.3	Ensure default user umask is configured	Further investigation is pending.
6.1.1	Ensure AIDE is installed	Impacts the storage IO performance. Further investigation for an alternative is pending.
6.1.2	Ensure filesystem integrity is regularly checked	Depends on the control 6.1.1 (above). Further investigation is pending.
6.2.1.2.2	Ensure `systemd-journal-remote` authentication is configured	Not applicable. MOSK logging is handled by StackLight.
6.2.1.2.3	Ensure `systemd-journal-upload` is enabled and active	Not applicable. MOSK logging is handled by StackLight.
6.2.2.1	Ensure access to all logfiles has been configured	Further investigation is pending.
7.1.11	Ensure world writable files and directories are secured	MOSK components require specific file access rules inside containers. Further investigation is pending.
7.1.12	Ensure no files or directories without an owner and a group exist	MOSK components require specific file access rules inside containers. Further investigation is pending.

Note

The control IDs may differ depending on the scanning tool.

If you require a detailed report of analyzed and fixed compliance checks, contact Mirantis support.