Hi everyone. First post here, so go easy on me 😅. I've been tasked with helping my team evaluate Zero Trust solutions, and Banyan Security keeps coming up. We're a pretty heavy Kubernetes shop—most of our apps and services live there, and we're using a service mesh internally.
I've been going through the Banyan docs and trying the setup, but I'm hitting a wall. The model seems really focused on registering individual servers or VMs, and everything is oriented around "services" as endpoints with specific IPs and ports. In our K8s world, pods are ephemeral, services are dynamic, and internal communication is often via cluster DNS names. Trying to map this to Banyan's concepts for access policies feels... confusing.
For example, defining a "service" for something like our internal API (which is just a Kubernetes Service name that load balances across pods) seems to require us to think about it like a static host. We also have developers who need access to specific pods for debugging via `kubectl exec`, which seems like a different paradigm entirely.
Am I missing something fundamental? Has anyone here successfully configured Banyan for a mostly Kubernetes-based infrastructure? I'd be super grateful for any pointers on how you mapped your K8s services and workloads into Banyan's framework, or if you had to change your approach significantly. The security team loves Banyan's overall model, but the implementation path from our current state feels really steep.
Yeah, that's a really common pain point! Banyan's model is definitely server/VPC-centric, which clashes with how dynamic K8s is. You're not missing anything fundamental - it's just a mismatch.
We ran into this too. For internal services, we ended up using the Banyan connector as a DaemonSet and pointing Banyan "services" at the K8s Service's cluster IP. It feels weird, but it works for HTTP traffic. For things like `kubectl exec`, we had to get creative with short-lived access tokens and a custom hook. It's not perfect.
Have you looked at their "Serverless" or "Infrastructure Access" definitions? They're newer and handle service discovery a bit better for dynamic backends. Might fit your service mesh setup more closely. What mesh are you using?
Clean code, happy life
The DaemonSet trick is a classic, like using duct tape to hold a cloud together. We tried that too until a cluster autoscaler threw a fit and redeployed the pod on a new node, breaking the "static" endpoint until we noticed.
>for things like kubectl exec, we had to get creative
Oh god, don't remind me. We built a whole 'token vending machine' sidecar that felt more complex than the app it was protecting. Their "Infrastructure Access" thing helped later on, but only after we drew the architecture on a whiteboard and cried a little. It does get better if you're using Istio, funnily enough - their newer bits play slightly nicer with a mesh. What a time to be alive.
You've perfectly identified the core conceptual mismatch. Banyan's mental model is fundamentally anchored in a static network perimeter view, where a "service" is a fixed IP and port you can point a firewall rule at. That's inherently incompatible with a declarative, ephemeral environment like Kubernetes.
>defining a "service" for something like our internal API... seems to require us to think about it like a static host
This is exactly it. You're forced to create a proxy for the dynamic reality. The workaround we used involved templating Banyan's service definitions via our CI/CD pipeline, updating them on each deployment to reflect the new K8s Service cluster IP. It was a fragile, anti-pattern that violated the very dynamism K8s provides.
For `kubectl exec`, I'd advise against trying to shoehorn it into Banyan's service model. It's a different control plane entirely. Their infrastructure access feature, which treats the K8s API itself as the target, is a better fit, but it adds another layer of policy management separate from your app access controls. You end up with two policy schemas for one cluster.
—at
Welcome to the vendor reality distortion field. You aren't missing anything, the model is just inverted. Their entire setup assumes your world is static and you must contort your dynamic K8s environment to fit.
You'll spend more time building brittle automation to keep their static service definitions aligned with your cluster than you will on actual security. For `kubectl exec`, prepare for sadness. The "Infrastructure Access" model they've bolted on is a post-hoc admission that their core product doesn't fit, and you'll be a beta tester.
If you're already on a service mesh, ask why you need another layer of indirection that fights your architecture.