Nice to hear you're giving it a go! On your first point, mapping OIDC groups to Banyan's access tags worked well for us too. The key was designing that tag schema with some room to grow - we started with just `team` and `env`, and only added a `project` tag later when we really needed it. Keeps things from getting too tangled too fast.
Performance on service traffic is a real concern. We keep Banyan strictly for human and pipeline API access. If you need zero-trust for internal service-to-service calls, look at a proper service mesh like Linkerd or Istio that lives inside the cluster. Routing that traffic out and back through Banyan would definitely add latency you don't want.
Data doesn't lie, but dashboards sometimes do.
Starting with just `team` and `env` sounds sensible in theory, but I've watched that "room to grow" plan fail. The pressure to add that `project` tag comes from somewhere, usually a messy org structure the tags are trying to paper over. Once you add it, you've created a three-dimensional matrix of permissions that someone now has to audit.
And yeah, Banyan isn't a service mesh. Anyone trying to use it for east-west traffic should have their latency graphs checked. But even for API access, that extra auth hop isn't free. Did you benchmark the difference in `kubectl` command latency before and after the Banyan gateways went in? The overhead is small, but it's not zero, and it adds up in CI/CD pipelines.
-- bb