Issue and approve certificates with Venafi Control Plane
In this tutorial you will learn how to use the TLS Protect for Kubernetes components: cert-manager, approver-policy-enterprise and venafi-enhanced-issuer. You will configure venafi-enhanced-issuer to sign SSL certificates using Venafi TLS Protect and approver-policy-enterprise to approve certificates using Venafi TLS Protect. And you will configure the components in such a way as to allow application teams to help themselves to SSL certificates, whilst ensuring that the certificates issued to each team can be traced back to that team by the TLS Protect administrator. Additionally, you will learn how to configure the components so that sensitive Venafi Control Plane credentials can be stored securely in a vault, outside the Kubernetes cluster. And the other less sensitive Venafi Control Plane connection details are hidden from the application teams and other tenants on the Kubernetes cluster.
Introduction
Engineers are often organized into security teams, application teams and platform teams. The best practice is to enforce access controls to ensure that these teams have the least privilege necessary do their jobs. This tutorial will show how these teams can each benefit from the careful deployment and configuration of components of the TLS Protect for Kubernetes software suite.
Security Team
Security teams dictate security policies and ensure that engineers and systems comply with that policy. The security team use tools such as TLS Protect Datacenter (TPP) and TLS Protect Cloud (VaaS) from the Venafi Control Plane to codify and enforce policy. Using TLS protect they can set TLS certificate policy at an organizational level and make policy adjustments for different engineering teams. The components of TLS Protect for Kubernetes integrate with Venafi TLS Protect.
cert-manager and venafi-enhanced-issuer allow Kubernetes application teams to help themselves to SSL certificates, without interacting with the security team.
approver-policy-enterprise allows TLS Protect certificate policies to be extended into Kubernetes clusters.
- Cost: Security team saves time through the automation of certificate creation and renewal.
- Control: The security team have increased confidence that organizational policies are being followed.
- Security: By avoiding the sharing of private keys. The private keys are stored in one place (the Kubernetes cluster) rather then being shared between members of the security and application teams.
- Visibility: All the application certificates will appear in the TLS Protect dashboard and can be traced back to the application team that owns them.
Application Team
Application teams are responsible for writing and deploying user facing software applications. They will be able to create and renew SSL / TLS certificates automatically, without any interaction with the platform or security teams. Their certificates will be signed by a trusted certificate authority and their certificates will comply with the organization's security policies. This is in contrast to a more manual approach where the application team would have to request an SSL certificate from the security team and wait for it to be issued.
- Cost: Application teams save time through the automation of certificate creation and renewal.
- Control: SSL Certificates can be automatically provisioned using simple familiar Kubernetes APIs. This allows teams to fully automate the deployment of their applications.
- Security: Automation allows application teams to regularly rotate their certificates, reducing the potential impact of leaked private keys.
- Visibility: Application teams can clearly see the status of their certificates. Errors and warnings are related to certificates are visible to the teams through the status fields of the TLS Protect for Kubernetes and cert-manager API resources.
Platform Team
Platform teams maintain the servers and clusters on which the applications are hosted. They are responsible for the security of these systems and implement access controls to enforce security boundaries between applications and the components of the platform itself.
- Control: cert-manager and venafi-enhanced-issuer have declarative APIs which allows the platform team to configure those components using tools such as Terraform.
- Security: Platform teams (and security teams) are often wary of Kubernetes Secrets especially for the storage of long lived API credentials. venafi-enhanced-issuer can be configured without using Kubernetes Secret resources and instead can use ephemeral Kubernetes Service Account Tokens to authenticate to Venafi TLS Protect, using an intermediate OIDC supporting secret store, such as HashiCorp Vault.
- Visibility: Platform team can monitor the health of the connection to Venafi TLS Protect using the Status fields of the Issuer and ClusterIssuer resources.