Issuer¶

Issuer is a capability of cert-manager enabling integration with machine identity providers. These providers are typically Certificate Authorities which publish digital certificates to secure communication between workloads.

cert-manager is a critical component in the fight to secure your Kubernetes clusters, helping companies modernize with speed and agility. TLS Protect For Kubernetes includes an enterprise-hardened version of cert-manager alongside extensions to support and manage machine identities in the enterprise.

Introduction¶

The chapter on Ingress explains how Kubernetes is broadly unopinionated about the tools you use to fulfill your business demands, such as how you ensure the security of your workloads. The CNCF's move to accept cert-manager as an incubating project solidifies its reputation as the de-facto Kubernetes solution for stopping outages caused by TLS certificate expiry.

Before you begin, it's important to understand the "what" and "why" of Issuers in the context of Kubernetes.

What is it?¶

The Issuer capability in cert-manager extends the Kubernetes API, abstracting away the complexity of machine identity providers inside your clusters. Each Issuer object represents a provider capable of signing and issuing machine identities, typically in the form of X.509 certificates. These providers could be digital security companies you already know and trust, non-profit organizations or just some well-known devices inside your data center. Each provider brings its own strengths and consumer adoption is determined by various factor such as organizational policy, existing infrastructure, business relationships, individual choice and the task at hand. In a Kubernetes architecture which prevents misuse and compromise, use of a cert-manager Issuer is a mandatory requirement.

Why is it necessary?¶

The following diagram is taken from the cert-manager documentation homepage.

Native Issuer support in cert-manager is currently limited to the machine identity providers shown above. As a developer who needs to extend the reach of cert-manager to provide support for an alternate machine identity provider, this design pattern is for you.

FAQs¶

Before you proceed there may be a few initial questions that need addressing, for example:

"What problem will you solve?"

TLS Protect For Kubernetes users need to provide their clusters with a robust mechanism for delivery of machine identities from your CA's.

"What will the outcome be?"

Automated delivery of machine identities from your CA to your Kubernetes clusters and a reduction in outages due to certificate expiry.

"What will you need to deliver?"

You solution will be in the form of Kubernetes controllers and CRDs. Your images will be sourced from a public container registry and installation will be achieved via a Helm chart.

"How will your solution be used?"

Automation via your issuer will be initiated through the use of declarative references inside cert-manager objects.

"What about authentication and authorization?"

From the perspective of cert-manager there will be zero authentication and authorization requirements, but it will likely be a different story from the perspective of your machine identity provider. You may choose to consult with your machine identity provider to ensure that their own best practices are adhered to.

"Why will you want to certify your solution?"

Hop over to our certification section for TLS Protect For Kubernetes to find out more

If you aren't able to find what you're looking for, or have a specific question related to your use case, please post a question to the Developer Forum section of Venafi's Warrior Community or email Venafi Customer Support.