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.