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
Trust by proximity works nicely until the network boundary stops being a meaningful security boundary.
@fatima_sarki Same here. Saw a team rely on private VPC trust for years until an audit forced zero trust down their throats.
@faysal_fateh that's great
@faysal_fateh audit forcing the conversation is such a common pattern. nobody prioritises it until something external makes them. the good news is the pressure usually leads to the right outcome eventually.
@fatima_sarki exactly, the boundary used to mean something. now with cloud, containers, and distributed systems it's more of a suggestion than a wall.
@riya_pariyar This is such an overlooked part of security l Trusting the network by default can get risky fast . But still I am curious about that how other teams are handling service to service auth.
@lucas_cook2 most teams are handling it one of three ways: mutual TLS between services, short-lived tokens issued per service identity, or SPIFFE workload identity if they're on Kubernetes. the honest answer though is a lot of teams aren't handling it yet and just haven't hit the moment that forces it.
at MonoCloud we actually support all three of these, M2M tokens, mTLS client auth, and SPIFFE workload identity, so if you're trying to figure out where to start it's worth checking out:)
The same VPC = trusted assumption is definitely one of those things that survives longer than it should.
@joseph_collins2 it survives because nothing visibly breaks. which is exactly what makes it dangerous. you only find out it was wrong after something goes wrong.
@riya_pariyar Thats the scary part security debt can stay invisible for years because the architecture keeps working. By the time its tested, the cost is much higher.
We authenticate users carefully then sometimes let internal services trust each other blindly. that gap is easy to overlook.
@chandrshekhar_rawen that gap is the most common one i see. the front door is locked tight and the internal rooms are wide open. the two security postures are completely inconsistent.
@riya_pariyar That front door vs internal rooms analogy is spot on. once one service is compromised those open internal paths can turn a small breach into a much bigger one.
Personally I would start with the highest privilege service calls first. Not every internal request needs the same access. .Short lived credentials and clear service scopes could make this easier to manage.
@alheri_murya starting with the highest privilege calls is exactly the right prioritisation. you don't have to boil the ocean. just make sure the most sensitive service-to-service calls have real identity first.
I would be curious how much of this changes for small teams. zero trust sounds right but implementation overhead can be real.
@uttam_kumar35 for small teams the overhead is real but it's lower than it used to be. tools like SPIFFE or managed identity in cloud providers handle a lot of the heavy lifting now. you don't have to build it from scratch.
The hardest part probably isnt adding auth its doing it without breaking all the existing internal communication.
@thomas_jack3 that's the hardest part honestly. retrofitting auth into existing service calls without breaking everything is what keeps teams from starting. the trick is usually to do it service by service rather than all at once.
I think the tricky part is proving service identity without turning every internal request into a security project.
@adams_parker that's the design challenge. the goal is to make service identity as automatic as possible so proving who you are doesn't require a security project every time. short-lived credentials that rotate automatically get you most of the way there without the overhead.
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.
@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.