I would be surprised if you cannot.
This answer needs some terminology, to avoid getting lost in word-soup.
- App-A is a consumer of an in-cluster
Service
, and the one which will be authenticating to Ambassador
- App-Z is the provider of an in-cluster
Service
(the selector would target its Pod
s)
- The k8s
Service
for app-Z we'll call z-service
in the z
namespace, for a FQDN of z-service.z.svc.cluster.local
It seems like you can use its v-host support and teach it to honor the in-cluster virtual host (the aforementioned FQDN), then update the z-service
selector to target the Ambassador Pods rather than the underlying app-Z Pods.
From app-A's point of view, the only thing that would change is that it now must provide authentication for contacting z-service.z.svc.cluster.local
.
Without studying Ambassador's setup more, it's hard to know if Ambassador would Just Work™ at that point, or whether you would then need a "implementation" Service
-- such as z-for-real.z.svc.cluster.local
-- so that Ambassador knows how to find the actual app-Z Pods.