ACL Domain
An acl domain groups network or app resources under one shared set of access rules. You set up an acl domain by mapping user roles to specific resource targets. Most engineering teams start by creating broad rules so developers can build fast. Over time, these wide permissions create security risks when one role touches too many systems. A single bad query or command can then affect every database in that group. How an acl domain works in practice Every system needs a clear way to check who c
Cross-Domain SSO: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
An acl domain groups network or app resources under one shared set of access rules. You set up an acl domain by mapping user roles to specific resource targets. Most engineering teams start by creating broad rules so developers can build fast. Over time, these wide permissions create security risks when one role touches too many systems. A single bad query or command can then affect every database in that group.
How an acl domain works in practice
Every system needs a clear way to check who can read or write data. A domain acts as a boundary around related databases, servers, or internal apps. Inside this boundary, an access control list defines which users hold specific rights. Admins attach rules to groups rather than single users to keep work simple.
When a user tries to log in, the system checks their group membership first. It then reads the domain rules to see if that group has permission. If the rule matches, the system lets the user open a session. If the rule fails, the system blocks the request right away.
Teams often split these domains by stage, such as test, staging, and prod. Each stage gets its own list of allowed roles and network paths. This split stops a test script from writing data into a prod database. Admins also group rules by team function, like billing, support, or core platform.
Why teams struggle with static domain rules
Setting up boundaries by role works well when a team is small. As more apps and databases go live, the number of rules grows fast. Admins end up managing ratusan of small lists across different cloud tools and servers. When an engineer needs quick access to fix a bug, admins often grant broad roles.
Those temporary permissions rarely get removed after the fix is done. Soon, dozens of people hold full write rights across the entire prod boundary. Static rules also struggle to handle shared accounts or service keys. Two apps in the same domain might share one database role for ease of setup.
Cross-Domain SSO: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
When both apps use the same key, audit logs cannot show which person ran a query. Security teams then spend days trying to trace who changed a critical table. Cleaning up these old rules takes manual review and risks breaking live apps.
What native domain controls leave open
Native domain rules are good at deciding who can log in to a system. They check the user identity at the start of a session and grant entry. Once the session starts, Still, the domain rule steps out of the way. It cannot see or control the actual commands a user runs inside that session.
A developer with read rights can still pull thousands of customer emails and card numbers. An engineer with write rights can drop a table by mistake during a routine fix. The domain rule only knows that the user was allowed to be there. It does not check each query, block risky commands, or rewrite sensitive fields in results.
Check database and API queries on the wire
Identity tools, roles, and network rules decide who opens a session. Setup alone cannot check what each query does or mask sensitive values in a response once a session starts. When workflows touch Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, or internal HTTP APIs, hoop.dev runs beside those services as an open-source proxy, a sidecar for your Postgres or API. It inspects requests coming in and results going back on the wire.
Your login details and client tools stay as they are while hoop.dev guardrails refuse bad deletes or drops before they run. On responses, hoop.dev data masking rewrites matched sensitive values in memory. Furthermore, hoop.dev holds SOC 2 Type II, is MIT licensed, and writes every query and decision to an audit trail that generates evidence for HIPAA, GDPR, and PCI DSS. See the source on GitHub.
Frequently asked questions
What is the difference between an acl domain and a single access list?
A single access list applies rules to one specific file, table, or server port. An acl domain groups many resources together so they share one common policy boundary.
How often should teams review their domain access rules?
Teams should check their access lists at least once every quarter. Removing unused roles and old accounts keeps the permission boundary tight and clean.
Can domain rules stop a user from viewing sensitive data fields?
No, standard domain rules only permit or deny entry to the resource itself. To hide emails or phone numbers in query results, you need field-level data masking.