User management
Union.ai includes role-based access control (RBAC) for managing user and application permissions. The authorization system is based on the following concepts:
- Action: An operation that can be performed by a user or application.
For example,
register_flyte_inventoryis the action of registering tasks and workflows. - Role: A set of actions. The system includes built-in roles (see below) and also enables administrators to define custom roles.
- Policy: A set of bindings between a role and an organization, project, domain, or project-domain pair.
- User or application: An actor to which policies can be assigned. Through the assigned policies, the user or application acquires permission to perform the specified actions on the designated resources. A user is a person, registered and identified by email address. An application is an automated process (a bot, service, or other type of program), registered and identified by application ID.
- Organization: A set of projects associated with a company, department, or other organization.
- Project: A set of associated workflows, tasks, launch plans, and other Union.ai entities.
- Domain: Categories representing the standard environments used in the development process: development, staging, and production.
- Project-domain pair: The set of projects is divided orthogonally by the three domains.
The result is a set of project-domain pairs.
For example:
flytesnacks/development,flytesnacks/staging, andflytesnacks/production.
Actions
The following is the full list of actions available in the Union.ai system:
administer_project: Permission to archive and update a project and manage customizable resources.manage_permissions: Permission to manage user and machine applications and their policy assignments.create_flyte_executions: Permission to launch new executions.register_flyte_inventory: Permission to register workflows, tasks, and launch plans.view_flyte_executions: Permission to view historical execution data.view_flyte_inventory: Permission to view registered workflows, tasks, and launch plans.
Built-in policies
Union.ai ships with three built-in policies: Admin, Contributor, and Viewer.
- An Admin has permission to perform all actions (
administer_project,manage_permissions,create_flyte_executions,register_flyte_inventory,view_flyte_executions,view_flyte_inventory) across the organization (in all projects and domains). In other words:- Invite users and assign roles.
- View the Monitoring and Billing dashboards.
- Do everything a Contributor can do.
- A Contributor has permission to perform the actions
create_flyte_executions,register_flyte_inventory,view_flyte_executions, andview_flyte_inventoryacross the organization (in all projects and domains). In other words:- Register and execute workflows, tasks, and launch plans.
- Do everything a Viewer can do.
- A Viewer has permission to perform the actions
view_flyte_executionsandview_flyte_inventoryacross the organization (in all projects and domains). In other words:- View workflows, tasks, launch plans, and executions.
Multiple policies
Users and applications can be assigned to zero or more policies. A user or application with no policies will have no permissions but will not be removed from the system (they will still appear on the list of users). A user or application with multiple policies will have the logical union of the permission sets of those policies.
The default policies that come out of the box are hierarchical. The Admin permission set is a superset of the Contributor permission set, and the Contributor permission set is a superset of the Viewer permission set. This means, for example, that if you make a user an Admin, then additionally assigning them Contributor or Viewer will make no difference. But this is only the case due to how these particular roles are defined. In general, it is possible to create roles where assigning multiple ones is meaningful.
Custom roles and policies
You can create custom roles and policies to mix and match permissions at the organization, project, or domain level.
Roles and policies are managed using the
uctl CLI.
Create a role
Create a role spec file my_role.yaml that defines a set of actions:
:name: my_role.yaml
name: Workflow Runner
actions:
- view_flyte_inventory
- view_flyte_executions
- create_flyte_executionsCreate the role from the command line:
$ uctl create role --roleFile my_role.yamlSee
uctl create role for full details.
List and view roles
To list all roles:
$ uctl get roleTo view a specific role:
$ uctl get role --name "Workflow Runner"See
uctl get role for full details.
Delete a role
$ uctl delete role --name "Workflow Runner"See
uctl delete role for full details.
Create a policy
Create a policy spec file my_policy.yaml that binds roles to project/domain pairs.
Here we create a policy that binds the Contributor role to flytesnacks/development and binds the Workflow Runner role (defined above) to flytesnacks/production:
:name: my_policy.yaml
name: Workflow Developer Policy
bindings:
- role: Workflow Runner
resource:
project: flytesnacks
domain: production
- role: contributor # Built-in system role
resource:
project: flytesnacks
domain: developmentCreate the policy from the command line:
$ uctl create policy --policyFile my_policy.yamlAny user or application to which this policy is assigned will be granted Contributor permissions to flytesnacks/development while being granted the more restrictive Workflow Runner permission to flytesnacks/production.
See
uctl create policy for full details.
List and view policies
To list all policies:
$ uctl get policyTo view a specific policy:
$ uctl get policy --name "Workflow Developer Policy"See
uctl get policy for full details.
Delete a policy
$ uctl delete policy --name "Workflow Developer Policy"See
uctl delete policy for full details.
Assign a policy to a user or application
Once a policy is created, you can assign it to a user or application using the command line:
$ uctl append identityassignments \
--user "[email protected]" \
--policy "Workflow Developer Policy"Similarly, you can assign the policy to an application:
$ uctl append identityassignments \
--application "contoso-operator" \
--policy "Workflow Developer Policy"See
uctl append identityassignments for full details.
View identity assignments
To list all identity assignments:
$ uctl get identityassignmentSee
uctl get identityassignment for full details.
Remove identity assignments
$ uctl delete identityassignments \
--user "[email protected]" \
--policy "Workflow Developer Policy"See
uctl delete identityassignments for full details.
Initial onboarding
The initial Union.ai onboarding process sets up your organization with at least one Admin user who has permission to invite teammates and manage their roles.
Managing users in the UI
You can also manage users and their policy assignments through the Union.ai UI. Navigate to Settings > User Management to access the user management interface.
To manage users you must have the Admin policy (or a custom policy that includes the manage_permissions action).
From the user management interface you can:
- View users: See the list of all users and their assigned policies. You can search the list and filter by policy.
- Add a user: Add a new user by specifying their name, email, and the policies to assign. The new user will receive an email invite from Okta. They should accept the invite and set up a password, at which point they can access the Union.ai UI.
- Change assigned policies: Select a user to edit their assigned policies.
- Remove a user: Select a user and choose the option to remove them.
You can also assign policies to users from the command line using uctl append identityassignments (see
Assign a policy to a user or application above).