Policy Map Reference

SecuriTLS uses role based access control to determine which workspace, certificate, device, storage, alert, and satellite actions a user can perform.

Overview

A policy target is written as resource:action. For example, certificates:read allows a user to view certificates, while devices:deploy allows a user to deploy certificates to devices.

Some roles use wildcard permissions such as certificates:*. A wildcard grants every action under that resource.

Roles

Owner

Full UI access to workspace resources, certificates, credentials, devices, storage, alerts, organizations, and satellites.

Admin

Broad administrative access. Admins can manage most workspace resources, but storage access may be more constrained in the UI policy map.

Operator

Day-to-day operational role. Operators can manage devices, credentials, certificates, organizations, alerts, and selected storage/satellite actions.

Viewer

Read-only role for most resources. Viewers can inspect workspace objects and run limited device test actions.

UI Policy Map

These permissions control which actions are available from the SecuriTLS web interface.

Role Allowed UI targets
owner health:*, devices:*, certificates:*, creds:*, apikeys:*, workspaces:*, organizations:*, storage:*, alert:*, satellite:*
admin health:*, devices:*, certificates:*, creds:*, apikeys:*, workspaces:*, organizations:*, storage:update, storage:default, storage:create, storage:delete, alert:*, satellite:enable, satellite:disable, satellite:create, satellite:update, satellite:delete
operator devices:create, devices:read, devices:update, devices:delete, devices:deploy, devices:attach, devices:detach, devices:validate, certificates:read, certificates:create, certificates:update, certificates:revoke, certificates:reissue, certificates:rekey, certificates:renew, certificates:delete, creds:read, creds:delete, creds:update, creds:create, creds:reveal, apikeys:read, apikeys:create, apikeys:delete, apikeys:update, workspaces:read, workspaces:invite, workspaces:update, workspaces:delete, workspaces:adduser, organizations:read, organizations:create, organizations:delete, storage:read, storage:default, alert:read, alert:update, satellite:create, satellite:update
viewer devices:read, certificates:read, creds:read, workspaces:read, apikeys:read, devices:test, organizations:read, storage:read, alert:read

Permission Matrix

This table summarizes the main UI permission groups by role.

Resource Owner Admin Operator Viewer
Health * *
Devices * * create, read, update, delete, deploy, attach, detach, validate read, test
Certificates * * read, create, update, revoke, reissue, rekey, renew, delete read
Credentials * * read, create, update, delete, reveal read
API Keys * * read, create, update, delete read
Workspaces * * read, invite, update, delete, adduser read
Organizations * * read, create, delete read
Storage * update, default, create, delete read, default read
Alerts * * read, update read
Satellites * enable, disable, create, update, delete create, update
Audit Logs

Sensitive Actions

Some actions deserve extra care because they can affect private key material, device access, workspace membership, or storage encryption behavior.

Action Reason
creds:reveal Allows a user to reveal sensitive device credential material.
storage:default Changes where future encrypted material may be stored.
storage:delete Can affect configured storage providers and BYOK-backed encryption flows.
certificates:delete Can remove certificates and detach leaf certificates from devices.
certificates:revoke Changes certificate validity and may affect deployed workloads.
devices:deploy Can place certificate material and credentials onto configured devices.
satellite:create, satellite:update, satellite:delete Can affect local key custody, signing, and deployment workflows.
workspaces:adduser, workspaces:delete Can affect membership and workspace-level access.