egoncalv 5579744656 Editorial updates on Security Guide upstream

Acted on Greg's comments

Patch 1: Deleted duplicated docs and corrected references to fix build failure

Patch 2: Acted on Greg's and Ron's comments.

Patch 3: Acted on Greg's comment.

Patch 4: Acted on Mary's comments.

Patch 5: Solved merge conflict.

Patch 6: Worked on Mary's comments.

Patch 7: Fixed build conflict.

Patch 8: Worked on Mary's comments.

https://review.opendev.org/c/starlingx/docs/+/792461

Signed-off-by: egoncalv <elisamaraaoki.goncalves@windriver.com>
Change-Id: I647711ac35f45bc9c79cc490269831770e98e2f4

2021-06-02 12:28:10 -03:00

3.6 KiB

Raw Blame History

HTTPS Access Overview

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

These include:

REST API Applications and the web administration server

By default, provides HTTP access to REST API application endpoints (Keystone, Barbican and ) and the 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 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, an intermediate or Root -signed certificate and key are required. The use of an intermediate or Root -signed certificate is strongly recommended. Refer to the documentation for the external intermediate or Root that you are using, on how to create public certificate and private key pairs, signed by an intermediate or Root , for HTTPS.

You can update the certificate and key used by for the 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 hardware device. 2.0-compliant hardware must be available on the controller hosts.

Kubernetes

For the Kubernetes API Server, HTTPS is always enabled. You must use a Root CA certificate; intermediate CA certificates are not supported by upstream Kubernetes. 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 your external servers connecting to 's Kubernetes API endpoint. The '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 an intermediate or Root -signed certificate and key. Refer to the documentation for the external intermediate or Root that you are using, on how to create public certificate and private key pairs, signed by a Root , 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 .

3.6 KiB Raw Blame History