Are your backend services authenticated or just trusted by default?
most teams spend a lot of time thinking about user authentication. who can log in, how, with what credentials.
and then the services behind the scenes just... trust each other. because they're on the same network. because they're in the same VPC. because nobody questioned it when the architecture was first drawn up.
internal trust is one of those things that feels safe until it isn't. if any service in that network gets compromised, it can talk to every other service with the same implicit trust. there's no credential to steal because there was no credential to begin with.
the shift to zero trust changes this. every service call needs to prove who it is, not just where it's coming from. network location stops being a proxy for identity.
but most teams haven't made that shift. not because they don't care, but because retrofitting authentication into service-to-service calls is unglamorous work that competes with features on the roadmap.
curious how teams are actually handling this.
are your internal services authenticated or is it still mostly trust by proximity?
and if you've solved it, what finally pushed you to do it?
Replies
I would also look at credential rotation before introducing authentication everywhere. Long lived service credentials creats another problem if they leak. Automated rotation and narrowly scoped permissions could make the whole model safer.
MonoCloud for Startups
@bastienrenard 100% agree. long-lived credentials are basically a ticking clock. you don't know they've leaked until something breaks. automated rotation paired with narrow scopes is the right default, not the nice-to-have.
The problem i noticed with trusting by proximity is when you actually consider making any change. Right now aws VPC setup means we can't move any workload outside on any dedicated servers (much cheaper). The team would need to implement different ways to authenticate, and nobody has time for that.
I personally prefer using auth tokens where needed..or a shared resource, like a redis db or a messaging queue.
trust by proximity, and the thing that finally broke it for us wasnt a breach, it was putting an agent inside the network. the agent authenticates perfectly well. its a legitimate service with a legitimate identity, and that is exactly the problem, because service identity answers who is calling and the agent is genuinely who it says it is while being talked into a call nobody intended. so we ended up needing authorization per action rather than per caller. it gets an allowlist of specific operations and everything outside that is denied by default, which is a completely separate question from whether it authenticated. zero trust as usually described still assumes the caller is deterministic. mine isnt.