Access Policies (RBAC + ABAC)
The two access-control layers of the DuoKey Cockpit — role-based administration and attribute-based (ABAC) access policies that govern every runtime crypto operation.
The Cockpit has two distinct access-control layers. They answer different questions and are enforced at different points, so keeping them separate is essential:
| Layer | Governs | Where it applies |
|---|---|---|
| RBAC (roles & permissions) | Who may administer the Cockpit | The management API — deploying an app, rotating a key, editing a policy |
| ABAC access policies | Who, from where, and when may perform a runtime crypto operation | Bound to DKE services, apps and XKS endpoints; evaluated at decrypt / key-access time |
A short walkthrough of creating an access policy and watching it enforced will be added here.
RBAC — administration permissions
Administrative actions are protected by fine-grained, hierarchical role-based permissions that govern who may perform each action. A user is granted an action if they hold the matching permission or any parent that implies it; administrators pass all checks.
Permissions
Fine-grained permissions that nest hierarchically — a parent permission implicitly grants everything beneath it.
Roles
Each role bundles a set of permissions and is assigned to users. Roles can be scoped to an organizational unit (OU) so a grant applies only within that branch.
OU scope
An OU-scoped role assignment confines the permissions to the resources of that organizational unit, supporting delegated administration.
Roles, their permission sets, and their organizational-unit scoping are created and managed from the Cockpit administration console.
ABAC — access policies
An access policy is a tenant-scoped record evaluated whenever a protected key is used — for example a DKE decrypt, a generic app crypto operation, or an AWS XKS decrypt. Policies are enforced by the platform's policy engine and are the authorization layer that sits on top of whatever bearer token authenticated the caller.
Policy shape
| Attribute | Meaning |
|---|---|
| Name | Human-readable policy name |
| Description | Free-text description |
| Action | Overall policy action — Allow, Block, or Bypass |
| App type | Target app type — e.g. DKE365, Oracle TDE, AWS XKS |
| OU scope | Optional organizational-unit scope (unset = tenant-wide) |
| Enabled | Whether the policy is active |
| Rules + groups | Four typed rule blocks — user, device (IP), location and time — plus identity-provider groups |
The five access dimensions
Each dimension is a list of entries. Every entry carries a match mode (Include = whitelist, Exclude = blacklist, Require) and, where applicable, a match operator (any-of, contains).
| Dimension | Matches on |
|---|---|
| User | UPN / display name / email (regex-capable) |
| IP | Exact address, CIDR range, or start-end range (IPv4/IPv6) |
| Location | ISO-3166 country codes |
| Time | Day of week + minute-of-day range |
| Group | Identity-provider group membership |
Not every app type supports every dimension. The Cockpit exposes a capability matrix that declares which of the five categories each app type can honour, and the UI greys out the rule tabs that do not apply. DKE365 supports all five dimensions; several universal app types support only IP / location / time.
Binding a policy
A policy has no effect until it is bound to a resource. Binding attaches the policy to the target:
| Target | How it binds |
|---|---|
| DKE service | Attached to the service — enforced on every decrypt |
| Generic apps (incl. Oracle TDE) | Attached to the app — enforced on the app's crypto operations |
| AWS XKS endpoint | Attached per endpoint — enforced in the XKS decrypt path |
How enforcement works
Look up the bound policy
When a protected operation runs, the Cockpit looks up the policy bound to the resource. If none is attached, or the policy is disabled, the operation is allowed — no policy means the resource is not restricted.
Build the access context
The Cockpit builds an access context from the caller's identity and transport: user (from the JWT), IP, country, current time, and group membership. The JWT is authoritative. Forwarded / CDN headers (client IP, country) are used only as a fallback and cross-check, and only when they arrive from source addresses in the configured trusted-proxy CIDR list.
Evaluate each dimension
Each supported dimension is evaluated by the policy engine against the context.
Apply decision precedence
Decisions are resolved by precedence: Bypass > Block > Allow > default-deny.
Fail closed
An enabled policy with no rules denies — it does not silently allow. If a security audit record cannot be written for an allow decision in production, the operation is refused.
Record the decision
Every decision is written to a forensic access-policy audit log, surfaced in the Activity Logs.
The default is deny. Attaching an enabled but empty policy blocks all access to the resource until at least one Include/Allow rule matches the caller. Verify a policy end-to-end before binding it to a production resource.
Access-policy API
Access policies are created, listed, updated, bound to resources and audited through the Cockpit console and its management API. The same interface exposes the per-app-type capability matrix and the groups available for group rules.
Example rules
The five dimensions combine to express rules such as:
- Block a country — deny operations originating from a given ISO-3166 country.
- Allow only specific users — permit named users (by email or UPN) and exclude others.
- Restrict by IP and time — allow only a known subnet, and only during a defined daily window (for example Monday 08:00 to 18:00).
- Restrict by identity-provider group — require membership of a specific IdP group.
Putting it together
Create the policy
Create the policy for the correct app type with the desired rules — for example, allow operations only from a known subnet (IP dimension) during business hours (time dimension).
Bind it to a resource
Attach it to the target — a DKE service, a generic app, or an AWS XKS endpoint.
Enforce and audit
Every crypto operation on that resource is evaluated against the policy, and each decision is recorded in the access-policy audit trail.
A typical hardened policy combines an IP rule (only the expected client hosts / subnet) with a time rule (the permitted operating or maintenance window), leaving the bearer token as authentication and the policy as authorization. Layer a user or group rule on top when the caller identity is known.