core overview
How duck-iam combines RBAC and ABAC into a single evaluation pipeline. Subjects, resources, policies, rules, and combining algorithms.
What is duck-iam?
A hybrid access control engine. Roles (RBAC) and policies (ABAC) feed the same evaluation pipeline — no separate paths.
Roles convert to ABAC policies internally. Every check runs through one evaluator.
Reading order
| Page | Covers |
|---|---|
| evaluation pipeline | Step-by-step request → decision flow, dev vs prod modes |
| primitives | Subject, Resource, Action, Scope, Environment, AccessRequest, Decision |
| rule matching | When a rule fires — action match, resource match, conditions |
| cross-policy combination | AND across policies, default effect, defense in depth |
| roles | RBAC — defining, inheritance, scoped, conditional |
| policies | ABAC — building, conditions, targets, combining algorithms |
Quick mental model
Subject + Action + Resource + Scope + Environment
|
v
[ RBAC roles → __rbac__ policy ] [ Custom ABAC policies ]
| |
+--------- evaluate each ------------+
|
v
AND-combine across policies
|
v
Decision (allow / deny)
A deny from any policy is final. The cross-policy combiner is fixed engine behavior — no per-policy tuning to override it.
Why hybrid?
RBAC alone can express "editors update posts" but not "editors update posts they own during business hours." ABAC alone forces every grant to be a hand-written rule, which is verbose for the simple cases.
duck-iam lets you:
- Express common grants as roles (concise, easy to reason about)
- Express contextual rules as ABAC policies (deny on weekends, owner-only edits, geo-fencing)
- Have both contribute to the same decision via AND-combination
The result: roles cover 80% of grants in 20% of the code, ABAC handles the long tail.