Learn PKI - Zero Trust & Service Identity

#Introduction

In previous episodes you built a private CA, automated certificates in Kubernetes, and tried various PKI toolkits from OpenSSL to CFSSL. So far we have treated certificates as a complement: installed on a service, then forgotten until the validity period nearly ends. In episode 15 we flip that perspective.

In Zero Trust architecture, certificates are no longer a complement. They are the foundation of digital identity. The principle is simple: never trust something just because it is inside the internal network. Every request must be verified, and every service must prove who it is before being given access.

This episode's roadmap: we start from the Zero Trust paradigm and the role of mTLS, then distinguish workload identity from machine identity, see how service mesh such as Linkerd, Istio, and Cilium leverage mTLS, and close with SSH PKI using the step-ca you met in episode 9.

#Zero Trust and the Role of mTLS

Zero Trust was born from the failure of the old perimeter model. Once it was enough to be safe behind a firewall; now cloud servers are scattered, employees work from anywhere, and data moves across regions. The old model destroys security as soon as one layer is breached, because internal traffic was assumed clean.

The Zero Trust principle often cited: never trust, always verify. No zone is automatically trusted. Every connection verifies its identity, authorization, and device health. This is where mTLS works as the verification mechanism between services.

#mTLS as the Foundation

mTLS, or mutual TLS, is ordinary TLS with one big difference: two directions. The server proves its identity through its certificate, and the client is also required to present its certificate. The handshake does not finish until both parties validate each other. You already built this flow manually in episode 7, and now we see its application at scale.

With mTLS, access decisions can be made faster: was the certificate issued by a CA we trust, is it still valid, and does the identity written on it match the name of the target service? Certificates become an identity card checked every time two services communicate.

#Workload Identity vs Machine Identity

Two terms that are often confused: machine identity and workload identity. Machine identity is attached to a physical or virtual device, such as a server or container host. It is represented by a machine certificate with a long lifetime and is generally installed once. Workload identity is attached to a specific process or service running inside that machine.

This distinction matters because in the container world, many services share one machine. If identity is only attached to the machine, all services on that machine cannot be distinguished. Workload identity gives each service a unique identity, so one pod can be rotated, deleted, or moved without changing the identity of other services.

Certificates for workloads are usually short-lived, from a few hours to a few days. This limits the attack window: if a certificate leaks, it is no longer useful after expiry. Machine identity remains relevant for things like SSH into machines, but workload identity has become the standard for service-to-service communication.

#Service Mesh: Automated mTLS

Applying mTLS manually to hundreds of services is a huge job. Service mesh answers it by placing a sidecar proxy next to each pod. The sidecar handles TLS, so applications stay plain and never need to know about certificates. The three implementations most often discussed: Linkerd, Istio, and Cilium.

#Linkerd

Linkerd is the lightest service mesh. It uses a certificate for each pod and performs automatic mTLS between sidecars. When one service calls another, the connection passes through two sidecars that verify each other's certificates. Linkerd can leverage an external CA such as step-ca as its identity provider.

#Istio

Istio is larger and feature-rich. It also enables mTLS between services, but adds an authorization layer called AuthorizationPolicy. The combination of mTLS and AuthorizationPolicy enables rules such as: only services in the payment namespace may call a certain endpoint. mTLS answers the who question, while policy answers what they may do.

#Cilium and SPIRE

Cilium with CiliumNetworkPolicy can enable mTLS and identity-based policy at the kernel level via eBPF. For workload identity, Cilium is often paired with SPIRE. SPIRE is the SPIFFE implementation that gives each workload a unique identity in the form of a SPIFFE ID, and issues SVIDs as certificates with a limited lifetime.

#Per-Pod Certificates with SPIFFE

SPIFFE is the standard for workload identity. Every workload gets a SPIFFE ID, for example in the format spiffe://example.org/workload/billing. SPIRE, as its implementation, verifies pod conditions through various attestors, then issues an SVID that is a short-lived X.509 certificate.

SPIFFE's main advantage lies in consistency. No matter how many service mesh implementations exist, as long as they all understand SPIFFE, identities between workloads can be verified against each other without manual conversion. This is why Cilium, Istio, and Linkerd all support or can be connected to SPIFFE.

apiVersion: spire.spiffe.io/v1alpha1
kind: ClusterSPIFFEID
metadata:
  name: billing-workload
spec:
  spiffeIDTemplate: spiffe://example.org/workload/billing
  podSelector:
    matchLabels:
      app: billing

The example resource above asks SPIRE to give a SPIFFE ID to all pods labeled app: billing. SPIRE handles certificate creation, distribution to pods, and automatic renewal before expiry. Applications just read the SVID from the provided trust domain.

#SSH PKI with step-ca

Zero Trust does not stop at HTTP traffic. Administrative access such as SSH also needs well-managed identity. Most teams still use static keys: one public key copied to authorized_keys, used for years, and control is lost when an employee leaves. SSH PKI replaces this model entirely.

With SSH PKI, the CA signs a certificate for every host and every user. Servers no longer store a list of public keys. They just trust one CA public key. Client certificates are given a short validity period, and when they expire the user must request a new one through an automated flow.

#Host and User Certificates

step-ca from episode 9 supports SSH natively. You just initialize the CA with the SSH option, and step-ca will create key pairs for the host CA and user CA.

step ca init \
  --name "Homelab Internal CA" \
  --ssh \
  --dns ca.internal \
  --address ":443"

After that, host and user certificates can be issued with almost the same commands.

step ssh certificate host server01.internal \
  host/server01.internal-ssh.pub \
  host/server01.internal-ssh.crt

step ssh certificate user arman \
  user/arman-ssh.pub \
  user/arman-ssh.crt

The step ssh certificate host command signs a certificate for a machine, while step ssh certificate user signs one for a human. Each certificate carries a validity period, principals, and other constraints written by the CA.

#Short-Lived Certificates for Host and User

The biggest benefit of SSH PKI is the short certificate duration. Compare: a static key is valid indefinitely until someone manually revokes it. An SSH certificate can be made valid for only 12 hours, so a certificate leaked in the afternoon is already useless the next morning.

step-ca even provides a command to renew certificates. Users just log in again, and renewal automation can be installed on the client side.

step ssh renew user/arman-ssh.crt \
  --expires-in 24h

step ssh renew extends the certificate's validity while it still has valid credentials. On the server, the TrustedUserCAKeys option tells sshd which CA is considered trusted, so hosts do not need to manage a manual key list.

#Closing

Episode 15 takes you from the old paradigm to the Zero Trust mindset. You understood the role of mTLS as the foundation of two-way verification, distinguished workload identity from machine identity, saw how Linkerd, Istio, and Cilium leverage mTLS and SPIFFE for per-pod identity, and closed with SSH PKI replacing static keys with short-lived certificates.

Key takeaways:

• Zero Trust places certificates as the foundation of identity, not a complement.
• mTLS verifies in both directions and becomes the backbone of service-to-service communication.
• Workload identity is attached to a service and short-lived, unlike machine identity.
• Service mesh such as Linkerd, Istio, and Cilium automates mTLS without changing applications.
• SPIFFE and SPIRE provide consistent per-pod identity across platforms.
• SSH PKI with step-ca replaces static keys with short-lived, easily rotated certificates.

In episode 16 we enter the governance realm. You will learn security best practices and compliance: how to design an offline root CA, manage an online intermediate, perform key rotation, and understand audit frameworks such as PCI DSS, SOC 2, NIST, and FIPS 140-3. See you there!