mTLS i Kubernetes: service mesh, cert-manager og SPIFFE

Q: Hvad er en SPIFFE ID?

En standardiseret workload-identitet på formen spiffe://trust-domain/path, indlejret i certifikatets SAN som en URI. Den binder identiteten til workloaden frem for til en IP eller et podnavn der skifter.

I et Kubernetes-cluster taler dusinvis af services med hinanden over netværket — som standard i klartekst, uden at nogen beviser hvem de er. mTLS retter begge dele på én gang. Her er de tre veje til mTLS i Kubernetes: service mesh, cert-manager og den identitetsmodel, SPIFFE, der binder det hele sammen.

Kort svar

Den nemmeste vej til mTLS i Kubernetes er et service mesh (Istio eller Linkerd), der automatisk injicerer en sidecar-proxy ved siden af hver pod og krypterer + autentificerer al pod-til-pod-trafik uden at du ændrer din applikationskode. Vil du have mTLS uden et mesh, udsteder du certifikater med cert-manager og monterer dem i dine pods. Begge bygger på en identitetsmodel — ofte SPIFFE — der giver hver workload en kryptografisk verificerbar identitet.

Mulighed 1: Service mesh (automatisk mTLS)

Et service mesh placerer en sidecar-proxy (Envoy i Istio, en letvægts-proxy i Linkerd) i hver pod. Al udgående og indgående trafik går gennem proxyen, som etablerer mTLS med modpartens proxy. Applikationen ser kun almindelig HTTP på localhost — proxyen håndterer certifikater, rotation og verifikation.

I Istio aktiverer du obligatorisk mTLS for et namespace med en PeerAuthentication-politik:

apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata:
  name: default
  namespace: payments
spec:
  mtls:
    mode: STRICT   # afvis al ikke-mTLS-trafik i namespacet

STRICT betyder at en pod uden sidecar — eller en angriber på netværket — ikke kan tale med servicerne. PERMISSIVE tillader både mTLS og klartekst under en migrering.

Det stærke ved et mesh er, at certifikaterne er kortlivede (ofte 24 timer) og roteres automatisk. Bagsiden er, at de er usynlige for dine sædvanlige overvågningsværktøjer — de ligger i proxyens hukommelse, ikke i en fil du kan inspicere.

Mulighed 2: cert-manager (eksplicitte certifikater)

Vil du have mTLS uden et fuldt mesh — fx kun mellem to bestemte services — udsteder cert-manager certifikater fra en Issuer og lægger dem i et Kubernetes-secret, som din pod monterer:

apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: service-a-client
  namespace: payments
spec:
  secretName: service-a-client-tls
  duration: 2160h        # 90 dage
  renewBefore: 360h      # forny 15 dage foer udloeb
  commonName: service-a.payments.svc
  usages:
    - client auth        # clientAuth EKU til mTLS-klientrollen
    - digital signature
  issuerRef:
    name: internal-ca
    kind: ClusterIssuer

Bemærk usages: client auth — det sætter den clientAuth EKU, mTLS kræver. cert-manager fornyer automatisk inden udløb, men hvis en Issuer fejler, eller et secret ikke genmonteres, kan et certifikat stadig nå at udløbe.

Mulighed 3: SPIFFE/SPIRE (identitet, ikke kun nøgler)

SPIFFE (Secure Production Identity Framework For Everyone) definerer en standardidentitet for workloads: en SPIFFE ID som spiffe://example.org/ns/payments/sa/service-a, indlejret i certifikatets SAN som en URI. SPIRE er implementeringen, der udsteder disse kortlivede SVID-certifikater til hver workload baseret på dens attesterede identitet (fx hvilken Kubernetes service account den kører som).

Pointen er, at identiteten ikke er en IP eller et podnavn, der ændrer sig — den er kryptografisk bundet til workloaden. Istio bruger SPIFFE-ID'er internt, så de to modeller hænger ofte sammen.

Verificér at mTLS faktisk er aktivt

At have konfigureret mTLS er ikke det samme som at det virker. Tjek fra inde i en pod, hvilket certifikat sidecar'en præsenterer:

# Inspicer det cert Istios sidecar bruger
istioctl proxy-config secret deploy/service-a -n payments

# Eller test direkte mod en service via dens sidecar-port
kubectl exec -it deploy/service-b -n payments -c istio-proxy -- \
  openssl s_client -connect service-a:8080 -showcerts

Ser du et SPIFFE-URI i SAN og en kort gyldighedsperiode, kører mTLS som forventet.

Den blinde vinkel: certifikater uden for meshet

Et mesh håndterer mTLS pænt inde i clusteret. Men de fleste organisationer har også ingress-certifikater, certifikater på databaser uden for clusteret, interne CA'er med lange levetider og legacy-services, der ikke er i meshet. De falder uden for meshets automatik — og det er præcis dér udløb rammer uventet. CertControl opdager og overvåger certifikater på tværs af hele jeres miljø, ikke kun inde i ét cluster, sporer udløb og validerer kæder, og advarer før et certifikat — i eller uden for Kubernetes — får en service til at fejle. Start med vores mTLS-guide.

Ofte stillede spørgsmål

Skal jeg bruge et service mesh for at få mTLS i Kubernetes?

Nej, men det er den nemmeste vej hvis du vil have mTLS overalt automatisk. Til mTLS mellem få bestemte services kan cert-manager + monterede certifikater være enklere og lettere at gennemskue.

Hvad er forskellen på Istio og Linkerd til mTLS?

Begge giver automatisk mTLS via sidecars. Istio er mere funktionsrigt (Envoy-baseret, mange politikker), Linkerd er lettere og enklere. Til ren mTLS uden avancerede trafikregler er Linkerd ofte tilstrækkeligt.

Hvad er en SPIFFE ID?

En standardiseret workload-identitet på formen spiffe://trust-domain/path, indlejret i certifikatets SAN som en URI. Den binder identiteten til workloaden frem for til en IP eller et podnavn der skifter.

Roterer service mesh-certifikater automatisk?

Ja. Både Istio og Linkerd udsteder kortlivede certifikater (typisk 24 timer) og roterer dem løbende uden manuel indgriben. Det er en stor del af deres værdi.

Hvorfor kan mine sædvanlige scannere ikke se mesh-certifikaterne?

Fordi de lever i proxyens hukommelse og kun præsenteres på interne pod-til-pod-forbindelser, ikke på en offentlig port. Til overblik over dem bruger du mesh-værktøjer som istioctl — men ingress- og eksterne certifikater bør stadig overvåges udefra.

Se platformen Book demo