Basics of an issuer

In this course, we will look at configuring issuers for cert-manager from TLS Protect for Kubernetes. TLS Protect for Kubernetes simplifies the ability to create issuers by providing a UI driven configuration where users will provide values.

In many organizations, Kubernetes operators may not have all the information about the Certificate Authority to use within their clusters and those who do may or may not actively work on a Kubernetes cluster.

The objective of this course is to get familiar with Issuer configuration and various things to consider when an issuer is configured.

Read the cert-manager documentation for more details about issuers and cluster issuers

What exactly is an Issuer or ClusterIssuer?

As stated in the cert-manager documentation, Issuers and ClusterIssuers are resources in Kubernetes that represent certificate authorities that have the ability to sign certificates by honoring the certificate signing requests sent by TLS Protect for Kubernetes.

There are various classification of issuers.

• Built-in Issuers that are native to cert-manager. Examples include Venafi, Vault, ACME, etc.
• External Issuers that are add-ons and extend the ability of cert-manager. Examples include Google CAS, AWS PCA Issuer, StepCA issuer, etc.
• Enterprise Issuers that are part of the TLS Protect for Kubernetes enterprise that provide value-added capabilities for enterprises. For e.g, isolated-issuer that has the ability to work with enterprise HSM's, Secrets Management tools, etc.

As the name describes, Issuers are namespaced resources and as such are available for use only within the namespace it is configured. Issuers cannot issue certificates for a namespace other than the one it is configured to issue.

In terms of best practices, it is recommended to utilize Issuers to lock down access to a certain namespace, teams that have access to certain namespaces, etc. Most often a team working on an application require access to a private CA where they are able to request certificates with a certain domain. Other teams will have different requirements. Issuers help define the various policies and controls required for managing the identities of various resources like Ingress, Pods, Mesh, etc. in a cluster.

ClusterIssuers, on the other hand, as the name implies is accessible across all namespaces. Most often cluster issuers are created when an issuer configuration is applicable across the cluster. For example, all certificates for sub-domains of example.com must use a specific issuer configuration and it doesn't matter which namespace or team deploys the application. The policy and controls remain the same across.

Login to your TLS Protect for Kubernetes account, access your cluster and click on the issuers tab. If you see a list of issuers (perhaps created by other team members), review each issuer.

Additionally, access the TLS Protect for Kubernetes Integrations catalog for details about all the issuers and documentation specific to each issuer. Here is the link to the integration catalog. Click on Issuers tab for specific details.

Continue to the next chapter to create our own issuer.