One of the most important aspects of service-oriented architectures (microservice architectures) is cross-service communication.
Such architectures may comprise of very different services— written in different programming languages, deployed in different regions, on different cloud providers, and on entirely different deployment models (think IaaS, PaaS, SaaS).
<aside> <img src="/icons/report_red.svg" alt="/icons/report_red.svg" width="40px" />
This is a condensed version of the original article, intended for people who are already familiar with cybersecurity concepts.
</aside>
Some standards have been developed to underpin communication between services. gRPC is a common choice, as it’s language-agnostic and can be implemented on many platforms. When services are talking to each other, they must authenticate each other.
We can think of this in two parts— when Service A makes a request to Service B:
Service A needs to confirm the authenticity of Service B (Upstream authentication)
So it can be sure it is sending request data to Service B, and not an impostor (i.e. a Man-in-the-Middle attack).
Service B needs to confirm the authenticity of Service A (Downstream authentication)
So it can be sure that a request is legitimate and coming from a trusted service. Allowing untrusted parties to make requests can create vulnerabilities such as a confused deputy problem.
<aside> 💡
Why are upstream and downstream this way around?
Authentication flows in the opposite direction to a request.
E.g. if Service A makes a request to Service B, we say that Service B authenticates itself to Service A (upstream).
HTTPS, which uses Transport Layer Security (TLS), is relevant when considering authentication flows. For upstream authentication, HTTPS allows Service A to verify Service B's identity through a chain of trust. Service B proves itself using an X.509 certificate signed by a certificate authority.
Browsers verify certificates against trusted authorities, but in microservices, we typically use our organization's Private Certificate Authority. Through certificate pinning, Service A will only trust certificates signed by our authority.
While HTTPS enables upstream authentication, it doesn't verify the sender's identity (downstream authentication). A common solution uses passwords or secrets (like Bearer tokens/JWTs), though these are vulnerable to replay attacks if compromised.
A more secure alternative is mTLS, where both parties must present certificates to establish a connection, enabling mutual authentication.
Going over the intricacies of establishing service and workload identity (and doing so in a robust way) would take a lot more than a single article. Nevertheless, it would be difficult to explain the rest of the article without going over some key ideas and concepts first.
Identity Attestation is something that serves as proof of its holder’s identity. Think of it as an ID card. In the context of cybersecurity, this is usually some digital document that is digitally signed by someone we trust.
Workload identity refers to the concept of being able to identify the underlying infrastructure on which code runs. For example, AWS EC2 provides an Instance Identity Document that is signed by Amazon.
SPIFFE is the ‘Secure Production Identity Framework for Everyone.’ It helps with verifying workload identity and issuing certificates that can attest for (i.e. verifiably prove) the identity of a service. Here, ‘identity’ confirms that the service we are talking to is running on infrastructure that we trust.