<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>
Service-oriented architectures are systems which are made up of different services or components. These can be written in written in different programming languages, deployed in different regions, on different cloud providers, and on entirely different deployment models (think IaaS, PaaS, SaaS).
These services need a way of talking to each other and doing so securely— this can quickly unfold and become a very complicated challenge.
Some standards have been developed around cross-service communication. 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.
Within this article, we’ll think about 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).
When talking about authentication over the internet, we often mention HTTPS, which uses Transport Layer Security (TLS). For upstream authentication, HTTPS allows Service A to verify Service B's identity through a chain of trust. Service B proves itself using a certificate which is cryptographically signed by a certificate authority. We call these X.509 certificates.
When a typical browser is using HTTPS, it checks the certificate with a pre-defined list of trusted signing authorities. Microservices, however, tend to use the organisation’s Private Certificate Authority. This is certificate pinning— it’s like saying “you should only trust services that have a certificate signed by this specific certificate authority.”
While HTTPS enables upstream authentication, it doesn't verify the sender's identity (downstream authentication). The simplest way to solve this is through requiring some credential— like a username and password (or perhaps, a Bearer token). However, 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 trust— that’s where the m in mTLS comes from.
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.