Access Policies for DKE 365 (RBAC + ABAC)
The Cockpit v2 access-control model for DKE 365 — RBAC for administration and ABAC access policies enforced on decrypt.
Flowchart
Access-policy decision on decrypt
Precedence is fixed: Bypass > Block > Allow > default-deny. Anything no rule allows is refused (fail-closed), and every decision is written to the audit trail.
Cockpit v2 has two distinct access-control layers. For DKE 365 they answer two different questions:
| Layer | Governs | For DKE this means |
|---|---|---|
| RBAC (roles & permissions) | Who may administer the Cockpit | Who can deploy / enable / rotate DKE services |
| ABAC access policies | Who, from where, and when may perform a runtime crypto operation | Who can decrypt DKE-protected content, from which IP / country / time / group |
The RBAC and Zero-Trust Access Control pages describe the product-level access-control concepts. In the Cockpit they are enforced by the policy engine described below, bound to a DKE service via its access_policy_id.
RBAC — administration permissions
Administrative actions (deploying, enabling and rotating DKE services, managing access policies) are governed by role-based access control. Roles are assigned to users and can be scoped to an organizational unit (OU); administrators pass all checks.
ABAC — access policies bound to a DKE service
An access policy is a tenant-scoped record evaluated on every DKE decrypt. Bind it to a service by setting the service's access_policy_id (see DKE Configuration).
The Cockpit v2 access-control layer is a first-class policy engine, not a static allow-list. A single policy composes five independent dimensions (user, IP, location, time, group), each with whitelist / blacklist / require semantics, under one of three policy actions (Allow / Block / Bypass) with deterministic precedence. It is fail-closed, tenant-scoped, optionally OU-scoped, driven by a per-app-type capability matrix, and every decision is written to a forensic audit trail — all enforced server-side on the decrypt path, so the label's protection travels with the data rather than the client.
Policy shape
A policy has a name and description, an overall action (Allow, Block, or Bypass), an optional organizational-unit scope (otherwise tenant-wide), an enabled flag, and rule blocks for each of the five access dimensions below. A per-policy setting decides whether all rule tabs must match (AND, the default for new policies) or one is enough (OR) — see How the rule tabs combine.
The five access dimensions
Each dimension entry carries a match mode (whitelist, blacklist, or require) and, where applicable, a match operator. DKE 365 supports all five dimensions.
| 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 |
How enforcement works (on decrypt)
No policy means no restriction
If no policy is attached (or it is disabled), decrypt is allowed (no policy = not restricted).
Build the access context
Cockpit v2 builds an access context from the caller: user, IP, country, current time and group membership. The Azure AD JWT is authoritative; forwarded / CDN headers (client IP, country) are used only as a fallback and cross-check, trusted only from source addresses in the configured trusted-proxy CIDR list.
Evaluate each dimension
Each dimension is evaluated by the policy engine, and the results are combined with the policy's AND / OR tab setting. Under AND, a decrypt token that carries no groups does not match a Groups tab.
Apply decision precedence
Decision precedence: Bypass > Block > Allow > default-deny.
Fail closed
An enabled policy with no rules denies. If a security audit record cannot be written for an allow in production, the decrypt is refused.
Record the decision
Every decision is written to a forensic access-policy audit log, surfaced in the Activity Logs.
Policies are created and managed from the Cockpit, and every enforcement decision is available as an audit trail surfaced in the Activity Logs.
Example: a DKE decrypt policy
A typical DKE decrypt policy allows decrypt only for members of a specific identity-provider group (for example, the label's audience), from your corporate countries, during business hours — while blocking any sanctioned country outright. You combine a group rule with location and time rules, bind the policy to the DKE service (access_policy_id), and every decrypt is then evaluated against it, with each decision recorded in the audit trail.
Access policies are how DKE 365 implements zero-trust decryption on Cockpit v2: authentication is the Azure AD token, and authorization — who / where / when / which group — is the access policy. Combine a group rule (only the label's audience) with location and time rules for a tight posture.