We recently moved from Teleport to Boundary for managing secure access to our internal tools. The main driver was cost, as our Teleport bill was getting steep for our team size.
We've hit a snag with access control that's slowing our rollout. In Teleport, assigning a user to a role gave them access to a specific set of nodes. With Boundary, we're using scopes and roles, but the mapping feels less direct. For example, we have a role for "read-only analysts" that should only allow connecting to a specific set of PostgreSQL targets. Even with the right grants, some users in that role are seeing (but failing to connect to) other dev targets. It feels like we're managing permissions at too granular a level.
Has anyone else faced this after a migration? Specifically, how did you model your previous Teleport "roles" within Boundary's structure of scopes, roles, and grants? Any tips on avoiding this kind of scope creep?
Still learning.
I'm a platform lead at a mid-market SaaS shop, running a hybrid stack with 300ish devs and analysts. We've been on Boundary in production for about 18 months after evaluating Teleport, and we manage access to roughly a thousand database and app targets.
* **Target fit:** Teleport is built for engineers, by engineers. It assumes your users understand SSH and Kubernetes contexts. Boundary is an abstraction layer built for operators to broker access for *non*-engineers. If your "read-only analysts" are, say, data scientists, Boundary's model is actually the right fit. If they're DevOps folks, you're fighting it.
* **Real pricing & hidden costs:** Teleport's published per-user pricing is straightforward but gets brutal at scale. Boundary's open-source core is free, but the real cost is operational. You *must* run a controller and workers, which is at least three VMs with HA. Our managed compute for Boundary runs about $300/month, but we spent 20-25 engineering hours getting the scope and role structure right. The cost shift is from licensing to implementation.
* **Permission model granularity:** This is your pain point. Teleport roles are essentially tags for nodes. Boundary uses a RBAC model where a role is a collection of *grants* (permissions) within a *scope* (project, org, global). The mapping feels indirect because it is. You don't grant "access to node A." You grant "connect to target B," which is a resource inside a scope, and that target's host sets define the actual endpoints. The "scope creep" you see happens when users have roles in a parent scope (like "org") that grants listing capabilities on targets in child scopes.
* **Where Boundary clearly wins:** Once modeled, delegating access to non-SSH resources (like that PostgreSQL DB) is cleaner. You define a target once, and its connection parameters and credentials are brokered automatically. We have finance users connecting to internal web apps via HTTPS without a VPN, which we could never have rolled out with Teleport. The audit log is also more detailed for compliance purposes.
I'd stick with Boundary, but only if your primary need is secure, brokered access for non-engineers to web apps and databases. If your use case is purely engineers needing SSH and kubectl, tell us that, and I'd tell you to swallow the cost and go back to Teleport.
-- cost first
That granular permission feeling is the biggest mental shift. Boundary's model is "deny by default, then explicitly grant," while Teleport often feels like "allow by role, maybe restrict."
I modeled our old Teleport roles by creating a dedicated scope for each logical role, like `analysts-ro`. Then I set up a role inside that scope with the exact target grants needed. It's more overhead initially, but it keeps the visibility problem you're seeing in check - users only see targets in the scopes where they have roles.
Question: Are you using host catalogs and host sets? If your analysts are seeing dev targets, my guess is those targets are in a host set that's being granted to a role they belong to, maybe at a parent scope. That inheritance can surprise you.
Prompt engineering is the new debugging.
Yeah, that scope inheritance got us too. The trick isn't just modeling your old roles, it's about flattening your scope tree for user roles.
We put all our end-user roles in the same global child scope, like "access-prod". No inheritance. Then, the host catalogs and targets for analysts live there, and the dev targets live in a separate "access-dev" scope. Users get added to a role in *only* one of those scopes. They never see the other catalog because it's in a different scope they can't even read.
It feels wrong coming from Teleport, but it works. You're managing one extra scope instead of juggling grants and inheritance. Are your analyst and dev targets in the same host catalog?
Yeah, that "dedicated scope per logical role" pattern is solid advice. We tried that early on too, but ran into a scaling issue when someone needed to belong to multiple logical roles. We ended up with scope sprawl.
The host catalog point is key. The inheritance trip-up happens so easily. In our setup, we had a single "postgres-prod" host catalog at the org scope for convenience. Even with separate roles, if both roles pulled from that same catalog at the parent scope, users saw everything in it, even targets they couldn't connect to. It created that confusing "I can see it but I can't click it" experience that really frustrates analysts.
We had to break the habit of centralizing resources and instead attach the host catalog directly to the child scope where the role lives. It felt inefficient at first, but it totally eliminated the visibility clutter. Did you find managing those decentralized catalogs to be a pain, or did you automate it?
Pipeline is king.
The "see but can't connect" problem usually comes from target visibility being granted at a parent scope, like the org level. It's a visibility vs. authorization split that trips up a lot of teams.
Your instinct about mapping Teleport roles directly to Boundary roles is the right starting point, but you need to pair each role with its own *scope*. That scope should contain the dedicated host catalog and targets for just that role, cutting off the inheritance that's letting them see dev resources. It feels like extra work, but it's how Boundary enforces that clean boundary.
Did you centralize all your PostgreSQL targets into one host catalog initially? That's the most common culprit for this kind of scope creep.
Putting end-user roles in separate child scopes is a logical approach to cut inheritance. We use a similar model, but you'll need to monitor role sprawl as the number of these dedicated access scopes grows.
I'd add a caveat about session recording. If you have a global audit requirement, your recording storage policy may need to reference all these disparate child scopes, which can complicate reporting.
EXPLAIN ANALYZE
That makes a lot of sense. So the dedicated scope essentially acts as a permission boundary for visibility, not just connection. I hadn't thought of it that way.
If you create a scope per role, how do you handle a user who genuinely needs two roles? Like an analyst who also needs occasional dev access? Do you create a whole new, third scope for that combined permission set?
You've hit on the main operational trade-off with that model. Creating a third, combined scope is one way, but it leads to scope proliferation.
A more maintainable pattern is to keep the roles and their scopes separate, then assign the user to multiple roles. Boundary will union the permissions, and the user will see targets from both scopes in their session list. The key is ensuring the host catalogs and targets are isolated to each role's scope, so there's no inheritance overlap creating confusion.
The visibility isn't a problem if the targets are clearly named, like `prod-analytics-db` and `dev-testing-db`. The user sees both, but the grants in each role only allow the intended connections. This approach scales better than managing combinatorial scopes for every permission set.
Measure everything.
That scope creep feeling is exactly why I lasted three months with Boundary before moving our team to something else. You're mapping a square peg to a round hole.
The core issue is that Boundary treats visibility as a separate permission. Your analysts see dev targets because *someone* in their scope can see them, even if they can't connect. The advice here to create a dedicated scope per role is technically correct, but it's a band-aid that creates a configuration nightmare.
My take: if your analysts are technical enough to use Teleport, Boundary's abstraction layer is just adding friction. You're trading a high bill for high admin overhead. The real "cost" wasn't just the Teleport invoice, it was the engineering time to rebuild your mental model and now manage a dozen scopes instead of a handful of roles.
Have you calculated the time spent on this permission redesign? In my last gig, that's when we realized the "free" tool wasn't.