Authorization

Listing Permissions

Permissions in Shipa work in a hierarchical model and are typically represented using a dot notation. Granting access to top-level permission implies access to all permissions below it.

shipa permission list [-t/--tree]

The command above lists all permissions available for use when defining roles.

Flags:

Creating Roles

It is not possible to assign permissions to users directly. You first have to create a role, including the desired permissions, then assign this role with a context value to one or more users.

shipa role add <role-name> <context-type> [--description/-d description]

The command above creates a new role for the specified context type. Valid context types are:

• global (for Shipa Self-Hosted only)
• organization (for Shipa Cloud only)
• app
• team
• framework

📘

Context Explanation

Suppose a user has the app.deploy permission for the team named myteam it means the user can only deploy applications to which myteam has access. In the same way, it is possible to assign the same app.deploy permission to a user with the context app for one application named myappname. This means the user can now deploy this specific application called myappname.

📘

Global or Organization Context

The global or organization context is a special case. It gives users permission to perform all actions on Shipa.

In the previous scenario, if a user has the app.deploy permission with a global or organization context; it means that the user can deploy any application.

The --description parameter sets a description for the role. It is an optional parameter, and if it's not set, the role will only not have a description associated.

Flags:

Updating Roles

shipa role update <role> [-d/--description <description>] [-c/--context <context type>] [-n/--name <role new name>]

The command above updates a role description.

Removing Roles

shipa role remove <role-name> [-y/--assume-yes]

The command above removes an existing role.

Flags:

Listing Created Roles

The command below lists all existing roles.

shipa role list

Role Information

Through the command below, users can retrieve information about a specific role.

shipa role info <role-name>

Adding Role Permission

📘

Permission Hierarchy

Permissions in Shipa work in a hierarchical model and are typically represented using a dot notation. Granting access to top-level permission implies access to all permissions below it.

When adding a new permission to an existing role, users should execute the following command:

shipa role permission add <role-name> <permission-name>

Removing Role Permission

shipa role permission remove <role-name> <permission-name>

Removes a permission from an existing role.

Assigning User to Role

The command below assigns an existing role to a user or token with some context value.

shipa role assign <role-name> <user-email>|<token-id> [<context-value>]

Removing Roles from Users

shipa role dissociate <role-name> <user-email>|<token-id> [<context-value>]

Dissociates an existing role from a user or token for some context value.

Listing Roles

shipa role default list

Lists all roles set as default on any event.

Adding Default Roles

It is possible to have default roles applied to a user when some event happens on Shipa; events such as user create and team create.

• To list all possible events, use the role default list command.
• To include a new role in an event, use the role default add command.
• To remove a role from an event, use the role default remove command.

Once these roles are created, they can be added as defaults on the appropriate event.

shipa role default add [--user-create <role name>]... [--team-create <role name>]

Adds a new default role on a specific event.

Flags:

Removing Default Roles

shipa role default remove [--user-create <role name>]... [--team-create <role name>]

Removes a default role from a specific event.

Flags:

Creating Additional Super Admins - Shipa Self-Managed

For self-managed e.g on-prem installations, as a good practice, having more than one installation level admin user is prudent. In case the unavailability of one admin, there is a secondary, etc admin to manage.
From an admin account, grant the AllowAll role to another account.

shipa role assign  AllowAll [email protected]