Security¶

Overview¶

Linkerd takes a security-first approach: automatic mTLS is enabled by default for all traffic between meshed pods, requiring zero configuration. The identity system uses a simple PKI chain anchored by a trust anchor certificate. Authorization policies use the Kubernetes-native Server and ServerAuthorization CRDs.

See also: index, architecture, operations

1. Automatic mTLS¶

Linkerd automatically enables mutually-authenticated TLS (mTLS) for all TCP traffic between meshed pods. This means every connection between meshed workloads is both encrypted and authenticated without application code changes or manual certificate management.

graph LR
    subgraph "Source Pod"
        AppA["Application"] --> PA["linkerd2-proxy"]
    end
    subgraph "Destination Pod"
        PB["linkerd2-proxy"] --> AppB["Application"]
    end
    PA <-->|mTLS<br/>encrypted & authenticated| PB
    PA -.->|certificate request| ID["identity controller"]
    PB -.->|certificate request| ID

Key characteristics:

On by default -- no configuration needed to enable mTLS
Zero application changes -- encryption and authentication happen at the proxy layer
Protocol agnostic -- works for HTTP, HTTP/2, gRPC, and raw TCP
Control plane also secured -- Linkerd's own control plane components communicate via mTLS

2. Trust Anchor PKI¶

Linkerd uses a simple two-tier PKI (Public Key Infrastructure):

Trust Anchor (root certificate, long-lived)
  └── Issuer Certificate (intermediate, managed by identity controller)
        └── Workload Certificate (per-Service Account, short-lived)

Trust Anchor¶

The trust anchor is the root of trust for the entire mesh:

Generated during linkerd install or provided manually
Typically uses ECDSA (P-256) for small key size and fast verification
Common name format: root.linkerd.cluster.local
Distributed to all proxies as a read-only ConfigMap (linkerd-identity-trust-roots)
Should be stored securely and rotated infrequently

Issuer Certificate¶

The issuer certificate is signed by the trust anchor and used by the identity controller to sign workload certificates:

Stored as a Kubernetes Secret in the linkerd namespace
Can be managed by cert-manager for automatic rotation
Rotating the issuer does not require restarting proxies

Provisioning with cert-manager¶

For production deployments, cert-manager can manage the trust anchor and issuer lifecycle:

apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: linkerd-trust-anchor
  namespace: cert-manager
spec:
  issuerRef:
    kind: Issuer
    name: linkerd-trust-root-issuer
  secretName: linkerd-trust-anchor
  isCA: true
  commonName: root.linkerd.cluster.local
  duration: 8760h    # 1 year
  renewBefore: 7320h  # renew 60 days before expiry
  privateKey:
    rotationPolicy: Always
    algorithm: ECDSA

The trust-manager Bundle resource distributes trust anchors to all namespaces:

apiVersion: trust.cert-manager.io/v1alpha1
kind: Bundle
metadata:
  name: linkerd-identity-trust-roots
  namespace: linkerd
spec:
  sources:
  - secret:
      name: "linkerd-trust-anchor"
      key: "tls.crt"
  target:
    configMap:
      key: "ca-bundle.crt"
    namespaceSelector:
      matchLabels:
        linkerd.io/is-control-plane: "true"

3. Identity Controller¶

The identity controller is Linkerd's built-in certificate authority:

Issues TLS certificates to linkerd2-proxy instances on startup
Identity is derived from the pod's Kubernetes Service Account
Identity format: <service-account>.<namespace>.serviceaccount.identity.linkerd.cluster.local
Validates CSR (Certificate Signing Request) against the Kubernetes API
Short-lived certificates (default 24 hours) with automatic rotation
Runs as part of the linkerd-control-plane deployment

4. Certificate Rotation¶

Linkerd handles certificate rotation at multiple levels:

Certificate	Lifetime	Rotation Mechanism
Trust anchor	1+ years	Manual or cert-manager
Issuer certificate	Configurable	cert-manager or manual
Workload certificate	24 hours (default)	Automatic via identity controller

Workload certificate rotation is transparent to the application. The proxy requests a new certificate from the identity controller before the current one expires, with no connection interruption.

5. Server and ServerAuthorization¶

Linkerd uses two CRDs for fine-grained authorization:

Server¶

The Server resource defines which traffic a policy applies to, selecting pods by label and specifying the port and protocol:

apiVersion: policy.linkerd.io/v1beta1
kind: Server
metadata:
  name: backend-server
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: backend
  port: 8080
  proxyProtocol: HTTP/2

ServerAuthorization¶

The ServerAuthorization resource specifies which clients are allowed to connect to a Server:

apiVersion: policy.linkerd.io/v1beta1
kind: ServerAuthorization
metadata:
  name: backend-authz
  namespace: production
spec:
  server:
    name: backend-server
  client:
    meshTLS:
      identities:
      - "frontend.production.serviceaccount.identity.linkerd.cluster.local"
    unauthenticated: false

Authorization features:

Identity-based access control -- restrict access to specific Service Account identities
Namespace-based access control -- allow traffic from specific namespaces
Network-based access control -- allow traffic from specific CIDR ranges
Protocol-aware -- HTTP method and path matching for L7 policies

6. Tap RBAC¶

Linkerd's tap feature allows real-time inspection of traffic flowing through the mesh. Access to tap data is controlled by Kubernetes RBAC:

The linkerd-tap role controls who can tap traffic
Tap can be scoped to specific namespaces, deployments, or pods
Sensitive data (headers, body) is not exposed by default
Requires explicit RBAC binding to use

Tap Access

Grant tap permissions carefully. While tap does not expose payload data by default, it reveals request metadata including URIs, headers, and response codes that may contain sensitive information.

7. Security Comparison with Istio¶

Aspect	Linkerd	Istio
mTLS default	On by default	PERMISSIVE by default (requires PeerAuthentication STRICT)
Identity format	Service Account based (custom format)	SPIFFE format
Authorization CRD	Server + ServerAuthorization	AuthorizationPolicy
JWT validation	Not built-in (use external)	RequestAuthentication (native)
Certificate management	Built-in or cert-manager	Built-in Citadel or external CA
Ambient / sidecar-less	Not available	ztunnel + waypoint

Key Insight

Linkerd's security philosophy is "secure by default." mTLS is automatically enabled for all meshed traffic, the PKI is simple (trust anchor + issuer + workload), and authorization uses Kubernetes-native CRDs. This trades Istio's richer security features (native JWT, SPIFFE standard, ambient mode) for a dramatically simpler operational model where the default configuration is already production-ready.