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
4.2 KiB
Executable File
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.
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 .