docs/doc/source/security/kubernetes/https-access-overview.rst
Rafael Jardim d95c80d36f Update Security
Fixed merge conflict (RS)

Signed-off-by: Rafael Jardim <rafaeljordao.jardim@windriver.com>
Change-Id: I30b882a14196525f440db1108a56bbf862dfaf55
Signed-off-by: Ron Stone <ronald.stone@windriver.com>
2021-04-01 16:02:36 -04:00

109 lines
3.8 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:
- |prod| REST API applications and the |prod| web administration server
- Kubernetes API
- Local Docker registry
.. contents::
:local:
:depth: 1
You can also add a trusted Certificate Authority \(CA\) for the |prod| system.
.. _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|.