Create Self-Signed Server Certificate Pair For Testing Purposes

The cluster administrator can issue self-signed server certificates. For testing purposes, a self-signed certificate pair can be installed on any device where authentication is needed via the web interface, for example on an Ingress client connecting to an Ingress server (section 4.22.12). The configuration is carried out as follows:

The cm-kubernetes-setup wizard is started up on the active head node by the cluster administrator.

The menu item Configure Ingress is selected (figure A.1).

Figure A.1: Option to configure Ingress

The Kubernetes cluster is chosen in the next screen. The Kubernetes cluster is the one on which Ingress is to be configured (figure A.2)

Figure A.2: Prompt for the Kubernetes cluster to configure Ingress for

A prompt appears asking if an existing server certificate pair should be used. Since a self-signed pair is to be used for testing purposes, no is selected (figure A.3)

Figure A.3: Prompt to select existing certificate (choose “no” here for self-signed.)

A list of domains to customize is displayed (figure A.4)

Figure A.4: Prompt for customizing trusted domains that need to be part of the self-signed certificate.

For this example, the domain is customized to superpod.nvidia.local (figure A.5)

Figure A.5: Prompt answered with an entry superpod.nvidia.local

All the names entered end up in the SAN part of the server certificate as valid DNS names. Continuing with Ok executes steps to take care of the configuration (figure A.6)

Figure A.6: The output when the self-signed configuration has completed.

So far in the procedure, the following has been carried out:

• a private CA key pair has been created (ingeress-ca.key and ingress-ca.crt in figure A.7)

• a server certificate (ingress-server.crt) has been made and signed by the private CA

• Ingress has been patched to use the server certificate pair (ingress-server.crt and ingres-server.key)

Figure A.7: The server certificate files on the active head node.

The default in this path is the label of the Kubernetes cluster for which the certificates have been created.

A Note On Using Self-Signed Certificates

The use of self-signed certificates is not recommended. It is only useful for testing purposes. The use of self-signed certificates may cause users can run into obscure issues, where it is hard to uncover that the problem is because of self-signed certificates.

The private key for the server certificate has been uploaded, from its location on the active head node at:
/etc/kubernetes/pki/default/ingress-server.key

The certificate has also been uploaded from its location on the active head node at:
/etc/kubernetes/pki/default/ingress-server.crt

The self-signed CA, taken from: /etc/kubernetes/pki/default/ingress-ca.crt, can alternatively be installed on the local machine (the cluster administrator laptop, for example) in order for the browser to recognize the certificate as trusted. Details are typically OS dependent, but for Chrome on a Linux system it follows a method of accepting the certificate by ignoring a warning about the site certificate being untrusted.

The warning is due to the CA server not being a recognized Certificate Authority (CA) like the CAs that are recognized by a browser.

If there is no internet access to the cluster URL, then the warning about the CA not being a recognized Certificate Authority is not an issue, and the user can simply accept the “untrusted” certificate.

If there is internet access to the cluster URL, then some cluster administrators may regard it as more secure to trust the self-signed certificate rather than external certificate authorities anyway.