Access Policies (RBAC + ABAC)
The two access-control layers of Cockpit v2 — role-based administration and ABAC access policies protecting keys, Oracle TDE apps and DKE services.
Cockpit v2 has two distinct access-control layers. Keeping them separate is important:
| Layer | Governs | Where it applies |
|---|---|---|
| RBAC (roles & permissions) | Who may administer the Cockpit | The management API (e.g. deploy an Oracle TDE app, rotate a DKE key) |
| ABAC access policies | Who, from where, and when may perform a runtime crypto operation | Bound to keys, apps (incl. Oracle TDE) and DKE services; evaluated at decrypt / key-access time |
A short demo video of creating an access policy and seeing it enforced will be added here.
RBAC — administration permissions
Administrative actions (managing keys, apps, DKE services and access policies) are governed by role-based access control. Roles are assigned to users; each role grants a set of permissions and can be scoped to an organizational unit (OU). Administrators pass all checks.
ABAC — access policies
An access policy is a tenant-scoped record evaluated whenever a protected key is used (for example, a DKE decrypt or an Oracle TDE master-key operation). It mirrors the access-policy model of the legacy Cockpit, re-implemented on a policy engine.
Policy shape
A policy has a name and description, an overall action (Allow, Block, or Bypass), a target app type (for example DKE 365, Oracle TDE, or a universal app), an optional organizational-unit scope (otherwise tenant-wide), an enabled flag, and rule blocks for each of the five access dimensions below.
The five access dimensions
Each dimension is a list of entries; every entry carries a match mode (whitelist, blacklist, or require) and, where applicable, a match operator.
| 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. Cockpit v2 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. DKE 365 supports all five; several universal app types support only IP / location / time.
Binding a policy
| Target | How it binds |
|---|---|
| DKE service | access_policy_id on the service — enforced on every decrypt |
| Generic apps (incl. Oracle TDE) | access_policy_id on the app — enforced on the app's crypto operations |
| AWS XKS | A per-endpoint access_policy_id, enforced in the XKS decrypt path |
How enforcement works
Look up the bound policy
When a protected operation runs, the Cockpit looks up the bound policy. If none is attached, or the policy is disabled, the operation is allowed (no policy = 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 are trusted only from source addresses in the configured trusted-proxy CIDR list.
Evaluate each dimension
Each dimension is evaluated by the policy engine.
Apply decision precedence
Decision 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.
Managing policies
Policies are created and managed from the Cockpit, which also surfaces the per-app-type capability matrix, the groups available for group rules, and the enforcement audit trail.
Example rules
Access policies compose the five dimensions with simple whitelist / blacklist / require semantics. Typical rules include: block any sanctioned country while allowing your corporate ones (location); allow only named users or exclude a pattern (user); restrict to an IP range and to business hours (IP + time); or require membership in a specific identity-provider group.
Applying an access policy to an Oracle TDE app
Create the policy
Create an access policy targeting the Oracle TDE app type, with the desired rules — for example, allow master-key operations only from the database subnet (IP dimension) during business hours (time dimension).
Bind it to the app
Bind it to the Oracle TDE app by setting the app's access_policy_id.
Enforce and audit
Every master-key management operation on that app is then evaluated against the policy, and each decision is recorded in the access-policy audit trail.
A typical Oracle TDE policy combines an IP rule (only the database hosts / subnet) with a time rule (maintenance windows for key rotation), leaving the access_token bearer credential as authentication and the policy as authorization.