f125a8b892
This change addresses a long-standing issue in rST documentation imported from XML.
That import process added backslash escapes in front of various characters. The three
most common being '(', ')', and '_'.
These instances are removed.
Signed-off-by: Ron Stone <ronald.stone@windriver.com>
Change-Id: Id43a9337ffcd505ccbdf072d7b29afdb5d2c997e
7.1 KiB
Executable File
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.
Infrastructure Security Features
The security features listed below are available with and should be included in your infrastructure security planning.
Regular CVE scanning and fixing of Platform’s DEB Kernel and RPM Packages
UEFI Secure Boot on Hosts
- Signed boot loaders, initramfs, kernel and kernel modules
- Signed in formal builds with private key on secure signing server
- Validated by board-specific UEFI Secure Boot Firmware
For more information, see
Kubernetes_UEFI_Secure_Boot_PlanningSigned ISOs and Patches/Updates
- Signed in formal builds with private key on 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
- 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
- Dashboard Webserver (Keystone - Local DB)
- Keystone Roles - admin, member
- Local Docker Registry (Keystone - Local DB)
- Keystone - admin, non-admin user
- SSH / Local Console (local LDAP)
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
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
Secure Boot Planning allows you to authenticate modules before they are allowed to execute.
The initial installation of should be done in mode if you plan on using the secure boot feature in the future.
The secure boot certificate can be found in the ISO, on the EFI bootable FAT filesystem. The file is in the directory /CERTS. You must add this certificate database to the motherboard's certificate database. How to add this certificate to the database is determined by the 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 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 setup utility unless mode is enabled, and secure boot is enabled.
Many motherboards ship with Microsoft secure boot certificates pre-programmed in the certificate database. These certificates may be required to boot drivers for video cards, controllers, or (for example, the boot software for a may have been signed by a Microsoft certificate). While certificates can be removed from the certificate database (this is 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 firmware of each node for that node to be protected by secure boot.
- Secure Boot is supported in installations only. It is not used when booting as a legacy boot target.
- does not currently support switching from legacy to 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 () is not supported.
- When upgrading a system from a version that did not support secure boot to a version that does, do not enable secure boot in firmware until the upgrade is complete.