3adaa45e61
Remove customer documentation of TPM mode of certificate install. Fix merge conflict Story: 2009712 Task: 44087 Signed-off-by: Ron Stone <ronald.stone@windriver.com> Change-Id: Iaf4d0d288181f0feb10af58f3ce361f1a8ea5324
106 lines
4.2 KiB
ReStructuredText
Executable File
106 lines
4.2 KiB
ReStructuredText
Executable File
|
|
.. cxj1582060027471
|
|
.. _installation-and-resource-planning-https-access-planning:
|
|
|
|
=====================
|
|
HTTPS Access Planning
|
|
=====================
|
|
|
|
You can enable secure HTTPS access and manage HTTPS certificates for all
|
|
external |prod| service endpoints.
|
|
|
|
These include:
|
|
|
|
.. _installation-and-resource-planning-https-access-planning-d18e34:
|
|
|
|
.. contents:: |minitoc|
|
|
:local:
|
|
:depth: 1
|
|
|
|
.. note::
|
|
Only self-signed or Root |CA|-signed certificates are supported for the
|
|
above |prod| service endpoints. See `https://en.wikipedia.org/wiki/X.509
|
|
<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 |prod| system.
|
|
|
|
.. note::
|
|
The default HTTPS X.509 certificates that are used by |prod-long| 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.
|
|
|
|
|
|
.. _installation-and-resource-planning-https-access-planning-d18e75:
|
|
|
|
-----------------------------------------------------------------
|
|
StarlingX REST API applications and the web administration server
|
|
-----------------------------------------------------------------
|
|
|
|
By default, |prod| 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 |prod| 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 |prod| for the StarlingX REST
|
|
and Web Server endpoints at any time after installation.
|
|
|
|
|
|
.. _installation-and-resource-planning-https-access-planning-d18e105:
|
|
|
|
----------
|
|
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 |prod| system's Kubernetes API endpoint. The system's
|
|
Kubernetes Root |CA| is configured as part of the bootstrap during
|
|
installation.
|
|
|
|
|
|
.. _installation-and-resource-planning-https-access-planning-d18e117:
|
|
|
|
---------------------
|
|
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.
|
|
|
|
.. _installation-and-resource-planning-https-access-planning-d18e126:
|
|
|
|
-----------
|
|
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|.
|
|
|