Feature Overview (aka. Goal Summary)

Provide a way to configure API server certificates that have been issued by a custom CA.

Goals (aka. expected user outcomes)

The goal of this feature is to enable MicroShift administrators to configure a custom server certificate that has been issued by a customer CA and is then used by the k8s API server endpoint

Requirements (aka. Acceptance Criteria):

• The simplest solution is to provide a config for the API server to point it to the cert to be used: 

apiServer:
customCertificate:
certFile: <pathToCRTFile>
keyFile: <pathToKeyFile>

• Alternatively, if not too complex to implement, a list of named certificates can be configured. Depending on the host named given in the TLS-SNI header, this first matching  cert is used. This is helpful to use different certs e.g. for internal and external traffic:

apiServer:
namedCertificates:
- certFile: <pathToCert-A>
keyFile: <pathToKey-A>
names:
- "internal-a.example.com"
- certFile: <pathToCert-B>
keyFile: <pathToKey-B>
names:
- "external-B.example.com"
- "something.else.com"
_ "*.apps.external.com" # Wildcards must be supported, too!

Out of Scope

1. Other endpoints - this is only for the k8s APi server endpoint
2. certificate rotation: if custom CAs are used, it is the responsibility of the administrator to replace expiring certs
3. hostname or IP address changes. MicroShift can be used in environments where host- and/or IP addresses change dynamically. With the built in CA, certs are then automatically re-generated and adjusted. This will not happen with custom certs. It is the responsibility of the administrator to either create new certs, or provide a sensible list of System Alternate Names (SAN) entries in their custom cert.
4. Client certificates. MicroShift uses client certificates issued by the built in CA to authenticate. Those would still be used and issued by the built in CA.

Background

Customer  esp. in the public sector / defense community have very strict requirements regarding TLS certs. There are frequently intermediate proxies which allow only TLS traffic with certs from accpeted CAs. In those scenarios, it is next to impossible to read 

Open Question

1. The custom cert is issued by a custom CA. Where does this CA Certificat (trust root) need to be added for everything to work? At the server os level (e.g. in the RHEL trust root, or as additional trustedCABundle config option)? At the client (e.g. kubeconfig certificate-authority-data field)

Customer Considerations

See out of scope statements.

Documentation Considerations

This will need docs instructions how to configure it.

Interoperability Considerations

1. Need to verify with ACM/ACS if they could handle a different API / CA. Assumption is yes, as OCP can also change API server certs.
2.