Skip to main content

Roles in Defakto

Defakto uses roles to manage permissions. The following hierarchical access roles are installed by default:

  1. Auditor
  2. Operator
  3. Manager
  4. Administrator
  5. Owner

Roles are hierarchical. Each subsequent role has the permissions of the previous role plus additional permissions. For example, Operator has Auditor permissions and the ability to create and modify clusters.

A further organization role, Member, sits outside that hierarchy. Member grants no access by default, deriving all of its access from explicit grants.

Organization Roles vs. Realm Roles: Organization roles grant permissions across all trust domains and realms. Realm-specific roles (like Realm Admin) grant permissions only within assigned realms. See Realms for more information.

Member Role​

Every hierarchical role, even Auditor, carries organization-wide read access. The Member role closes that gap by carrying no access to your infrastructure on its own, so a Member's reach is entirely grant-derived. A Member sees what you assign to them, directly or through their discovered IdP groups, and nothing beyond it. Member is also the role that just-in-time provisioned accounts land on, making it the safe landing role for automatically created users.

How Member access works:

  • One grant, one scope. Grant Realm Admin on realm prod, and the Member sees and manages exactly that: the realm, its clusters, and the workloads, agents, credentials, and activity within them. The parent trust domain also becomes visible, since the realm lives under it.
  • Unreachable resources are hidden, not refused. On the read surface, realms and clusters a Member was not granted are reported as not found rather than as a permission error, so browsing and listing reveal nothing beyond their grants.
  • Everything is scoped to the grants. Lists and statistics (clusters, workloads, credentials, agents, activity) cover only the clusters in the Member's granted realms, not the whole trust domain.
  • Trust domain infrastructure is shared, not realm-scoped. Trust Domain Servers and trust domain deployments serve every cluster in the trust domain, so a Member with a grant in a trust domain sees every server and deployment under it.
  • Self-service within their ceiling. A Member who administers a realm can create service accounts in it and manage the ones they created, capped at their own privilege level. They can set and remove those accounts' WIF configuration.

Visibility of the parent trust domain is limited to the scoped read surface: its details, deployments, workloads and statistics. Trust domain keys, configuration, federation links and CI/CD profiles stay Auditor-gated, as do service account details and reading back a WIF configuration. The secret discovery and governance features, including Ledger, also require Auditor or above.

The Member role does not appear in the permission tables below because its permissions are grant-derived rather than fixed. A Member with no grants reaches no trust domain, realm, or cluster, and cannot create a service account, because a Member must name a realm to create one in. Given a Realm Admin grant, the Realm Admin column applies within the granted realm, minus the organization-wide read access that column inherits from Auditor.

Realm Admin Role​

The Realm Admin role is a realm-scoped role that grants delegated administrative control over clusters within a specific realm. This role enables teams to manage their own infrastructure without requiring organization-wide Operator or Administrator permissions.

Realm Admin Capabilities:

  • Create, read, update, and delete clusters within the assigned realm
  • View workloads and configurations for clusters in the assigned realm
  • Register new cluster versions within the assigned realm

Realm Admin Limitations:

  • Cannot access clusters in other realms
  • Cannot create or delete realms
  • Cannot modify realm role assignments
  • Cannot elevate their own privileges

Role Permissions​

The tables below list permissions by feature area. The Realm Admin column reflects a user with the Auditor organization role who is also a Realm Admin. Such a user inherits all Auditor permissions plus the realm-scoped cluster operations noted below.1 A Realm Admin who holds the Member role keeps the realm-scoped operations and the read rows narrowed to their granted realms, but not the rows that require Auditor. A Realm Admin grant made to an IdP group adds only those realm-scoped operations: Each member's own organization role still applies on top, so an Auditor in the group keeps organization-wide read access.

Users & Invitations​

AuditorOperatorManagerAdministratorOwnerRealm Admin
List users
View organization settings
Update organization settings
Invite user
Renew / delete user invitation
List user invitations
Change user role
Delete user

Role Assignments​

AuditorOperatorManagerAdministratorOwnerRealm Admin
List roles
List role assignments
Assign / remove user role assignments

Service Accounts​

AuditorOperatorManagerAdministratorOwnerRealm Admin
View service account info
List service accounts
Create service account 2 3
Update service account4444
Delete service account4444
Link service account to realm556
View WIF Configuration
Set / delete WIF Configuration7777

WIF Issuers​

AuditorOperatorManagerAdministratorOwnerRealm Admin
List / view WIF issuers
Create / update / delete WIF issuer

Trust Domains​

AuditorOperatorManagerAdministratorOwnerRealm Admin
List trust domains
View trust domain info and signing authority status
List trust domain keys
Create / enable / disable / delete trust domain keys
List trust domain deployments
Manage deployment key sets (prepare / activate / taint / remove)
Create / register / update trust domain
Delete trust domain
Delete trust domain deployment

Clusters​

AuditorOperatorManagerAdministratorOwnerRealm Admin
List / describe clusters
List cluster versions
Create cluster6
Create / activate / deactivate cluster versions6
Delete cluster / cluster version6

Realms​

AuditorOperatorManagerAdministratorOwnerRealm Admin
List realms
Create / delete realm
Assign / remove realm roles

Federation​

AuditorOperatorManagerAdministratorOwnerRealm Admin
List federation links
Refresh federation link
Create / delete federation link

CI/CD Profiles​

AuditorOperatorManagerAdministratorOwnerRealm Admin
List CI/CD profiles and links
Create / delete CI/CD profile
Link / unlink CI/CD profile

Developer Identity​

AuditorOperatorManagerAdministratorOwnerRealm Admin
View unified access status
List developer identity policies
Add / update / delete developer identity policy
Enable / disable developer identity policy
Manage developer identity OIDC configurations

Managed Config​

AuditorOperatorManagerAdministratorOwnerRealm Admin
View organization config
View trust domain config
View trust domain deployment config
View cluster config / history / versions
Diff config versions
Update cluster config6
Update organization config
Update trust domain config
Update trust domain deployment config

Footnotes​

  1. Realm Admin is a realm-scoped role, not an organization role. This column reflects a user with the Auditor organization role who has also been assigned as Realm Admin for specific realms. Realm Admins inherit all Auditor permissions and can additionally perform cluster operations within their assigned realm(s). A Realm Admin holding the Member role instead inherits no organization-wide permissions. The realm-scoped rows apply, and the read rows apply narrowed to their granted realms rather than organization-wide, but the rows gated on Auditor are lost. ↩

  2. Service Accounts cannot have the Owner role. ↩

  3. Users can only create service accounts with a role equal to or lower than their own. Service accounts cannot create service accounts. ↩

  4. Can only update or delete service accounts they created. ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8

  5. Can only link service accounts they created to realms. ↩ ↩2

  6. Only within assigned realm(s). ↩ ↩2 ↩3 ↩4 ↩5

  7. Can only view or manage WIF Configuration on service accounts they created. ↩ ↩2 ↩3 ↩4