Access and permissions

Two distinct notions coexist:

• App Access — who can use a deployed application (sign in to Digdash BI, to Hop…);
• Internal Permissions — who can administer what within the Control Panel itself.

App Access

The App Access page (or the Manage access button on a card, not available for PostgreSQL) lists, for each OIDC-authenticated application, the authorized users — individually or in bulk.

Two mechanisms depending on the template, shown automatically by the page:

• Profiles (most templates, e.g. Digdash BI): granting access means assigning one or more profiles (application roles) to the user — a user with no profile has no access. The Add profiles button opens the selection.
• Direct grant / revoke (Apache Hop GUI only): a simple binary grant, with no notion of profile — Grant / Revoke buttons.

Internal Permissions

Control Panel roles are granted per namespace (the user acts on the whole namespace) or per application (scope limited to a single application):

Role	What it allows
viewer	View the applications, volumes, buckets in scope
operator	+ start/stop/restart, configure, resync
admin	+ deploy and delete, manage access and permissions in scope

On top of this comes the platform administrator status, which is cross-cutting: managing users, namespaces and quotas, cluster settings, the Git instance and relay authentication.

Groups

Groups let you grant a set of application access rights and permissions to several users at once. A group carries its members, its access grants and its permissions per namespace or application.

Note

Control Panel permissions are independent from each application's own internal roles: granting operator on a namespace does not, for example, grant administration rights inside Digdash BI itself.