GitLab's 'Two Front Doors' for Internal Apps

GitLab shared its blueprint for building a single internal application that securely serves two very different teams with different access needs.

GitLab's engineering team faced a common challenge when an internal tool began serving more than one master. According to a post on the company's blog, its Governance, Risk, and Compliance (GRC) application had to support two distinct user groups: the Security Compliance team and the Internal Audit team. This created a classic authorization problem of how to provide each group with access to only the features and data they need, all within a single application. This scenario is familiar to many growing companies, where internal tools often evolve to serve multiple departments, leading to complex and brittle permission systems. GitLab's solution offers a clear case study in tackling this issue head-on with a clean, maintainable architecture.

Instead of implementing a complex, object-level permission system from the start, GitLab's engineers opted for what they call "module-level access." They leveraged Django's built-in permissioning framework but organized access logically around the application's core features. Each major section of the GRC tool was treated as a distinct module. The team then created specific user groups, such as "Security Compliance" and "Internal Audit," and assigned permissions to these groups at the module level. This means a user in the audit group might see the "Audit Engagements" module but be completely blocked from the "Compliance Controls" module. This is enforced through custom middleware in their Django app, which checks a user's group memberships and associated module permissions before rendering any part of the user interface, effectively creating two separate "front doors" into the same application.

This approach reflects a broader industry trend toward building flexible, scalable internal platforms instead of siloed, single-purpose tools. As companies grow, the cost and complexity of maintaining dozens of separate internal applications become unsustainable. Consolidating tools is more efficient, but it introduces security and usability challenges like the one GitLab solved. Their solution is a practical example of the "platform engineering" mindset, where internal development teams create shared, reusable systems that can be configured for different internal customers. It strikes a crucial balance between the simplicity of a single codebase and the granular control required in a multi-tenant environment, a core challenge in modern enterprise application architecture.

The key takeaway for developers, CTOs, and security teams is that a robust access control system doesn't always require a heavyweight, third-party authorization framework. By thoughtfully using the tools built into a framework like Django, teams can create secure and maintainable solutions. The GitLab model of grouping permissions by application module provides a pragmatic starting point for any internal tool that is beginning to serve more than one audience. This foundation allows for an evolutionary approach to security, where more fine-grained, object-level permissions can be added later where necessary. This strategy prevents over-engineering while ensuring the application remains secure and easy to manage as its user base diversifies.

This provides a real-world architectural pattern for implementing granular, module-level authorization in Django. For developers building internal tools, it's a valuable guide to avoiding monolithic permission systems and creating flexible, multi-tenant applications without building separate apps for each user group.

Building one internal tool instead of two saves significant development and maintenance costs. This approach also reduces security risks by centralizing access control, ensuring that sensitive data is only visible to the correct teams, which is critical for compliance and audit functions.