CloudBase/Technical Specification

Fedora Cloud Base Technical Specification

This document aims to describe the technical characteristics of the Fedora Cloud Base product in detail. This includes provided services and APIs, installed software, and the like. Some of the desired characteristics are not complete in the current version of the Cloud Base product, and will be introduced in later versions.

The content of this specification references the work of the Fedora Linux Base Feature definitions as is necessary to ensure alignment with the principles and features of the Fedora Project.

Core Services and Features

Supported Architectures and Environments

Fedora Cloud Base will be built for a number of commercial cloud providers, including, but not limited to, Amazon EC2, Google Compute Cloud, and Azure Compute, as well as many other regional providers. Others platform providers will be evaluated and accommodated on a case by case basis and evaluation is driven primarily based on user demand and ease of integration into existing build tools.

Images will support the following architectures:

• aarch64
• x86_64

There will also be specific accomodation to ensure that the following environments are fully functional even if the builds are not immediately validated or tested in efforts to prepare for release by the Cloud Working Group. These are in support of virtual environments including IBM Cloud and virtual machines for IBM Hardware:

• ppc64le
• s390x

There are currently two official images and four environments supported for the Fedora Cloud Base:

• Generic Configuration for OpenStack and other personal
• GCP qemu/kvm or container

There are customizations beneficial for the following environments:

• Azure qemu/kvm or xen
• EC2 qemu/kvm or xen

File system

The default file system type for Fedora Cloud Image installs will be BTRFS configured directly to a qcow2 or raw disk image with the required subvolume for /home.

File system layout is selected based on requirements for the flexibility of the file system at instance instantiation and the potential to ensure maximum flexibility for hardening and noexec requirements. The use of BTRFS gives users the flexibility to modify these configurations settings after boot.

When uploaded to shared usage environmnets, such as Azure Compute or Amazon EC2 disk encryption is not used so that users can make copies into their own accounts and enforce disk encryption as they require.

Instance management

The Fedora Cloud Base Images depend upon cloud-init by default, however there are certain environments that require bespoke configurations for boot. GCP requires this change. It is the intention of the Fedora Cloud Base to accommodate these specific requirements wherever software licensing and publication requirements are met.

Networking

Network devices and connections do not leverage advanced NetworkManager configuration by default. Cloud Management Roles that may need to interact with the network configuration should do so by leveraging the NetworkManager utilities.

Firewall

There will be no firewall by default in the Fedora Cloud Base Image configuration. Cloud Images may not require instance firewalls as they are handled externally to the instances through security groups and other configurations with the normal operation of programs installed by default.

On a pristine system, both SSH and Cockpit services are expected to be enabled, but no other services are listening by default. When [[ | Linux System Roles]] are deployed, they may elect to install a firewall and make one or more ports based on the most likely need. Roles *must* provide an interface that describes which ports they want open and which ones they currently have opened. The admin must be able to easily modify this configuration.

Roles that open ports by default must have the set of ports approved by majority vote of the Server Working Group.

If the user hasn't specified firewall status explicitly, interactive role deployment will inform the user whether the service's ports have been opened by default. It must be possible to query the API for the required state of the firewall to support the role, which can then be compared to the active firewalld state.

The OpenLMI project will provide a public, external API to manage firewalld centrally. (This is not yet scheduled for a Fedora release, but is a medium-term plan.)

SELinux

SELinux will be enabled in enforcing mode, using the targeted policy. The Fedora Cloud Base standard image and any customized Linux System Roles must operate in enforcing mode.

Problem reporting

Problems and error conditions (e.g. kernel oopses, Selinux AVCs, application crashes, OOM, disk errors) should all be reported in the systemd journal.

Support for sending this information to a central place (like abrt does for crashes today) is mandatory.

Account and Identity Management

As a result of alignment with the base features of Fedora Linux, SSSD will provide the support for identity management. The Fedora Cloud Base is typically not centrally managed, but users are aligned through the use of instance user-data. Though there should be no block to use of centrally-managed applications; it must be possible to configure any Fedora Cloud Base instance to rely on a directory service for identity and policy management details. Fedora Cloud Base should provide and support joining FreeIPA and Active Directory domains, but configuration will require configuration via cloud-config. Interacting with other identity sources will remain a manual configuration effort.

Software updates

Software updates on the Fedora Server must be possible to perform either locally using command-line tools (e.g. yum/dnf) or centrally by common management systems (e.g. Puppet, Chef, Satellite, Spacewalk, OpenLMI).

Miscellaneous system information

System locale, timezone, hostname, etc. will be managed through the services provided by systemd for this purpose. Customizations may be made to support configurations for specific cloud providers by default. TODO Add documentation on specific requirements from different cloud providers for link local resources.

Virtualization

Nested virtualization is supported in some environment. Images should support both bare metal configurations for hyperscalers as well as standard virtualization using Xen and KVM. There are specialized requirements on specific public cloud providers and it is the mission of this Edition to accommodate these environmental requirements to the best of our ability without creating.

Accessibility

Accessibility support is handled through standard tooling, but is limited to what is achievable in the virtualized environments. For example, An Amazon EC2 instance cannot support USB devices connections unless it is specifically used with software for virtual desktop integration, such as Spice

Input Methods

The input method support for the Fedora Cloud Base console access will be limited to LOCALE support in the command shell. By default this is limited, but can be modified at boot using cloud-config to modify the LOCALE with the cloud-init application or other tool.

Input method support in the optional graphical console will align with Fedora Workstation.

Graphics and Display Manager

The Fedora Cloud Base does not directly support a graphical environment at this time. It may be used with VDI software to achieve a graphical workstation environment and should support hardware acceleration whenever possible. Other bespoke or specialized hardware for accelerated workloads, like Amazon's Inferentia chips will be supported whenever there are open source utilities and mainline kernel support.

Appearance

The default user-experience for the Fedora Cloud Base includes access via SSH to a bash shell on the console and access to the instances via Cockpit web management console whenever possible

System Installer

Fedora Cloud Base will be composed using the Fedora Cloud Base kickstart and implemented using pyKickstart and Anaconda in the unattended installation mechanics provided through koji. Recently the image building software kiwi has been integrated into koji in support of the goals for building and testing images through the Fedora build environments

Core Package list

List of the core packages installed to the Fedora Cloud Base. This list includes all packages that will be available on the base image. This is the identified minimal list of packages to be installed on a cloud instance. For UX and QA testing, this package list will be the priority.

Package Considerations

cloud-init is the de jure standard for cloud management utilities. If another package supports a different cloud, it is expected that it will be similarly available as a systemd service and can be prioritized over cloud-init. To disable password authentication, cloud-init is set to modify the setting in /etc/ssh/sshd_config at boot by default.

To improve the integration with OpenStack and other VM management systems (oVirt, KubeVirt) qemu-guest-agent is installed by default.

To prevent failure of access, firewalld is installed during the build to allow for the uncomplicated deployment of dependent software and then removed to ensure support is uncomplicated.