Infrastructure Security¶
A key aspect of planning your installation and configuration is addressing infrastructure security. By planning your configuration to include industry standard best practices prior to deployment, you can reduce the risk of security and compliance issues.
StarlingX Infrastructure Security Features¶
The security features listed below are available with StarlingX and should be included in your infrastructure security planning.
Regular CVE scanning and fixing of StarlingX Platform’s CentOS Kernel and RPM Packages
UEFI Secure Boot on StarlingX Hosts
Signed boot loaders, initramfs, kernel and kernel modules
Signed in formal builds with StarlingX private key on StarlingX secure signing server
Validated by board-specific UEFI Secure Boot Firmware
For more information, see Kubernetes UEFI Secure Boot Planning
Signed ISOs and Patches/Updates
Signed in formal builds with StarlingX private key on StarlingX secure signing server
Public key built into ISO and patch signature validation code
Signatures checked on load import and update import commands
Authentication and Authorization on all interfaces of:
SSH / Local Console (local LDAP)
Linux User/Group Permissions
Linux sudo
StarlingX REST APIs/CLIs (Keystone - local DB)
Keystone Roles - admin, member
Kubernetes APIs/CLIs (Service Accounts and Remote LDAP / Windows Active Directory via OIDC/DEX)
K8S RBAC Policies
StarlingX Dashboard Webserver (Keystone - Local DB)
Keystone Roles - admin, member
Local Docker Registry (Keystone - Local DB)
Keystone - admin, non-admin user
HTTPS Support for all external Platform endpoints including:
System, Kubernetes, local docker registry REST APIs
Platform Dashboard Webserver
Certificate Management for K8S Certificates
Bootstrap configured K8S Root CA Certificates (auto-generated or user-specified)
Cron Jobs for renewing K8S server & client Certificates
Procedure for updating K8S Root CA Certificate
Certificate Management for HTTPS Platform endpoints (StarlingX APIs, Registry, OIDC, …) including use of Cert-Manager for install and auto-renewal of Certificates
Trusted CA Management for local client-side certificate validation
Alarming of soon-to-expired and expired Certificates
‘show-certs.sh’ for displaying status and residual time for all certificates.
Secure (HTTPS) Platform management network communication in Distributed Cloud providing secure management network connectivity between the system controller and subclouds with auto-renewal of certificates
OAM / API Firewall includes default firewall rules automatically applied and customer modifiable through Calico network policies
Helm v3 support including the removal of the default use of Helmv2/Tiller (insecure)
Secure User Management including:
User Password Complexity enforcement
User forced log out on idle activity
User temporary lock out on N consecutive authentication failures
Audit logs for operator commands and authentication events
Shell commands (on SSH / Local Console)
StarlingX REST APIs / CLIs
All logs can be sent to external Log Server using Wind River Analytics application
Linux Auditd support for running on all hosts with configurable rules
OpenScap Modules included in Host ISO
Security Services for Hosted Applications including:
Cert Manager support including integration of the cert-manager project to automate the management and issuance of TLS certificates from various issuing sources (e.g. interface with external CA for certificate signing, auto-renewal of certificates)
Secure secret management and storage (Hashicorp Vault) with the integration of upstream Hashicorp Vault project and Support Vault general secret management for hosted applications
Kubernetes UEFI Secure Boot Planning¶
UEFI Secure Boot Planning allows you to authenticate modules before they are allowed to execute.
The initial installation of StarlingX should be done in UEFI mode if you plan on using the secure boot feature in the future.
The StarlingX secure boot certificate can be found in the StarlingX ISO, on the EFI bootable FAT filesystem. The file is in the directory /CERTS. You must add this certificate database to the motherboard’s UEFI certificate database. How to add this certificate to the database is determined by the UEFI implementation provided by the motherboard manufacturer.
You may need to work with your hardware vendor to have the certificate installed.
There is an option in the UEFI setup utility that allows a user to browse to a file containing a certificate to be loaded in the authorized database. This option may be hidden in the UEFI setup utility unless UEFI mode is enabled, and secure boot is enabled.
Many motherboards ship with Microsoft secure boot certificates pre-programmed in the UEFI certificate database. These certificates may be required to boot UEFI drivers for video cards, RAID controllers, or NICs (for example, the PXE boot software for a NIC may have been signed by a Microsoft certificate). While certificates can be removed from the certificate database (this is UEFI implementation specific) it may be required that you keep the Microsoft certificates to allow for complete system operation.
Mixed combinations of secure boot and non-secure boot nodes are supported. For example, a controller node may secure boot, while a worker node may not. Secure boot must be enabled in the UEFI firmware of each node for that node to be protected by secure boot.
Secure Boot is supported in UEFI installations only. It is not used when booting StarlingX as a legacy boot target.
StarlingX does not currently support switching from legacy to UEFI mode after a system has been installed. Doing so requires a reinstall of the system. This means that upgrading from a legacy install to a secure boot install (UEFI) is not supported.
When upgrading a StarlingX system from a version that did not support secure boot to a version that does, do not enable secure boot in UEFI firmware until the upgrade is complete.
