Ron Stone 3143d86b69 Openstack planning

Updates for patchset 2 review comments
Changed link depth of main Planning index and added some narrative guidance
Added planning/openstack as sibling of planning/kubernetes
Related additions to abbrevs.txt
Added max-workers substitution to accomodate StarlingX/vendor variants

Signed-off-by: Ron Stone <ronald.stone@windriver.com>
Change-Id: Ibff9af74ab3f2c00958eff0e33c91465f1dab6b4
Signed-off-by: Stone <ronald.stone@windriver.com>

2021-01-25 08:36:47 -05:00

4.4 KiB

Executable File

Raw Blame History

HTTPS Access Planning

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

These include:

Note

Only self-signed or Root -signed certificates are supported for the above 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 for the system.

Note

The default HTTPS X.509 certificates that are used by 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 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, 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 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 -signed certificate and key are required. The use of a Root -signed certificate is strongly recommended. Refer to the documentation for the external 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 for the StarlingX REST and Web Server endpoints at any time after installation.

For additional security, optionally supports storing the private key of the StarlingX Rest and Web Server certificate in a StarlingX hardware device. 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 certificate and key. This Kubernetes Root 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 and with a custom Root certificate and key, generated by yourself, and trusted by external servers connecting to the system's Kubernetes API endpoint. The system's Kubernetes Root 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 -signed certificate and key. Refer to the documentation for the external that you are using, on how to create public certificate and private key pairs for HTTPS.

Trusted CAs

also supports the ability to update the trusted 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 .

4.4 KiB Executable File Raw Blame History