Kubernetes CLM
Certificate lifecycle management, Kubernetes-native.
Automate certificate management across every cluster. Native integration with cert-manager, Ingress controllers, and service meshes for seamless TLS automation — from a single control plane.
kubectl · tigertrust-prod
$kubectl get certificates -A
NSNAMESTATUSAGE
prodapi-tls● Ready47d
prodingress-tls● Ready12d
prodgrpc-mtls● Ready3d
stagingapp-tls● Ready18d
stagingauth-tls◐ Renew85d
infravault-tls● Ready21d
inframesh-ca● Ready6d
7 certs · 6 Ready · 1 renewing · watched by tigertrust-operator
cert-manager · v1.16
Certificate resourcesapiVersion: cert-manager.io/v1
prod/api-tls
auto-renew2160h
renew 360h
staging/auth-tls
auto-renew2160h
renew 360h
infra/vault-tls
auto-renew8760h
renew 720h
Ingress · Gateway API · Service Mesh — one control loop
cert-manager
Native cert-manager integration
Ship as a cert-manager Issuer or ClusterIssuer. Custom Resources, automatic renewal, and policy-driven issuance — all operating the way Kubernetes expects.
How it works
- Custom Issuer and ClusterIssuer support
- Automatic renewal on the cert-manager schedule
- Certificate policies enforced at admission
- CRD-first configuration
Ingress TLS
TLS for every Ingress, automatically
Watches Ingress resources across every namespace and provisions TLS automatically. Wildcard and multi-domain SANs handled without manual coordination.
How it works
- NGINX, Traefik, and Istio Gateway support
- Wildcard certificates
- Multi-domain SANs
- Namespace-scoped or cluster-wide
Service mesh
mTLS certificates for Istio and Linkerd
Issue and rotate short-lived workload identity certificates for your mesh. Bring your own root CA and let TigerTrust operate the intermediates.
How it works
- Istio integration via SDS
- Linkerd identity issuer
- Custom CA roots
- Short-lived workload certs
Multi-cluster
One control plane for every cluster
Manage EKS, GKE, AKS, and on-premise clusters from a single dashboard. GitOps-friendly configuration with ArgoCD and Flux integration.
How it works
- EKS, GKE, AKS, and self-managed clusters
- ArgoCD and Flux integration
- Version-controlled configuration
- Unified dashboard across environments
Cloud-native certificate management
Built for how Kubernetes actually works. Not bolted on.
Everything Kubernetes teams need to run TLS without spreadsheets.
GitOps workflows
Manage certificate config through ArgoCD, Flux, and version control.
- ArgoCD integration
- Flux support
- Version-controlled config
Security & compliance
RBAC, secret encryption, and full audit logging out of the box.
- RBAC integration
- Secret encryption
- Audit logging
Namespace isolation
Scope Issuers and policies per namespace or per team.
- Namespaced Issuers
- Per-tenant quotas
- Delegated admin
Cloud provider bridges
Issue certificates backed by AWS PCA, GCP CAS, or Azure Key Vault.
- AWS Private CA
- GCP CA Service
- Azure Key Vault CA
Cluster fleet visibility
See every certificate across every cluster in a single inventory.
- Cross-cluster search
- Expiry heatmap
- Owner attribution
Zero-touch renewal
Renewals happen before expiry and roll out with pod-safe rotation.
- Policy-driven renewal
- Pod-safe rotation
- Rollback on failure
From production clusters
100K+
K8s certs managed
500+
Clusters connected
99.99%
Renewal success rate
Case study
Global · SaaS platform
Managed 180k mTLS certificates across 240 clusters — from one console.
“Every cluster had its own cert-manager config drift. TigerTrust became the single Issuer, we deleted a hundred YAML files, and mTLS just works — pod-safe rotations included.”
240
Clusters unified
180k
mTLS certs under management
99.99%
Rotation success rate
Integrations
Works with every tool in your stack
Ships as first-class citizens in the cloud-native ecosystem you already run.
cert-manager
K8s
Istio
Service Mesh
Linkerd
Service Mesh
HashiCorp Vault
Secrets
Kyverno
Policy
OPA Gatekeeper
Policy
ArgoCD
GitOps
Flux
GitOps
AWS Private CA
Cloud CA
GCP CAS
Cloud CA
Azure Key Vault
Cloud CA
Prometheus
Monitoring
FAQ
Frequently asked questions
TigerTrust plugs into cert-manager as an Issuer/ClusterIssuer — you keep using the CRDs your team already knows. What you add: cross-cluster visibility (see every certificate in every cluster from one console), a real CA backend with HSM-backed keys, policy enforcement across namespaces (Kyverno/OPA rules against certificate resources), and one place to manage renewals when things go wrong. cert-manager stays the reconciler; TigerTrust is the CA and the control plane.
Istio via the SDS protocol (workload identity certificates), Linkerd as the identity issuer, Consul Connect via the CA provider interface, and Cilium via Hubble mTLS. For each mesh TigerTrust can be the root CA, an intermediate under your existing root, or a shared root across meshes — enabling cross-mesh workload trust. Short-lived workload certificates (5-60 min TTLs) are the default; longer TTLs are configurable per policy.
For Ingress and Gateway resources, TigerTrust writes the new Secret before the old one expires and triggers a controller reload (nginx, Traefik, Envoy) — no pod restart. For service mesh workloads, SDS delivers new certificates in-process without touching the pod. For custom workloads that consume Secrets directly, the rolling-restart hook is optional and rate-limited to protect availability. Health checks verify the swap before the old certificate is revoked.
Yes, and it's the recommended pattern. All TigerTrust resources — Issuers, Certificates, policies — are CRDs that ArgoCD or Flux reconciles from your git repo. Sync waves are respected so Issuers install before Certificates. Sealed Secrets or SOPS-encrypted values are supported for any bootstrap credentials. Drift detection surfaces manual changes made to certificate resources outside git.
Production tenants run 500+ clusters against a single TigerTrust control plane. Each cluster runs a lightweight agent that maintains a single outbound mTLS connection — no inbound firewall changes required. Cross-cluster search, expiry heatmaps, and policy application happen in near-real-time even at scale. Multi-region control planes are available for latency-sensitive fleets.
Yes. Options include: (1) TigerTrust operates intermediate CAs that chain to your existing offline root; (2) each cluster gets a scoped intermediate under a shared root for tenant isolation; (3) per-mesh roots with cross-signed trust bundles for cross-mesh workloads. All keys stay in HSMs (yours or ours). The root never has to touch the cluster.
Related resources
Continue exploring
Product
PKI as a Service
The managed CA that backs your Kubernetes Issuers — HSMs included.
Read more
Product
SSL Certificate Discovery
Find every certificate across every cluster before you automate.
Read more
Solution
Kubernetes
Reference patterns for cert-manager, Istio, Linkerd, and multi-cluster fleets.
Read more
Solution
Cloud-native
PKI patterns for platform teams standardising on Kubernetes and service mesh.
Read more