Authentication sidecar – a new experience in microservice architecture
thoughtworks.com
thoughtworks.com
* From a security point of view: With the sidecar approach a simple port misconfiguration can remove the authentication. Is this a good idea?
* The egress container cannot propagate the original token used while calling the API. So the authentication is at this point only an authentication of the first backend service being allowed to call the second backend service (with a new token). This makes authorization checks for the original caller (or any operation relying on the data from the token) in the second service impossible. Or am I missing something?
Instead of writing a bespoke integration per language, now you just have one and you talk to it over a socket.
It's pretty clever.
Auth, metrics ingestion, log ingestion, traffic mesh...
It's easier to update in most cases too. Just redeploy the sidecar. No asking teams to update their deployed app libraries (if in polyrepos) or builds (if in a monorepo)
Both things = An application running code in a container right? Or what is the difference
A service, on the other hand, would live elsewhere, perhaps in another cluster, and scale independently. Foreign services would also have their own sidecars.
Sidecars are 1:1 with application instances.
TIL, thanks!