HTTPS and Certificates Management Overview¶
Certificates are heavily used for secure HTTPS access and authentication on StarlingX platform. This table lists the major certificates being used in the system, and indicates which certificates are automatically created/renewed by the system versus which certificates must be manually created/renewed by the system administrator. Details on manual management of certificates can be found in the following sections.
Certificate |
Auto Created |
Renewal Status |
|---|---|---|
Kubernetes Root CA Certificate |
Yes |
NOT AUTO-RENEWED; Default expiry is set at 10 years; MUST be renewed via CLI. |
Cluster Admin client certificate used by kubectl |
Yes |
auto-renewed by cron job |
kube-controller-manager client certificate |
Yes |
auto-renewed by cron job |
kube-scheduler client certificate |
Yes |
auto-renewed by cron job |
kube-apiserver server certificate |
Yes |
auto-renewed by cron job |
kube-apiserver’s kubelet client certificate |
Yes |
auto-renewed by cron job |
kubelet client certificate |
Yes |
auto-renewed by kubelet feature enabled by default |
etcd Root CA certificate |
Yes |
NOT AUTO-RENEWED; Default expiry is set at 10 years |
etcd server certificate |
Yes |
auto-renewed by cron job |
etcd client certificate |
Yes |
auto-renewed by cron job |
kube-apiserver’s etcd client certificate |
Yes |
auto-renewed by cron job |
StarlingX REST API & HORIZON Server Certificate |
Yes (But the auto-created certificate is self-signed and should be changed) |
auto-renewed if configured with cert-manager; NOT AUTO-RENEWED if configured with system certificate-install .., must be renewed via CLI |
Local Registry Server Certificate |
Yes (But the auto-created certificate is self-signed and should be changed) |
auto-renewed if configured with cert-manager; NOT AUTO-RENEWED if configured with system certificate-install .., must be renewed via CLI |
OIDC Client and Dex Server Server Certificate |
No |
auto-renewed if configured with cert-manager; NOT AUTO-RENEWED if configured with an externally generated certificate, CUSTOMER MUST renew via CLI. |
OIDC Client and Dex Server CA certificate |
No |
NOT AUTO-RENEWED. CUSTOMER MUST renew via CLIs |
OIDC Remote WAD CA Certificate |
No |
NOT AUTO-RENEWED. CUSTOMER MUST renew via CLIs |
Vault Server Certificate |
Yes |
NOT AUTO-RENEWED; CUSTOMER MUST renew via CLIs |
Vault Root CA certificate |
Yes |
NOT AUTO-RENEWED; CUSTOMER MUST renew via CLIs |
Portieris Server Certificate |
Yes |
Auto renewed by cert-manager; BUT CUSTOMER MUST restart Portieris after the certificate is renewed |
Portieris remote registry and notary server CA Certificate |
No |
NOT AUTO-RENEWED; CUSTOMER MUST renew via CLIs |
Root CA DC Admin Endpoint CA Certificate |
Yes |
auto-renewed |
Intermediate CA DC Admin Endpoint CA Certificate |
Yes |
auto-renewed |
DC Admin Endpoint Server Certificate |
Yes |
auto-renewed |
System trusted CA Certificates |
No |
NOT AUTO-RENEWED as these are certificates that are not necessarily owned by the platform |
Where:
Auto created: the certificate is generated during system deployment or triggered by certain operations.
Renewal Status: whether the certificate is renewed automatically by the system when expiry date approaches.
The following sections provide details on managing these certificates.
For further information about certificates expiration date or other certificates information, see Display Certificates Installed on a System. In addition, StarlingX monitors the installed certificates on the system by raising alarms for expire-soon certificates and for expired certificates on the system, see Expiring-Soon and Expired Certificate Alarms.
