mTLS and propagating identity

An encrypted channel proves the server to the client, but it does not tell the server who called; making both sides present certificates gives each a verified workload identity, and that original caller's identity must ride every hop — because no hop shares memory with the one that started the call.

Previously

We can now move bytes fast, fairly, and resiliently — but we've never asked who is on the other end of the wire; and because no hop shares memory with the one before it, each hop must carry both a proof of who it is AND the original caller's identity forward, exactly the way it carried the deadline.

Scene 11

mTLS and propagating identity

Watch
Try it
Predict
Capture

padlock = the channel is encrypted

badge = a per-call token (separate thing)

← workload identity: a verified name, both sides

What to watch for

First, separate two ideas people constantly conflate. Encrypting the wire — what HTTPS does — scrambles the bytes so an eavesdropper can't read them, and it proves the SERVER is who it claims (your browser checks the server's certificate). That's the padlock. A per-call token is a different thing entirely: a credential placed in the call's metadata that says 'this specific call is allowed.' That's the badge. The diagram draws them as two distinct objects on purpose. Now the gap: under plain TLS the badge and padlock prove the server to the client, but the server has no proof of who the CLIENT is — it sees only an IP address. When we make both sides present a certificate, each peer gets a cryptographically verified name we'll call its workload identity — a stable proof like prod/frontend of which service this is, not just where it's connecting from. Watch the slider move from TLS to that mutual-cert mode.

One call drawn as two SEPARATE things — a padlock (the channel is encrypted) and a badge (a per-call token in the metadata) — followed by a 3-hop A→B→C chain.
Under plain TLS the server can only see the caller's IP; with mutual certificates both peers display a cryptographically verified workload identity; with identity propagation on, the original caller's identity is forwarded down the chain so the leaf can decide based on who STARTED the call, not just its immediate caller.

Implementation

Highlighted lines are the ones running in the diagram right now.

Channel.establish

the TLS handshake — and whether the client also proves itself

1def establish(server_addr):
2    conn = tls_handshake(server_addr)
3    # server's cert always verified by the client
4    conn.server_id = verify_cert(conn.server_cert)
5    if mutual_tls:
6        # client ALSO presents a cert: both sides named
7        present_cert(conn, self.cert)  # e.g. SPIFFE/SVID
8        conn.client_id = self.workload_identity
9    else:
10        conn.client_id = None  # caller is just a peer IP
11    return conn

Client.call

what rides in the call's metadata: a token, and the origin

1def call(conn, method, req, ctx):
2    md = {}
3    md['authorization'] = mint_token()  # per-call badge
4    if propagate_identity:
5        # carry who STARTED the call, like grpc-timeout does
6        md['origin-principal'] = ctx.origin or self.id
7    # HTTP/2 HEADERS frame carries the metadata
8    return conn.invoke(method, req, metadata=md)

Server.authorize

the leaf decides on who called — origin or just the last hop

1def authorize(conn, md, action):
2    caller = conn.client_id  # verified by mTLS
3    origin = md.get('origin-principal')
4    if origin is not None:
5        # authorize on who STARTED the call
6        return policy.allow(origin, action)
7    # no origin forwarded: fall back to immediate caller
8    return policy.allow(caller, action)

Where this sits in Build a gRPC-style RPC framework

Scene 11 of 14, in the Secure & ship act — mTLS identity, then configure the whole stack.. TLS encrypts and proves the server; mTLS proves both peers with a workload identity. The original caller's identity must propagate across hops, just like a deadline.

Up next. Codec, transport, deadlines, retries, balancing, security — every layer was a forced choice with a trade-off; the last move is to put them all on one canvas and pick a coherent posture for a real workload, defending each choice with the scene that taught it.

All 14 scenes in Build a gRPC-style RPC framework · Every curriculum

Built with Arqly

Every scene in Build a gRPC-style RPC framework builds on the one before it.All 14 Build a gRPC-style RPC framework scenes