cert-manager
This feature is an Enterprise feature. See our pricing plans or contact our sales team for more information.
You can integrate cert-manager with your tenant cluster to manage TLS certificates across control plane and tenant environments.
Prerequisites
-
Administrator access to a Kubernetes cluster: See Accessing Clusters with kubectl for more information. Run the command
kubectl auth can-i create clusterrole -Ato verify that your current kube-context has administrative privileges.infoTo obtain a kube-context with admin access, ensure you have the necessary credentials and permissions for your Kubernetes cluster. This typically involves using
kubectl configcommands or authenticating through your cloud provider's CLI tools. -
helm: Helm v3.10 is required for deploying the platform. Refer to the Helm Installation Guide if you need to install it. -
kubectl: Kubernetes command-line tool for interacting with the cluster. See Install and Set Up kubectl for installation instructions.
- cert-manager operator installed on your control plane cluster. For setup instructions, see the cert-manager installation guide.
Enable the integration
Enable cert-manager integration in your tenant cluster configuration:
integrations:
certManager:
enabled: true
This configuration enables the integration and configures automatic resource sync:
- Imports: Cluster-scoped
ClusterIssuersfrom your control plane cluster into the tenant cluster - Exports: Namespaced
IssuersandCertificatesfrom the tenant cluster to the control plane cluster - Syncs: Generated certificate secrets back to the tenant cluster automatically
Set up cluster contexts
Create or update a tenant cluster following the vCluster quick start guide. Configure cluster contexts to simplify switching between control plane and tenant clusters:
export HOST_CTX="your-host-context"
export VCLUSTER_CTX="vcluster-ctx"
Run kubectl config get-contexts to list available contexts.
Certificate issuer configurations
Choose the appropriate certificate issuer based on your security and operational requirements.
Self-signed certificates for development
Self-signed certificates work well for development environments and internal services that don't require public trust.
Tenant Cluster Create a self-signed issuer
self-signed-issuer.yamlapiVersion: cert-manager.io/v1kind: Issuermetadata:name: selfsigned-issuernamespace: defaultspec:selfSigned: {}Apply the issuer:
Apply self-signed issuerkubectl --context=$VCLUSTER_CTX apply -f self-signed-issuer.yamlTenant Cluster Create a certificate
self-signed-certificate.yamlapiVersion: cert-manager.io/v1kind: Certificatemetadata:name: app-tls-certnamespace: defaultspec:secretName: app-tls-secretduration: 2160h # 90 daysrenewBefore: 360h # 15 dayscommonName: myapp.localdnsNames:- myapp.local- api.myapp.localprivateKey:algorithm: RSAsize: 2048issuerRef:name: selfsigned-issuerkind: IssuerApply the certificate:
Apply certificatekubectl --context=$VCLUSTER_CTX apply -f self-signed-certificate.yaml
Self-signed certificates generate browser warnings and should not be used in production environments accessible to external users.
Private PKI for enterprise environments
Private PKI configurations provide enterprise-grade certificate management with custom certificate authorities.
Control Plane Cluster Create a root CA certificate
Create a self-signed root CA in the control plane cluster (ClusterIssuers are imported from control plane to tenant cluster):
root-ca.yamlapiVersion: cert-manager.io/v1kind: ClusterIssuermetadata:name: selfsigned-issuerspec:selfSigned: {}---apiVersion: cert-manager.io/v1kind: Certificatemetadata:name: root-ca-certnamespace: cert-managerspec:isCA: truecommonName: "Enterprise Root CA"subject:organizations:- "Enterprise Corp"organizationalUnits:- "IT Security"countries:- "US"secretName: root-ca-secretduration: 87600h # 10 yearsrenewBefore: 78840h # 9 yearsprivateKey:algorithm: ECDSAsize: 256issuerRef:name: selfsigned-issuerkind: ClusterIssuerApply in the control plane cluster:
Apply root CA in control plane clusterkubectl --context=$HOST_CTX apply -f root-ca.yamlControl Plane Cluster Create a CA issuer
ca-issuer.yamlapiVersion: cert-manager.io/v1kind: ClusterIssuermetadata:name: enterprise-ca-issuerspec:ca:secretName: root-ca-secretApply in the control plane cluster:
Apply CA issuer in control plane clusterkubectl --context=$HOST_CTX apply -f ca-issuer.yamlTenant Cluster Issue certificates from your CA
ca-signed-certificate.yamlapiVersion: cert-manager.io/v1kind: Certificatemetadata:name: enterprise-app-certnamespace: defaultspec:secretName: enterprise-app-tlsduration: 8760h # 1 yearrenewBefore: 720h # 30 dayscommonName: myapp.enterprise.localdnsNames:- myapp.enterprise.local- api.myapp.enterprise.localsubject:organizations:- "Enterprise Corp"organizationalUnits:- "Application Services"usages:- digital signature- key encipherment- server authissuerRef:name: enterprise-ca-issuerkind: ClusterIssuerApply in the tenant cluster:
Apply certificate in tenant clusterkubectl --context=$VCLUSTER_CTX apply -f ca-signed-certificate.yaml
Security considerations:
- Store root CA private keys securely and offline when possible
- Implement proper certificate lifecycle management
- Monitor certificate expiration dates
- Establish clear revocation procedures
ACME for public-facing services
ACME (Automatic Certificate Management Environment) issuers like Let's Encrypt provide free, automatically-renewed certificates for public-facing services.
Tenant Cluster Create an ACME issuer
acme-issuer.yamlapiVersion: cert-manager.io/v1kind: Issuermetadata:name: letsencrypt-prodnamespace: defaultspec:acme:email: admin@yourdomain.comserver: https://acme-v02.api.letsencrypt.org/directoryprivateKeySecretRef:name: letsencrypt-prod-account-keysolvers:- http01:ingress:ingressClassName: nginx # the ingress-nginx project has been deprecated, we recommend using a different ingress class- dns01:cloudflare:email: admin@yourdomain.comapiKeySecretRef:name: cloudflare-api-key-secretkey: api-keyTenant Cluster Create an ACME certificate
acme-certificate.yamlapiVersion: cert-manager.io/v1kind: Certificatemetadata:name: public-app-certnamespace: defaultspec:secretName: public-app-secretduration: 2160h # 90 daysrenewBefore: 720h # 30 daysdnsNames:- myapp.example.com- api.myapp.example.comissuerRef:name: letsencrypt-prodkind: Issuer
Rate limits: Let's Encrypt enforces rate limits. Use staging environment (https://acme-staging-v02.api.letsencrypt.org/directory) for testing.
PKI for compliance requirements
PKI configurations require specific certificate formats and validation procedures for compliance with standards.
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
name: gov-service-cert
namespace: default
spec:
secretName: gov-service-secret
duration: 8760h # 1 year maximum
renewBefore: 2160h # 90 days
commonName: service.application.1234567890
subject:
organizations:
- "Organization"
organizationalUnits:
- "PKI"
- "CONTRACTOR"
countries:
- "US"
usages:
- digital signature
- key encipherment
- server auth
privateKey:
algorithm: RSA
size: 2048 # Federal minimum requirement
issuerRef:
name: gov-pki-issuer
kind: ClusterIssuer
Compliance requirements:
- Use hierarchical 3-tier CA structure
- Include specific Distinguished Name fields
- Maintain Certificate Revocation Lists (CRLs)
- Follow Federal PKI Certificate Policy guidelines
Verify certificate creation
Check that your certificates generate correctly:
Tenant Cluster Check certificate status
Verify certificate creationkubectl --context=$VCLUSTER_CTX describe certificate <certificate-name> -n <namespace>Look for
Ready: Truein the status conditions.Tenant Cluster Verify secret creation
Check certificate secretkubectl --context=$VCLUSTER_CTX get secret <secret-name> -n <namespace> -o yamlConfirm the secret contains
tls.crtandtls.keydata.Control Plane Cluster Confirm synchronization
Check control plane cluster resourceskubectl --context=$HOST_CTX get certificate,issuer -AVerify resources appear in the control plane cluster namespace.
Use certificates in applications
Reference your certificate secrets in Ingress resources:
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: secure-app-ingress
annotations:
kubernetes.io/ingress.class: nginx # ingress-nginx has been deprecated
nginx.ingress.kubernetes.io/ssl-redirect: "true"
spec:
tls:
- hosts:
- myapp.example.com
secretName: your-tls-secret # Use the secretName from your Certificate
rules:
- host: myapp.example.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: app-service
port:
number: 80
Replace your-tls-secret with the actual secretName specified in your Certificate resource (e.g., app-tls-secret, enterprise-app-tls, or public-app-secret from the examples above).
Troubleshooting
Certificate creation issues
Check certificate status:
kubectl --context=$VCLUSTER_CTX describe certificate <name>
Common problems:
- Pending status: Check CertificateRequest events
- Failed validation: Verify DNS/HTTP challenge accessibility
- Rate limiting: Switch to staging ACME server for testing
Examine certificate requests:
kubectl --context=$VCLUSTER_CTX get certificaterequests
kubectl --context=$VCLUSTER_CTX describe certificaterequest <name>
Integration synchronization problems
Verify integration status:
Control Plane Clusterkubectl --context=$HOST_CTX -n cert-manager get pods
kubectl --context=$HOST_CTX -n cert-manager logs deployment/cert-manager
# Check if integration is enabled
kubectl --context=$VCLUSTER_CTX get configmap vcluster-config -o yaml
# Check resource synchronization
kubectl --context=$VCLUSTER_CTX get events --field-selector reason=Sync
Common synchronization issues:
- RBAC permissions missing on control plane cluster
- Network policies blocking communication
- Resource naming conflicts between clusters
ACME challenge failures
For detailed troubleshooting of ACME challenges:
Check challenge status:
kubectl --context=$VCLUSTER_CTX describe order <order-name>
kubectl --context=$VCLUSTER_CTX describe challenge <challenge-name>
For comprehensive ACME troubleshooting, including HTTP-01 and DNS-01 challenge issues, see the cert-manager ACME troubleshooting guide.
For troubleshooting guidance, see the cert-manager troubleshooting documentation.
Advanced configuration
Custom sync configurations
Fine-tune resource synchronization behavior:
integrations:
certManager:
enabled: true
sync:
toHost:
certificates:
enabled: true
issuers:
enabled: true
fromHost:
clusterIssuers:
enabled: true
selector:
labels:
vcluster.loft.sh/managed: "true"
Configuration options:
selector: Filter which ClusterIssuers to import- Individual resource type controls for granular sync management
Configuration reference
certManager required object
CertManager reuses a host cert-manager and makes its CRDs from it available inside the vCluster.
- Certificates and Issuers will be synced from the virtual cluster to the host cluster.
- ClusterIssuers will be synced from the host cluster to the virtual cluster.
certManager required object enabled required boolean false
Enabled defines if this option should be enabled.
enabled required boolean false sync required object
Sync contains advanced configuration for syncing cert-manager resources.
sync required object toHost required object
toHost required object