5579744656
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
100 lines
3.6 KiB
ReStructuredText
100 lines
3.6 KiB
ReStructuredText
|
|
.. ddq1552672412979
|
|
.. _https-access-overview:
|
|
|
|
=====================
|
|
HTTPS Access Overview
|
|
=====================
|
|
|
|
You can enable secure HTTPS access and manage HTTPS certificates for all
|
|
external |prod| service endpoints.
|
|
|
|
These include:
|
|
|
|
|
|
.. _https-access-overview-ul-eyn-5ln-gjb:
|
|
|
|
.. contents::
|
|
:local:
|
|
:depth: 1
|
|
|
|
.. _https-access-overview-section-N10048-N10024-N10001:
|
|
|
|
-------------------------------------------------------
|
|
REST API Applications and the web administration server
|
|
-------------------------------------------------------
|
|
|
|
By default, |prod| provides HTTP access to REST API application endpoints
|
|
\(Keystone, Barbican and |prod|\) 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 |prod| 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 |CA|-signed certificate
|
|
and key are required. The use of an intermediate or Root |CA|-signed
|
|
certificate is strongly recommended. Refer to the documentation for the
|
|
external intermediate or Root |CA| that you are using, on how to create public
|
|
certificate and private key pairs, signed by an intermediate or Root |CA|, for
|
|
HTTPS.
|
|
|
|
You can update the certificate and key used by |prod| for the
|
|
REST and Web Server endpoints at any time after installation.
|
|
|
|
For additional security, |prod| optionally supports storing the private key
|
|
of the StarlingX REST and Web Server certificate in a |prod| |TPM| hardware
|
|
device. |TPM| 2.0-compliant hardware must be available on the controller
|
|
hosts.
|
|
|
|
|
|
.. _https-access-overview-section-N1004F-N10024-N10001:
|
|
|
|
----------
|
|
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 |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 your
|
|
external servers connecting to |prod|'s Kubernetes API endpoint. The |prod|'s
|
|
Kubernetes Root |CA| is configured as part of the bootstrap during
|
|
installation.
|
|
|
|
|
|
.. _https-access-overview-section-N10094-N10024-N10001:
|
|
|
|
---------------------
|
|
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 |CA|-signed certificate and key.
|
|
Refer to the documentation for the external intermediate or Root |CA| that you
|
|
are using, on how to create public certificate and private key pairs, signed by
|
|
a Root |CA|, for HTTPS.
|
|
|
|
|
|
.. _https-access-overview-section-N10086-N10024-N10001:
|
|
|
|
-----------
|
|
Trusted CAs
|
|
-----------
|
|
|
|
|prod| 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|.
|
|
|