​Role-​Based ​Access ​Control (​R​B​A​C)

This page describes how to manage access and permissions to your instance.

Overview

Kestra Enterprise supports Role-Based Access Control (RBAC), allowing you to manage access to workflows and resources by assigning Roles to Users, Groups and Service Accounts.

The image below shows the relationship between Users, Groups, Service Accounts, Roles, and Bindings (visible on the Access page in the UI).

Roles and Bindings

A Role is a collection of permissions that can be assigned to Users, Service Accounts or Groups.
Theses permissions are defined by a combination of a Permission (e.g. FLOWS) and an Action ( e.g. CREATE).

Permissions

A Permission is a resource that can be accessed by a user or group. The following permissions are currently supported:
FLOWS, BLUEPRINTS, TEMPLATES, NAMESPACES, EXECUTIONS, USERS, GROUPS, ROLES, BINDINGS, AUDITLOGS, SECRETS, IMPERSONATE, SETTINGS, WORKERS.

Actions

An Action is a specific operation that can be performed on a Permission. The currently supported Actions are:
CREATE, READ, UPDATE, DELETE.

Currently supported Roles

Kestra currently creates only an Admin role by default. That role grants full access to all resources.

Apart from that, you can create additional Roles with custom permissions.

Super Admin and Admin

Kestra provide two way for managing your instance: super admin and admin.
Super Admin is a user type with elevated privileges for global control and Admin is a customizable role that grants full access to all resources (scoped to a tenant if multi-tenancy is enabled).

Super Admin

Super Admin is a type of user that works outside the box. Without any Role or Binding, it has access to manage tenants, users, roles, groups and access within a Kestra Enterprise instance.
The purpose of the Super Admin is to allow an easy management of your instance.

Admin

In Kestra, the notion of Admin user does not exist; instead we create an Admin role with all permissions.

This role can be assigned to any User, Service Account or Group. This allows you to have different types of admin, to grant admin permissions to a whole group, and to revoke those admin permissions at any time without having to delete any group or user.

When using multi-tenancy, Kestra assigns by default the Admin Role to the user who created the tenant.

Users, Groups and Service Accounts

In Kestra you will find three types of entities:

• Users—represents a person
• Groups—represents a collection of Users and Service Accounts
• Service Accounts—represents an application

All theses entities can be assigned to a Role, which define what resources the User, Group or Service Account can access.

Note that these entities don’t belong to namespaces, but their permissions can be limited to specific namespaces via Bindings (Access page).

Users

A User represents a person who can access Kestra, identified by an email address. Each user might have personal information attached to it, such as the first name or last name.

They can change their own password, and adjust other settings such as theme, editor preferences, timezone, and a default namespace.

Groups

Each Group is a collection of zero, one or more Users or Service Accounts.

• Each User can be assigned to zero, one or more Groups.
• Each Service Account can also be assigned to zero, one or more Groups.

Groups are a useful mechanism providing the same roles to multiple Users or Service Accounts at once by binding a role to a Group.

RBAC FAQ