For modern enterprises, Identity and Access Management (IAM) is no longer just about authentication—it’s about precision, compliance, and usability at scale. Security teams grapple with two major challenges:
The explosion of IAM roles and variations that must be managed across different teams and services.
Disconnected IAM models across tools like cloud providers and release management systems, creating inconsistencies and operational inefficiencies.
At Facets, we’ve built a Role-Based Access Control (RBAC) system that prioritizes lineage-aware permissions, ensuring that every access decision is rooted in a structured mapping of Teams > Project > Environment > Resource. This approach provides security teams with simplified visibility and control, eliminating ambiguity in access rights while streamlining governance across cloud environments and the software development lifecycle (SDLC).
Traditional IAM vs. Facets RBAC: Why Lineage Matters
IAM solutions like AWS IAM, Azure AD, or Okta often rely on static, service-specific policies, which fail to provide the necessary context to manage cloud resources effectively. Managing access to virtual machines, databases, serverless functions, and Kubernetes clusters typically requires multiple overlapping policies, leading to role explosion, manual audits, and security blind spots.
Facets solves this by embedding lineage-aware permissions at the core of access management, ensuring that security teams always know the precise scope of every user’s access. Here’s how:
Challenge in Traditional IAM | How Facets Solves It |
Siloed Permissions Per Service – AWS IAM, Azure RBAC, and GCP IAM require separate policies for EC2, S3, Lambda, etc., leading to fragmented governance. | Context-Based RBAC – Permissions are tied to Teams > Project > Environment > Resource, ensuring access is always linked to operational needs rather than broad service roles. |
No Environment-Aware Context – Roles like S3-Writer apply globally, ignoring environment boundaries (e.g., Prod vs. Dev). | Environment-Scoped Permissions – Ensure that s3:DeleteObject permissions apply exclusively to Development environment buckets, preventing accidental deletions in Production. |
Manual Multi-Cloud Audits – Teams waste hours correlating permissions across AWS, Azure, and GCP consoles. | Cross-Cloud Access Analyzer – Provides structured visibility into permissions across all environments, mapped to the appropriate project and operational scope. |
Static Permissions – Cloud IAM roles lack time-bound or approval-based access, forcing risky "standing" privileges (persistent, excessive permissions). | Automated Temporary Access – Assign context-driven, time-limited permissions for cloud resources (e.g., 2-hour access to Prod RDS) via Jira/Slack, ensuring least privilege at all times. |
Role Explosion – Hundreds of roles for services like Lambda, EC2, and S3 create unmanageable sprawl. | Resource Groups + Contextual Inheritance – Group cloud resources based on business use cases while ensuring permissions remain tied to operational needs rather than arbitrary roles. |
Why Facets Wins: Lineage-Based Access Governance
Feature | Traditional IAM | Facets RBAC |
Scope | Siloed (per cloud service or K8s) | Lineage-aware policies tied to Project, Environment, and Resource. |
Role Granularity | Broad service-level roles (e.g., EC2-Admin) | Action + Environment-Level Control (e.g., ec2:StartInstance allowed only in Dev). |
Multi-Cloud Governance | Manual role replication across AWS/Azure/GCP | Consistent, structured lineage-driven governance across all cloud environments. |
Temporary Access | Standing privileges or manual revocation | Context-driven, automated temporary access with enforced expiration. |
Audits | Export logs from each cloud console | Cross-cloud/K8s audit trails, mapped to project and environment for better risk assessment. |
Real-World Impact: Why Lineage Matters More Than Just Role Management
🚀 Use Case 1: Least Privilege for Serverless & Databases
A fintech company needed to restrict DeleteTable permissions in DynamoDB to Prod environments only. With AWS IAM, this required separate roles for Dev and Prod. Facets solved this with a single DB-Admin role, scoped to environments, ensuring clear access context and reducing the number of roles.
🔄 Use Case 2: Multi-Cloud Resource Groups
A SaaS startup using AWS Lambda and Azure Functions struggled with role duplication. Facets’ lineage-aware RBAC allowed them to define Backend-Team access in alignment with project and operational structures, cutting policy management time.
🔐 Use Case 3: Auto-Revoking Cloud Credentials
A security team eliminated standing access to Prod EC2 instances by enforcing contextual approvals via Jira-based workflows, ensuring time-limited access only when needed, reducing breach risk.
Security Teams' Perspective
“One thing that I really like was that we can edit the prebuilt, predefined roles. If I feel they’re too privileged or not privileged enough, I can always go into the code, make changes, and that’s something I really like.”
“The recent change that you released about assigning multiple user groups—I think that is a big relief because before that, our IAM was a mess. At some point, you always mess up someone's permissions unknowingly.”
“We have a lot of granularity in our RBAC, controlling each and every action and entity. A few days ago, someone performed a full release and things broke down. Because of the granularity, we were able to remove just the full release portion while leaving developers free to work.”
— Vandan Rohatgi, Security Engineer, MPL
Why This Matters for Enterprises
✅ Agility – Developers self-serve cloud resource access without waiting for ops teams, with clear contextual guardrails.
✅ Risk Reduction – Permissions are always tied to environmental and project-specific constraints, reducing security gaps.
✅ Cost Savings – 60–80% fewer roles/policies to manage, with structured access context baked into every permission.
Facets is not just another IAM tool - it simplifies security design for the entire organization, enabling security teams to enforce access governance at an organizational level rather than trying to reconcile fragmented IAM models across different tools.
The Future of IAM: Why Lineage-First Access is the Key to Security
Facets’ RBAC isn’t about ticking compliance boxes - it’s about ensuring that every access decision is rooted in an operational context. By aligning cloud and Kubernetes permissions under a structured Project > Environment > Resource model, Facets eliminates silos, sprawl, and security gaps of traditional IAM.
For enterprises like MPL, the result is clear:
🚀 Stronger Security – Every permission is explicitly scoped to its operational context.
⚡ Faster DevOps – Self-service access is safe because context-driven constraints are always in place.
📉 Less Overhead – 80% fewer roles to manage, with built-in access governance.
