Kubernetes is where certificate lifecycle gets messy fast: every Ingress needs a certificate, every service mesh sidecar has one, cert-manager wants to own renewal but nothing owns visibility. TigerTrust’s Kubernetes section gives you inventory, policy, and — optionally — writeback into the cluster so a rotated certificate lands as an updated secret without a human copying PEMs.
Kubernetes

​
What it is

You register a cluster with TigerTrust, which then discovers all kubernetes.io/tls secrets across namespaces, correlates them with Ingress objects, and imports the certificates into your inventory. Optionally, you enable secret writeback so renewed certificates are pushed directly into the cluster as updated secrets.

​
When to use it

  • Get visibility into every TLS secret across all namespaces without running kubectl manually.
  • Detect expired or expiring Ingress certificates before they take down a service.
  • Use TigerTrust’s internal CA as a drop-in cert-manager ClusterIssuer.
  • Automatically push renewed certificates into Kubernetes secrets without an operator step.

​
Set it up

1

Register the cluster

Go to Infrastructure > Kubernetes and click Add cluster. You can register with a kubeconfig (for out-of-cluster access) or by deploying a field agent inside the cluster. The in-cluster agent is recommended for production — no credentials leave the cluster.
2

Grant the required permissions

The agent or kubeconfig needs get, list, and watch on secrets, namespaces, and ingresses. Add create and update on secrets if you want to enable certificate writeback. A minimal ClusterRole manifest is shown in the setup wizard.
3

Run a discovery sync

Click Sync now to run an on-demand discovery pass against the cluster. TigerTrust lists all TLS secrets, parses the certificates, and imports them into your inventory tagged with the cluster and namespace as the source.
4

Enable cert-manager integration (optional)

If cert-manager is running in the cluster, TigerTrust detects it automatically. You can then point a cert-manager ClusterIssuer at TigerTrust’s ACME endpoint so cert-manager requests certificates from your internal CA the same way it requests them from Let’s Encrypt.
5

Enable secret writeback (optional)

On any certificate’s deployment settings, add a Kubernetes target and specify the namespace and secret name. When the certificate is renewed, TigerTrust pushes the new PEM bundle into the cluster secret automatically.

​
What you’ll see

Registered clusters appear on Infrastructure > Kubernetes with their API endpoint, detected cert-manager version (if present), and last sync timestamp. Discovered certificates appear in Certificates tagged with source: kubernetes and the cluster/namespace/secret path as the source identifier.
Secret writeback is opt-in per certificate. It requires either an in-cluster agent or a kubeconfig with create and update permissions on secrets in the target namespace — the read-only kubeconfig used for discovery is deliberately insufficient.

​
cert-manager ClusterIssuer example

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: tigertrust-internal
spec:
  acme:
    server: https://tigertrust.example.com/acme/directory
    email: ops@example.com
    privateKeySecretRef:
      name: tigertrust-acme-account
    solvers:
      - http01:
          ingress:
            class: nginx

Container scanning

Registry, Docker, and Kubernetes-secret discovery targets in one place.

ACME

TigerTrust’s ACME server — the endpoint cert-manager talks to.

Certificate deployment

Deployment policies that drive Kubernetes secret writeback.