HTTPS Access Planning

You can enable secure HTTPS access and manage HTTPS certificates for all external StarlingX service endpoints.

These include:

Note

Only self-signed or Root CA-signed certificates are supported for the above StarlingX service endpoints. See https://en.wikipedia.org/wiki/X.509 for an overview of root, intermediate, and end-entity certificates.

You can also add a trusted CA for the StarlingX system.

Note

The default HTTPS X.509 certificates that are used by StarlingX for authentication are not signed by a known authority. For increased security, obtain, install, and use certificates that have been signed by a Root certificate authority. Refer to the documentation for the external Root CA that you are using, on how to create public certificate and private key pairs, signed by a Root CA, for HTTPS.

StarlingX REST API applications and the web administration server

By default, StarlingX provides HTTP access to StarlingX REST API application endpoints (Keystone, Barbican and StarlingX) and the StarlingX web administration server. For improved security, you can enable HTTPS access. When HTTPS access is enabled, HTTP access is disabled.

When HTTPS is enabled for the first time on a StarlingX system, a self-signed certificate and key are automatically generated and installed for the StarlingX REST and Web Server endpoints. In order to connect, remote clients must be configured to accept the self-signed certificate without verifying it. This is called insecure mode.

For secure mode connections, a Root CA-signed certificate and key are required. The use of a Root CA-signed certificate is strongly recommended. Refer to the documentation for the external CA that you are using, on how to create public certificate and private key pairs for HTTPS.

You can update the certificate and key used by StarlingX for the StarlingX REST and Web Server endpoints at any time after installation.

For additional security, StarlingX optionally supports storing the private key of the StarlingX Rest and Web Server certificate in a StarlingX TPM hardware device. TPM 2.0-compliant hardware must be available on the controller hosts.

Kubernetes

For the Kubernetes API Server, HTTPS is always enabled. Similarly, by default, a self-signed certificate and key is generated and installed for the Kubernetes Root CA certificate and key. This Kubernetes Root CA is used to create and sign various certificates used within Kubernetes, including the certificate used by the kube-apiserver API endpoint.

It is recommended that you update the Kubernetes Root CA and with a custom Root CA certificate and key, generated by yourself, and trusted by external servers connecting to the StarlingX system’s Kubernetes API endpoint. The system’s Kubernetes Root CA is configured as part of the bootstrap during installation.

Local Docker registry

For the local Docker registry, HTTPS is always enabled. Similarly, by default, a self-signed certificate and key is generated and installed for this endpoint. However, it is recommended that you update the certificate used after installation with a Root CA-signed certificate and key. Refer to the documentation for the external CA that you are using, on how to create public certificate and private key pairs for HTTPS.

Trusted CAs

StarlingX also supports the ability to update the trusted CA certificate bundle on all nodes in the system. This is required, for example, when container images are being pulled from an external docker registry with a certificate signed by a non-well-known CA.