Implement mTLS Authentication in Service Mesh - The Orchestrator

Implementation

In a service mesh, every service-to-service call must be authenticated. mTLS (mutual TLS) achieves this by requiring both the client and the server to present a certificate. If either certificate is invalid or untrusted, the connection is rejected — even inside the cluster.

Implement a node that handles mTLS certificate operations:

// Mutual TLS handshake between two services
{ "type": "handshake", "msg_id": 1,
  "client": "service-a", "server": "service-b" }
-> { "type": "handshake_complete", "in_reply_to": 1,
    "success": true, "cipher_suite": "TLS_AES_256_GCM_SHA384" }

// CA issues a certificate for a service
{ "type": "issue_certificate", "msg_id": 2,
  "service": "service-a" }
-> { "type": "certificate_issued", "in_reply_to": 2,
    "service": "service-a",
    "certificate": "-----BEGIN CERTIFICATE-----...",
    "expiry": "<iso-timestamp>" }

// Verify a SPIFFE identity
{ "type": "verify_identity", "msg_id": 3,
  "spiffe_id": "spiffe://example.com/ns-1/service-a",
  "trust_domain": "example.com" }
-> { "type": "identity_valid", "in_reply_to": 3,
    "valid": true, "service": "service-a", "namespace": "ns-1" }

// Reject an invalid certificate
{ "type": "handshake", "msg_id": 4,
  "client": "attacker", "cert": "invalid-cert" }
-> { "type": "handshake_failed", "in_reply_to": 4,
    "reason": "Invalid certificate", "success": false }

Sample Test Cases

Perform mTLS handshakeTimeout: 5000ms

Input

{
  "src": "sidecar-a",
  "dest": "sidecar-b",
  "body": {
    "type": "handshake",
    "msg_id": 1,
    "client": "service-a",
    "server": "service-b"
  }
}

Expected Output

{"type": "handshake_complete", "in_reply_to": 1, "success": true, "cipher_suite": "TLS_AES_256_GCM_SHA384"}

Issue certificate for serviceTimeout: 5000ms

Input

{
  "src": "service",
  "dest": "ca",
  "body": {
    "type": "issue_certificate",
    "msg_id": 1,
    "service": "service-a"
  }
}

Expected Output

{"type": "certificate_issued", "in_reply_to": 1, "service": "service-a", "certificate": "-----BEGIN CERTIFICATE-----...", "expiry": ".*"}

Hints

Hint 1▾

mTLS: both client and server present certificates — not just the server as in regular TLS

Hint 2▾

The CA issues a certificate for each service identified by a SPIFFE ID

Hint 3▾

SPIFFE format: spiffe://<trust-domain>/ns-<namespace>/<service-name>

Hint 4▾

A handshake fails if either party presents an invalid or untrusted certificate

Hint 5▾

Verify: check that the SPIFFE ID matches the expected service and trust domain

Implementation

Sample Test Cases

Hints

Resources

Theoretical Hub

Key Concepts