Declarative Authorisation Service Das
You set up a declarative authorisation service das by defining access rules as plain text files. An engine then reads those files to check every user request against your state rules. Teams use this setup to pull permission logic out of app code. They store rule files in source control so reviewers can check changes before launch. Still, broad role definitions still create big risks for your data. When a rule grants full database read rights, any matched user can pull every row by default. How
Declarative Security Policies: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up a declarative authorisation service das by defining access rules as plain text files. An engine then reads those files to check every user request against your state rules. Teams use this setup to pull permission logic out of app code. They store rule files in source control so reviewers can check changes before launch. Still, broad role definitions still create big risks for your data. When a rule grants full database read rights, any matched user can pull every row by default.
How a declarative authorisation service das works
In an imperative setup, developers write long chains of code to check user roles. Each app holds its own custom logic to decide who can run an action. A declarative model works in a much cleaner way. You state what is allowed rather than writing step-by-step code checks. You write rules that link a user identity, a resource, and an action.
The engine takes three inputs to make a choice. First, it reads the rule files you wrote. Second, it takes context data, like user groups or time of day. Third, it reads the request details sent by the app or user. The engine checks these three parts and returns a pass or fail reply. Teams store the rule files in version control systems. When a rule changes, the engine pulls the new file and updates its state. This keeps rule checks fast and consistent across your whole stack.
What native declarative rules solve and what they miss
This model solves rule sprawl across many different apps and services. Security teams can read one set of files to see who has rights. Developers do not have to rewrite role checks every time they build an app. Audits go faster because every rule change has a clear commit history.
Still, a big gap remains once a user gets past the initial check. A declarative service often checks if a user can open a database session. Once the check passes, the user gets a live session with broad role rights. The service does not read the actual SQL statements or CLI commands sent later. An engineer with read rights can still query tables full of customer emails. A valid role does not stop someone from running a bad drop table command. The rule engine checks the door, not what happens inside the room.
Declarative Security Policies: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Closing the gap for live sessions and queries
To fix this, teams need checks that run on every single command or query. Access control must look past the start of a session. You must inspect the exact actions a user or script takes in flight. When an engineer runs a query, you need to check that statement right away. Risky commands should wait for a teammate to approve them on the spot.
You also need a way to protect private data during normal read queries. Data masking rewrites matched fields like phone numbers, card numbers, or national IDs in results. This lets engineers fix bugs without exposing raw customer details on their screens. By pairing declarative state rules with live query checks, you control both login and action.
Govern statements and responses across databases and APIs
Good config and scoped roles are needed setup. They do not check single queries in flight or mask sensitive fields in returned rows. Across Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, and internal HTTP endpoints, hoop.dev runs beside each supported service as an open-source proxy, a sidecar for your database or API.
First, hoop.dev guardrails block banned queries before they run. Then hoop.dev data masking rewrites matched sensitive values in responses in memory. The audit trail records every statement and verdict per resource. Furthermore, hoop.dev holds SOC 2 Type II and is open source on GitHub.
Frequently asked questions
How does declarative authorization differ from imperative authorization?
Declarative rules state who can do what in a separate text file. Imperative checks bury that logic inside app code using long chains of conditions.
Can a declarative service stop a bad database query?
Most declarative engines only check if a user can start a session or call an API. They do not parse live SQL statements or block bad commands inside an open session.
How do teams protect private data after a role check passes?
Teams use real-time data masking to rewrite fields like emails and card numbers in query results. This keeps sensitive fields safe even when a user has valid read rights.