BlogSupportDocumentation
TigerTrust
Solutions · Kubernetes

Certificates in Kubernetes, the way they were meant to work.

Ingress TLS, mTLS between pods, service-mesh identities, ephemeral job credentials — all managed with cert-manager compatibility, CSI-driver mounts, and CRDs that fit your GitOps workflow.

Book a demoTalk to a Kubernetes expert
The problem

cert-manager is table stakes. The CA behind it is the problem.

Every K8s cluster grows a cert-manager install pointed at a Let's Encrypt or self-signed CA. That works until compliance shows up asking about your root, your audit trail, and how you rotate across 200 clusters.

Without Kubernetes-native PKI
  • Self-signed cluster CAs proliferate — no single root of trust
  • Let's Encrypt rate limits break scale events and CI reissuance
  • No centralised inventory across the cluster fleet
  • Service mesh mTLS rotates every 24 hours — nobody knows if it works
  • Renewing an intermediate means touching every cluster
With TigerTrust Kubernetes PKI
  • cert-manager ClusterIssuer / Issuer — plugs in without workflow changes
  • CSI driver mounts short-lived certs directly into pod filesystems
  • Fleet-wide inventory across every cluster and namespace
  • Native trust root for Istio, Linkerd, Consul Connect
  • Rotate intermediates centrally; clusters pick up the new chain automatically
cert-manager compatible

Drop-in ClusterIssuer for existing workflows

Point your existing cert-manager Certificate resources at TigerTrust. Every workflow — Ingress annotations, Gateway API references, Helm chart values — keeps working with a stronger CA behind them.

How it works
  • ClusterIssuer and Issuer CRDs
  • Gateway API and Ingress support
  • Namespaced RBAC for multi-tenant clusters
  • Prometheus metrics for issuance
Kubernetes control plane running workloads at scale
Pod certificates

CSI driver mounts fresh certs into every pod

Pods mount certificates from the TigerTrust CSI volume like any other filesystem. Rotation happens under the pod without a restart. Zero application changes.

How it works
  • CSI SecretProviderClass integration
  • In-pod rotation without restart
  • File-based or env-var delivery
  • Sidecar-free operation
Container pods with encrypted communication
Service mesh

Be the trust root for Istio, Linkerd, Consul

Replace the default mesh CA with a TigerTrust root. Every workload identity — including cross-cluster and cross-mesh — flows through one auditable authority.

How it works
  • Istio Citadel replacement
  • Linkerd identity issuer
  • Consul Connect CA
  • SPIFFE-compatible workload IDs
Service mesh topology across multiple Kubernetes clusters
Fleet management

One control plane across every cluster

Manage 200 clusters like they were one. Central policy, per-cluster tenants, global inventory, and audit that spans regions.

How it works
  • Multi-cluster inventory
  • Cluster tenants with RBAC
  • Global policy replication
  • Cross-cluster mesh federation
Fleet of Kubernetes clusters managed from a single dashboard
Kubernetes-native primitives

Feels like Kubernetes. Delivers like enterprise PKI.

Every piece designed for the CNCF stack — CRDs, controllers, CSI, RBAC, all first-class.

cert-manager ClusterIssuer
Drop-in issuer for existing cert-manager workflows.
  • Cluster & namespace scoped
  • Gateway API
  • Ingress annotations
CSI driver
Mount short-lived certs directly into pods.
  • No sidecar needed
  • Auto-rotation
  • Multiple mount points
Service mesh CA
Root of trust for Istio, Linkerd, Consul.
  • SPIFFE workload IDs
  • Cross-cluster
  • Federation ready
Zero-downtime rotation
Health-gated cutover with automatic rollback.
  • Canary rollout
  • Pre-flight checks
  • Sub-second reissue
Namespaced RBAC
Per-team issuers with per-namespace policy.
  • SSO-mapped roles
  • Attribute policies
  • Least-privilege issuance
Observability
Prometheus, OpenTelemetry, Grafana dashboards.
  • Expiry SLIs
  • Issuance latency
  • Cluster health

From Kubernetes deployments

200+
Clusters per control plane
<1s
CSI-mounted issuance latency
100K+
Certificates per cluster
99.99%
Rotation success rate
Case study
Hyperscale · SaaS platform

220 clusters, one policy plane, zero mTLS incidents.

“Every cluster we spin up joins the trust root automatically. cert-manager Certificate CRDs just work — the platform team stopped being the CA team.”
— Staff Platform Engineer
220
Clusters per control plane
100K+
Certificates per cluster
99.99%
Rotation success rate
Integrations

Fits your existing stack

Every Kubernetes distribution, mesh, and GitOps tool the CNCF stack ships with.

Amazon EKS
Distribution
Azure AKS
Distribution
Google GKE
Distribution
Red Hat OpenShift
Distribution
Rancher / RKE2
Distribution
cert-manager
Controller
Istio
Mesh
Linkerd
Mesh
Consul Connect
Mesh
SPIRE
Identity
ArgoCD
GitOps
Kyverno
Policy
Explore all integrations
FAQ

Frequently asked questions

cert-manager is the controller — TigerTrust is the CA and control plane behind it. cert-manager lets you declare Certificate resources; it needs an issuer to fulfil them. Common issuers (Let's Encrypt, self-signed, in-cluster CA) run out of steam at scale. TigerTrust plugs in as a ClusterIssuer and provides the enterprise-grade CA, fleet-wide inventory, and audit trail cert-manager alone cannot deliver.
No. The CSI driver runs as a DaemonSet and mounts certificates into pod filesystems as a CSI volume. Rotation happens under the pod without a restart via atomic symlink swap once the new cert validates. Your application reads the cert like any other file. No sidecar, no init container, no code change.
Yes. A regional TigerTrust cluster can operate disconnected with periodic sync to the global control plane. Talos and edge distributions are supported with a minimal footprint control plane. Policy pulls from Git; audit logs push on reconnect. Kubernetes CSR API and cert-manager both work in disconnected mode.
For Istio: TigerTrust becomes the upstream trust root for Citadel, or replaces Citadel entirely as the workload CA. For Linkerd: TigerTrust issues the identity anchor and intermediates. For Consul Connect: TigerTrust is configured as the Connect CA provider. All three produce SPIFFE-compatible SVIDs, so cross-mesh federation works out of the box.
Issuers can be cluster-scoped or namespace-scoped. Namespace Issuers let each team operate independently — team A can only request certs from their issuer, with their algorithm allow-list and TTL bounds. RBAC bindings map to your SSO groups so a Backstage or Platform Portal shows only the resources a user can act on. Policy inheritance means central guardrails apply to every namespace.
Prometheus metrics on issuance count, latency (p50/p95/p99), and error rate — per issuer and per namespace. OpenTelemetry traces for the full issuance path. Structured logs for every action. Ready-made Grafana dashboards ship for cluster health, cert expiry SLIs, and rotation success. Expiry alerts feed into your existing alerting stack.
Related resources

Keep exploring

Product

Kubernetes CLM

The cert-manager and CSI implementation in detail.

Read more
Solution

Cloud-native

SPIFFE workload identity and API-first primitives.

Read more
Solution

DevOps

CI/CD plugins and Terraform providers for platform teams.

Read more
Solution

Multi-cloud

One control plane across EKS, AKS, GKE, and on-prem.

Read more

mTLS everywhere, without the operations pain.

Request a Kubernetes demoTalk to a Kubernetes expert