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

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. Supported Permissions:

• FLOW
• BLUEPRINT
• TEMPLATE
• NAMESPACE
• EXECUTION
• USER
• GROUP
• ROLE
• BINDING
• AUDITLOG
• SECRET
• IMPERSONATE
• SETTING
• INFRASTRUCTURE

Actions

An Action is a specific operation that can be performed on a Permission. Supported Actions:

• CREATE
• READ
• UPDATE
• DELETE

Currently Supported Roles

Currently, Kestra 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 provides two way for managing your instance: super admin and admin.

• Super Admin is a user type with elevated privileges for global control
• Admin is a customizable role that grants full access to all resources (scoped to a tenant if multi-tenancy is enabled).

Super Admin

Without any Role or Binding, Super Admin has access to manage tenants, users, roles, groups and access within a Kestra Enterprise 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.

To add users to your Kestra instance, you can do one of the following:

• Invite users to your instance or tenant from the UI
• Sync users from an external identity provider using SCIM
• Create users directly using Terraform

Change password

If a user wants to change their password, they can do it on their profile. This page can be accessed through the top right corner of the UI.

Reset password (by a Super Admin)

Kestra does not provide any forgot password feature yet. Currently only a super admin can update a user password through its User Edit page.

Groups

Each Group is a collection of 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 for providing the same roles to multiple Users or Service Accounts at once by binding a role to a Group.

What happens if you delete a Group?

All Users and Service Accounts assigned to that Group will lose permissions that were binds to the groups. However Users and Services Accounts will still exist.

RBAC FAQ