Linkerd
by CNCF / Buoyant
Lightweight, security-focused service mesh for Kubernetes with automatic mTLS and minimal configuration
Authoritative Sources
Key guidance documents from authoritative organizations. Click to view the original source.
NIST SP 800-204 §2.7: "A service mesh is a dedicated infrastructure layer that facilitates service-to-service communication... It provides the capability to declaratively define network behavior, node identity, and traffic flow through policy in an environment of changing network topology." MS-SS-4: "Client to API gateway as well as Service to Service communication should take place after mutual authentication and be encrypted (e.g., using mutual TLS (mTLS) protocol)." MS-SS-3: "Communication between an application service and a service registry should occur through a secure communication protocol such as HTTPS or Transport Layer Security (TLS)."
Configuration Examples(1)
SM-DR1: "All service-to-service communications should be authenticated." SM-DR6: "The application service and its associated proxy should only communicate through a loopback channel." SM-DR8: "All traffic should be denied by default and explicitly allowed (allowlisting)." Linkerd implements these via automatic mTLS and Server/ServerAuthorization policies.
Configuration Examples(3)
NIST SP 800-204B §1.1: "A service mesh provides a framework for building a set of operational assurances for an application through its various features... an authenticatable runtime identity for services, the ability to authenticate credentials of individual users of a service, encryption of communication in transit between services." §5.2.1: "The trusted document that carries the identity of the service is an X.509 certificate issued by one of the control plane components of the service mesh after verifying whether the requested identity is valid." SAUN-SR-2: "The service mesh should provide a secure naming service that maps the server identity to the microservice name."
Configuration Examples(3)
Official security guide covering automatic mTLS, identity, policy enforcement, and secure proxy configuration.
Configuration Examples(6)
SOC 2 CC6.7: "The entity restricts the transmission, movement, and removal of information to authorized internal and external users and processes, and protects it during transmission." Linkerd implements automatic mTLS encryption for all service-to-service communication with its lightweight Rust-based proxies, directly supporting CC6.7 requirements for protecting data in transit. Source: AICPA Trust Services Criteria.
ISO 27001:2022 A.8.24: "Rules for the effective use of cryptography, including cryptographic key management, shall be defined and implemented." Linkerd provides automatic certificate management and rotation through its identity component with short-lived certificates (24-hour default), implementing cryptographic controls that secure service communications as required by A.8.24. Source: ISO/IEC 27001:2022 Annex A.
CCM IAM-02: "Identify and authenticate all users with a unique ID and manage authentication credentials in accordance with policies." CCM IAM-14: "Access credentials for service accounts shall be short-lived and frequently rotated." Linkerd implements workload identity through SPIFFE-compliant certificates with automatic 24-hour rotation, directly supporting CCM IAM controls for service authentication and credential lifecycle management. Source: CSA Cloud Controls Matrix v4.0.
Verification Commands
Commands and queries for testing and verifying security configurations.
linkerd check linkerd viz edges deployment -n {namespace} linkerd diagnostics proxy-metrics -n {namespace} {pod-name} kubectl get serverauthorizations -A linkerd viz stat deploy -n {namespace} linkerd identity -n {namespace} {pod-name} kubectl get servers,serverauthorizations -n {namespace} linkerd diagnostics endpoints {service}.{namespace}.svc.cluster.local:port Related Controls
Security controls from various frameworks that relate to Linkerd.