Key Concepts: Cert-manager, Issuers, and Secrets
By default API Connect uses an open source product that is called cert-manager to handle the issuing and renewal of the certificates that are used by API Connect. The cert-manager has its own Kubernetes pods and runs in its own namespace. The cert-manager adds some additional resources to the Kubernetes environment. The API Connect administrator needs to be familiar with these additional resources:
Issuers play the part of certificate authorities (CAs) in the local environment and issue the certificates. Issuers reside in the API Connect namespace. There are two types of Issuers:
- Self-Signed - This issuer provides the self-signed certificates, for example a root CA.
- CA - This issuer can be either the root certificate authority or an intermediate certificate authority .
kubectl get issuers NAME READY AGE abc-management-ca True 96d selfsigning-issuer True 96d
selfsigning-issuerThis is a SelfSigned Issuer that provides the root certificate for all default certificates that are used in API Connect.
abc-management-caThis is a CA Issuer that signs all the end-entity certificates that are used by the Management Server. It is in effect an intermediate CA between the Root (selfsigning-issuer) and the end-entity certificates.
A certificate is a Kubernetes resource that contains a pointer to a Kubernetes secret which contains the actual TLS certificate. Certificate objects contain other information such as the certificate Issuer, renew-by date, and a status. Below are some of the Certificates that can be found on the Management Server:
The first in the list 'abc-management-ca' is the intermediate CA Certificate that is used for signing all the other certificates below it. Describing this resource observe that it is itself issued by the selfsigning-issuer mentioned earlier:
kubectl get certificate NAME READY SECRET AGE abc-management-ca True abc-management-ca 96d abc-management-client True abc-management-client 96d abc-management-natscluster-mgmt True abc-management-natscluster-mgmt 96d abc-management-server True abc-management-server 96d ...
Describing the subsequent certificates, observe they are all issued by the abc-management-ca:
Issuer Ref: Kind: Issuer Name: selfsigning-issuer
Issuer Ref: Kind: Issuer Name: abc-management-ca
- The certificates with '-ca' on the end are all CA Certificates, and they sign all the other subsystem certificates that whose names do not end with '-ca'.
- The CA certificates are also known as Issuer certificates.
- Certificates that are signed by the CA certificates are known as end-entity certificates.
- When a CA certificate is updated, all end-entity certificates that are signed by it must also be updated.
This is the standard Kubernetes resource for storing credentials, and for API Connect these are where the certificates are stored.
Notice the output from 'kubectl get certificate' above had a 'Secret' column. This is a shorthand way to know the certificate's corresponding Secret, as defined in its 'Secret Name' property:
Below is the describe output for above Secret, showing that it contains the tls certificates:
kubectl describe certificate abc-management-client | grep "Secret Name" Secret Name: abc-management-client
The certificates themselves can be seen with
kubectl describe secret abc-management-client Name: abc-management-client Namespace: default Labels: app.kubernetes.io/instance=abc-management app.kubernetes.io/managed-by=ibm-apiconnect app.kubernetes.io/name=abc-management-client Annotations: cert-manager.io/alt-names: cert-manager.io/certificate-name: abc-management-client cert-manager.io/common-name: abc-management-client cert-manager.io/ip-sans: cert-manager.io/issuer-group: cert-manager.io/issuer-kind: Issuer cert-manager.io/issuer-name: abc-management-ca cert-manager.io/uri-sans: Type: kubernetes.io/tls Data ==== ca.crt: 1107 bytes tls.crt: 1139 bytes tls.key: 1675 bytes
kubectl get -o yaml secret abc-management-client.