Declarative Access Policies
Declarative access policies state who can use a resource in a single file. You write the end state you want, and the system enforces those rules. Most engineering teams store these rule files in version control systems. They use automated pipelines to push rule changes to cloud platforms and databases. If teams make these roles too broad, users gain excess permissions across production systems. A single wide rule can expose sensitive tables or servers to every developer. How declarative access
Declarative Security Policies: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
Declarative access policies state who can use a resource in a single file. You write the end state you want, and the system enforces those rules. Most engineering teams store these rule files in version control systems. They use automated pipelines to push rule changes to cloud platforms and databases. If teams make these roles too broad, users gain excess permissions across production systems. A single wide rule can expose sensitive tables or servers to every developer.
How declarative access policies work in native tools
In a declarative model, you define the target state instead of step-by-step commands. You do not run manual scripts to add a user to a group. Instead, you list the user role, the target resource, and the allowed action. The platform reads this state file and compares it to current permissions. It then adds or removes privileges until the live system matches your file.
Cloud providers and databases evaluate these rules when a user tries to log in. An identity provider checks who the user is and what groups they join. The cloud platform then checks the declarative rule files attached to that group. If a rule allows database read rights, the user gets an active session. If no rule matches the request, the platform blocks the request right away.
Teams review changes to these rules through standard pull requests before merging them. Another engineer checks the diff to see which roles gain or lose rights. Once approved, an automated job applies the updated file to the target system. This workflow keeps a clear history of every permission change in git logs.
What native role rules solve and what they miss
Storing rules as code stops manual drift across your cloud and database accounts. Admins no longer click through web consoles to grant quick permissions during incidents. Every role assignment stays visible to auditors in one central repo. If someone changes a role by hand, the next sync resets it.
Still, native cloud and database rules only check permissions when a session starts. They decide who can log in or which high-level role a person assumes. They do not inspect what individual queries or commands do during that session. A developer with write rights to a database can still drop a table. A user with read rights can still pull thousands of customer card numbers.
Declarative Security Policies: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Static role files also struggle when engineers need temporary rights for a quick fix. Teams must either merge a pull request or keep wide standing roles open. Merging code takes time during an outage, so teams often leave broad roles active. Even with strict role files, raw emails and phone numbers return in query results. Data masking must rewrite matched fields in results, which basic role files cannot do.
How to tighten your rule design
Start by splitting broad admin roles into smaller task-based roles for each team. Group rules by the exact job an engineer needs to do today. Avoid wildcard characters that grant rights to all tables or all cloud buckets. Separate read rules from write rules so daily checks never use write roles.
Next, require peer approval on every pull request that touches your rule files. Set up automated checks to block rules that grant full admin rights. Audit your repo each month to remove roles that no one uses anymore. Pair your static role files with runtime controls that check every single command.
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
What is the difference between declarative and imperative rules?
Declarative rules state the final permissions you want in a static file. Imperative rules use step-by-step commands to add or remove rights one by one. Declarative files are easier to audit because the whole state lives in one place.
Do declarative access policies stop bad database queries?
No, native declarative rules only check if a role can use a resource. Once a user logs into a database, the role allows any query within that scope. You need command-level checks in flight to block risky queries or mask data.
How do teams handle urgent fixes with declarative files?
Wait times for pull requests can slow down urgent fixes during a live outage. Teams should use per-command approvals for live sessions instead of editing static role files. This keeps your base role files tight while letting engineers fix bugs fast.