gen-istio-cert

The gen-istio-cert tool is used with TEG to obtain and rotate Istio workload certificates for gateway-to-mesh mTLS it runs as a sidecar container in the Envoy data plane Pod and continuously:

1. Authenticates to Istiod using a projected Kubernetes service account token.
2. Requests an Istio workload certificate for the target service account.
3. Stores the issued certificate and private key into a Kubernetes Secret.
4. Refreshes certificates periodically, coordinated by leader election when multiple replicas run.

This enables TEG to originate mTLS to Istio workloads without injecting an Istio sidecar into the gateway Pod.

Command reference

Flag	Type	Default	Description
--ca-address	string	istiod.istio-system.svc:15012	Istio CA gRPC endpoint used for CSR signing.
--trust-domain	string	cluster.local	SPIFFE trust domain used in generated identities (for example spiffe://cluster.local/ns/<ns>/sa/<sa>).
--cluster-name	string	Kubernetes	Value sent to Istiod as ClusterID metadata.
--sa-name	string	empty	Service account name used for certificate identity. If omitted, parsed from mounted Kubernetes token claims.
--sa-namespace	string	empty	Service account namespace used for certificate identity. If omitted, parsed from mounted Kubernetes token claims.
--output-secret	string	istio-certs	Name of Secret where cert/key are written.
--output-secret-ns	string	empty	Namespace where output Secret is created/updated. Defaults to service account namespace if omitted.
--leader-election-id	string	empty	Leader election lease name. Default is <sa-name>.gen-istio-cert.teg.tetrate.io.

Inputs and required mounts

The container expects the following mounted files in standard paths:

1. Kubernetes service account token:
   • Path used for service account auto-detection: /var/run/secrets/kubernetes.io/serviceaccount/token
2. Istiod root CA:
   • Path used for TLS verification: /var/run/secrets/istio/root-cert.pem

A typical projection/mount pattern is:

volumes:
  - name: istiod-ca-cert
    configMap:
      name: istio-ca-root-cert
  - name: istio-token
    projected:
      defaultMode: 420
      sources:
        - serviceAccountToken:
            audience: istio-ca
            expirationSeconds: 43200
            path: istio-token

containers:
  - name: gen-istio-cert
    image: docker.io/tetrate/gen-istio-cert:v0.3.0
    volumeMounts:
      - name: istiod-ca-cert
        mountPath: /var/run/secrets/istio
      - name: istio-token
        mountPath: /var/run/secrets/tokens
        readOnly: true

Required RBAC

At minimum, grant the sidecar service account permissions to:

• Read/create/update Secret in output namespace
• Create/update/watch/delete Lease for leader election
• Create Events (for leader election recorder)

Cluster-scoped example:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: teg-gen-certs-role
rules:
  - apiGroups: [""]
    resources: ["secrets", "events"]
    verbs: ["get", "list", "create", "update"]
  - apiGroups: ["coordination.k8s.io"]
    resources: ["leases"]
    verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: teg-gen-certs-rb
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: teg-gen-certs-role
subjects:
  - kind: ServiceAccount
    name: teg-istio
    namespace: envoy-gateway-system

For namespace-scoped gateway deployments, Role/RoleBinding can be used if all accessed resources are in the same namespace.