The IBM Cloud Certificate Manager Service is being deprecated at the end of 2022, with any remaining instances being deleted on December 31, 2022. Please see the official IBM Cloud Certificate Manager deprecation announcement here.
Currently, the IBM Cloud Kubernetes Service and Red Hat OpenShift on IBM Cloud each provision one instance of Certificate Manager at cluster creation that lives for the lifecycle of the cluster. Any Ingress subdomains that live under ibmcloud nlb-dns ls then have their Let's Encrypt Certificates uploaded into the Certificate Manager instance. Additionally, any Kubernetes secrets created through the ibmcloud ks ingress secret create api using certificate CRNs correlated to the integrated Certificate Manager instance would be automatically updated in the cluster anytime the certificate was updated via the callback functionality offered by Certificate Manager.
As the strategic direction of managing certificates is moving to IBM Cloud Secrets Manager, naturally the Kubernetes Service integration will also move as well. Starting April 11, 2022, A new api in the CLI ibmcloud ks ingress secret instance register will allow users to integrate their own Secrets Manager instance with their Kubernetes cluster and set one as the default for any Ingress Subdomain certificates to be automatically uploaded to. Additionally, the current ibmcloud ks ingress secret api will be expanded to allow users to additionally utilize Secrets Manager to create Kubernetes secrets using a valid CRN.
Using the ibmcloud ks ingress instance CLI api
The ibmcloud ks ingress instance CLI allows users to register IBM Cloud Secrets Manager and IBM Cloud Certificate Manager instances. Registering a default instance with ibmcloud ks ingress instance register --is-default will configure any newly generated or regenerated Ingress TLS Certificates to be uploaded to that instance. This will allow users to provision an instance of their choice and register it to have their Ingress TLS Certificates uploaded to.
ibmcloud ks ingress instance
NAME:
ibmcloud ks ingress instance - Manage registered instances of the IBM Cloud Secrets Manager.
COMMANDS:
default Update the default configuration of a registered IBM Cloud Secrets Manager instance.
get View the details of an IBM Cloud Secrets Manager instance.
ls List all instances of the IBM Cloud Secrets Manager.
register Register an IBM Cloud Secrets Manager instance to a cluster.
unregister Unregister an IBM Cloud Secrets Manager instance from a cluster.
Using the extended ibmcloud ks ingress secret CLI api
The ibmcloud ks ingress secret CLI has been expanded to allow users to create opaque secrets . An opaque secret allows users to create secrets in their cluster with multiple non certificate CRNs using a CLI command like ibmcloud ks ingress secret create --type opaque --field <crn>. The previous secret type TLS is still supported and will be the default type if not explicitly passed in.
ibmcloud ks ingress secret
NAME:
ibmcloud ks ingress secret - Manage Ingress secrets in a cluster.
COMMANDS:
create Create an Ingress secret in a cluster for a secret stored in IBM Cloud Secret Manager.
field Manage the fields of an Ingress secret.
get View the details of an Ingress secret.
ls List all Ingress secrets in a cluster.
rm Remove an Ingress secret from a cluster.
update Update an existing Ingress secret.
FAQ
Will a secrets manager instance be auto generated with every cluster?
As the Secrets Manager service is a paid service, a Secrets Manager instance will not be generated with every cluster. However, a new API will allow users to bring their own Secrets Manager instance and register one as the default for Ingress subdomain certificates to be uploaded to.
How will migration work?
An API will be released allowing a default Secrets Manager instance to be associated with a cluster and will upload the ingress subdomain certificate to that instance on the next renewal. If the customers want the certificates uploaded to the Secrets Manager instance sooner, they can run the ibmcloud ks nlb-dns secret regenerate command. However, if a user previously created a user-provisioned secret using a certificate CRN from the default provisioned IBM Cloud Certificate Manager instance, and later sets a new default instance, they will need to update those secrets with the new certificate CRNs. For user provided certificates, the user will be responsible for migrating (see the Secrets Manager migration tool here).
Will the callback functionality be maintained?
The functionality that allows for the ingress secrets to be automatically updated in the clusters is intended to be maintained.
When will Certificate Manager instances no longer be auto provisioned at cluster creation?
Starting August 1, 2022, Certificate Manager instances will no longer be provisioned at cluster creation. Any existing Certificate Manager instances integrated with a cluster will continue to live throughout the lifecycle of the cluster until December 31, 2022 when they will be deleted by the Certificate Manager service itself.
Will multiple secret types be supported?
Previously, only TLS secrets were supported with Certificate Manager. With the new Secrets Manager integration, all the secret types supported by Secrets Manager are planned to be supported. Additionally, with the new secret types, any non-certificate secrets will allow for a many to one relationship of many Secrets Manager secret CRNs associated with one Kubernetes secret.
For general questions, engage our team via Slack by registering here and join the discussion in the #general or #openshift channels on our public Slack.