Service to Service

The billing service accepts a request on port 8080 and processes it, because anything that can reach that port is by definition a trusted internal caller. That was a defensible assumption when internal meant a rack you could point at. It is not one now, and it collapses entirely the moment a single other workload on that network is compromised — at which point the attacker inherits the billing service's full trust without having to authenticate as anything.

The fix is to make services prove who they are to each other, and the mechanism is already familiar: mutual TLS is the handshake from P53 with a certificate on both ends. The client verifies the server, as your browser does, and the server verifies the client, so the identity of the caller is established cryptographically rather than inferred from an address. What changes is not the protocol but the question you can now ask — instead of "did this arrive on the internal network", the billing service can ask "is this the orders service", and authorize accordingly.

That leaves the problem that decides whether any of this survives contact with production: where a workload's certificate comes from. Handing each service a long-lived certificate and a private key at deploy time reproduces every problem of long-lived credentials — they leak, they get copied, they outlive the service. Workload identity issues a credential to a workload based on what it is and where it runs, with a short lifetime and automatic rotation, so a leaked certificate expires on its own and a compromised host does not yield a permanent key. You will look at how rotation happens without dropping connections, because a rotation scheme that causes an outage is a rotation scheme that gets disabled.