Role-Based Access Control

Tuono implements Role-Based Access Control to facilitate the granular management of users and teams, Roles ( permissions) and objects. Roles can be independently applied to these target objects to create complex permission relationships, quickly and easily.

Roles

A role defines the permissions for each user or team and the target object where the role is applied. If a role is not defined then the subject has No Permissions to the target object.

Owner

• Complete authority to instantiate and to freely modify the object.

• Able to invite, change access level, or remove other users or teams from the object.

• Non-exclusive; there can be multiple owners.

Collaborator

• Able to view, update and copy the contents of the object.

• Access to perform Environment operations.

Observer

• Read only and duplicate access of the object.

Target Objects

Specific users or groups are assigned roles to individual target objects. Roles provide permissions to each individual object in the system. For example, a user can be granted the role of organization collaborator and can be set as an owner of a specific environment but only have an observer role to the blueprint in the environment. This would grant that user complete owner role privileges to execute jobs in the environment but that user would not be able to modify the blueprint.

The tables outline role permissions for each target object.

Organization

Roles applied to the organization allow you to have multiple administrators and defined roles for all organization target objects.

Role	Create/Duplicate Environments	Create/Duplicate Blueprints	Use Organization Secret	Create/Delete/Edit Organization Secret	Create/Delete Credentials	Create/Delete Teams	Invite User	Manage Sharing
Owner	✔️	✔️	✔️	✔️	✔️	✔️	✔️	✔️
Collaborator	✔️	✔️	✔️
Observer
No Permissions

Blueprints

Blueprints are the building block of infrastructure and may represent a single monolithic file containing all the infrastructure objects that describe a particular application. Alternatively, they may be highly-modular and several may be needed to create a functional application.

Roles can be applied on a per blueprint basis, so using RBAC, it becomes possible to define exactly who can view, edit and use a specific blueprint.

Role	View	Duplicate	Draft	Promote	Delete	Manage Sharing
Owner	✔️	✔️	✔️	✔️	✔️	✔️
Collaborator	✔️	✔️	✔️
Observer	✔️	✔️
No Permissions

Environment

An Environment represents a combination of blueprint(s), venue and appropriate credentials. Roles over an Environment allow users and groups to apply, destroy or view infrastructure.

Role	View	Duplicate	Add/Remove Blueprints*	Run Job	Use Environment Secret	Create/Delete/Edit Environment Secret	Delete	Manage Sharing
Owner	✔️	✔️	✔️	✔️	✔️	✔️	✔️	✔️
Collaborator	✔️	✔️	✔️	✔️	✔️
Observer	✔️	✔️
No Permissions

By default, a user or team has no permissions over any object.

Users or Groups need a minimum blueprint role of observer to add the blueprint to the Environment. If a user or group is granted an Environment Collaborator or Owner role they will automatically be granted an Observer role to any blueprints contained in that Environment.