Integrated Role-Based Access Control
Terraform ran as its own portal outside HCP even as HashiCorp's platform grew around it. Bringing Terraform's role-based access onto HCP was the first step toward integrated "better together" workflows. HCP only ever exposed finished roles to users; Terraform exposed fine-grained permissions directly and let users assemble their own custom roles from them. Reconciling those two role models was the hardest part of the work.
In 30 seconds
- The tangle
- Terraform ran as its own portal outside HCP even as HashiCorp's platform grew around it, and HCP only ever exposed finished roles while Terraform exposed fine-grained, user-assembled permissions.
- My move
- I led the RBAC design to bring Terraform onto HCP, translating Terraform's custom roles into fine-grained HCP roles and designing an inheritance model across org, project, and resource levels.
- What changed
- Access-provisioning time dropped 30-32%, over-permissioned identities dropped about 40%, and the fine-grained-role and inheritance models were later reused by other HCP product teams.
Overview
Overview
Terraform's separateness from HCP blocked integrated cross-product workflows and impeded adoption of the broader HashiCorp portfolio. Delegating Terraform's role-based access to HCP's platform-level IAM was the entry point for closing that gap, targeting platform engineers as the primary audience.
Context
The problem
Two role assignment models, one platform
HCP exposed only finished roles to users, never the underlying permissions each role granted. Terraform exposed fine-grained permissions directly and let users assemble custom roles from them. That mismatch surfaced during an initial audit of both systems.
Fragmented portfolio
As HashiCorp's platform grew (Vault, Vault Secrets, Vault Radar, Nomad, Packer, Boundary), Terraform's separateness from HCP blocked integrated "better together" workflows across the product set, which in turn impeded adoption.
Design Process
The process spanned HCP and Terraform stakeholders on both sides — engineering, product, and design — plus a staff designer coordinating the effort. It moved from a shared-baseline workshop through a preferred direction that didn't survive technical feasibility, three UI-pattern explorations for the fallback, then converged on the org-to-project-to-resource inheritance model tested and refined below.
Alignment workshop
Opened with a workshop walking every HCP and Terraform stakeholder through both existing role-assignment experiences before any design work started, since neither side reliably knew the other's system. The two teams also carried a long, complicated shared history that made default collaboration unlikely — driving durable alignment between them was as much a part of this project as any screen.
The custom-roles direction, and why it didn't ship
The preferred direction was to let users build custom roles directly, matching Terraform's own model, rather than choose from a fixed set of fine-grained roles. After proposing it, staff and principal engineers ran a technical feasibility analysis and found it could not be built within the project timeline. The direction was dropped, and the team fell back to a fine-grained role model with a UI pattern for selecting from it instead.
Choosing how to assign fine-grained roles
With custom-role creation off the table, three UI patterns were explored for assigning fine-grained roles within the existing model. The slide-out flyout was ruled out on accessibility: the existing component was built for read-only display, not form-based interactions, and couldn't pass an accessibility audit as-is. Flat continuous search looked promising early, but would have needed extra backend and frontend work neither team had time for against a short deadline. Multi-select dropdown was the fastest path to the same outcome, and the one stakeholders ratified. The pre-existing single-select pattern was the baseline being replaced, not a competing option.
Hierarchy & inheritance model
HCP's org-to-project-to-resource hierarchy meant entitlements granted at a higher level silently applied lower down, even with no role explicitly assigned at that lower level. Worked directly with staff and principal engineers to resolve the Terraform/HCP architectural mismatch in the design layer, without waiting on backend convergence.
Highest-friction screen, before and after
Round-1 usability testing found users could not understand the inheritance system in the UI at all. That became the single highest-priority fix carried into round 2.
Scaling screen volume
Roughly 15–20 screens per hierarchy level (org, project, resource), around 45–60 screens total. Built a local, auto-updating component library to keep them consistent, done manually ahead of AI-assisted design tooling.
Usability studies
Ran two rounds of moderated usability studies with internal subject-matter experts, 8-10 participants each round, using a written study guide and Figma prototypes with a note-taker per session. Each round was followed by dedicated time analyzing the session data before deciding what to change. Round 2 followed the inheritance redesign and the addition of a role-comparison flyout (a grid of roles against their abilities) and a live assignment summary panel, with a positive reaction to both changes.
Final Solution
Role-assignment screens across the org and project hierarchy levels, with an explicit, visualized inheritance model, a role-comparison flyout, and a live assignment summary panel.
Org-level
Org-level role assignments.
Project-level
Project-level role assignments.
Impact
Pattern reuse beyond RBAC
The fine-grained-role model and the inheritance model both outlived their original scope. Other HCP product teams reused the role model, and the inheritance model was cited for later hierarchy work like Folders.
Cross-functional alignment, despite history
HCP and Terraform carried a long, complicated shared history with no default incentive to collaborate. Building durable alignment between the two teams was as real a contribution as any screen shipped.
Backend/design boundary
Worked directly with staff and principal engineers to find a UI-only resolution when Terraform's and HCP's backend architectures proved too different to reconcile, rather than waiting on backend convergence.
Reactive edge-case process
A system-wide overhaul like this generated edge cases no upfront audit fully caught. What worked instead was agile and reactive: engineers surfaced breaks as they hit them during development, and fast design turnaround closed each one.
Built the case for management
Balancing this many stakeholders across two teams with a difficult history built the case for a later transition into a people-management role.
Evidence and attribution
Owner-published case study, synthesized from the owner's own account plus an internal Meta-PRD used for background context only (not quoted publicly). Underlying audit, workshop, and usability-study artifacts exist, but they aren't publicly shareable, so most claims here are owner-stated with private evidence rather than linkable source material. The scope and retention/adoption figures are the exception — they're independently confirmed in the owner's approved public resume record. Real media is wired for Fig. 02a/02b (comparison slider), Fig. 04, 05, and 06 (all three UI-pattern explorations, video), Fig. 07 (inheritance diagram), Fig. 08 (before/after slider), Fig. 09 and Fig. 10 (org/project flows, video). Fig. 03 (custom-roles exploration) intentionally has no image, owner decision. The resource-level flow section was intentionally dropped, owner decision. Case-study hero stays hidden, owner decision; the listing thumbnail is a composed image, not a plain crop.
Evidence IDs: evidence_integrated_rbac_audit, evidence_integrated_rbac_workshop, evidence_integrated_rbac_usability_studies, evidence_integrated_rbac_provisioning_metrics, evidence_integrated_rbac_reuse, evidence_integrated_rbac_custom_roles_feasibility, evidence_integrated_rbac_ui_pattern_tradeoffs, evidence_integrated_rbac_resume_scope_metrics, evidence_integrated_rbac_management_transition
I'd love to connect with you.
For the underlying artifacts, contribution detail, or a walkthrough of the work, get in touch.
Start a conversation