Setting up your Team

In this section you will learn how to provision other team members to use the Fusebit platform.

Only account admins are able to provision other team members. If you received a CLI initialization token during on-boarding to the Fusebit platform, then you will have admin access. Otherwise you will need to be granted admin access from an existing admin.

Make sure you have already installed and initialized the Fusebit CLI.

Creating a New User

The first step in provisioning a team member involves creating a new user on the Fusebit platform.

Imagine there is a developer on your team named Paul Andrews. Create a new user for Paul with the CLI user add command:

fuse user add Paul Andrews [email protected]

The output of the user add command should look like the following:

User Added    │  User 'usr-157bf2b190124d69' was successfully added

Paul Andrews  │  Id:    usr-157bf2b190124d69
              │  Email: [email protected]

You have successfully created Paul as a user on the Fusebit platform. He has been assigned a user id of usr-157bf2b190124d69.

Granting Boundary Access

Paul is now a user on the Fusebit platform, but he doesn't have access to do anything useful.

The next step is to grant Paul access to a boundary so that he is able to create, edit and delete Fusebit functions within that boundary. A boundary is just a unit of isolation. If Paul only has access to boundary A, he can manage any functions within boundary A but not functions in any other boundaries.

A boundary name can include hyphens and any alpha-numeric characters, so we'll use the boundary name dev-paul. We reference Paul by his user id.

Grant access to Paul with the CLI user access add command:

fuse user access add usr-157bf2b190124d69 --action function:* --boundary dev-paul

The output of the user access add command should look like the following:

Access Added  │  The access was successfully added to the user
              │  'usr-157bf2b190124d69'

Paul Andrews  │  Id:    usr-157bf2b190124d69
              │  Email: [email protected]
              │
              │  Allow:
              │  • action:   function:*
              │    resource: /account/acc-9d9341ea356841ed
              │              /subscription/sub-9d9341ea356841ed
              │              /boundary/dev-paul

Since we specified the action as function:*, Paul will be allowed to perform all function-related actions. And since we specified the dev-paul boundary, the resource path constrains Paul to performing these actions only on functions within the dev-paul boundary. We could have constrained Paul to only a single function if we had specified a function name as well. Conversely, we could have allowed Paul to act on any function in any boundary if we had not specified the boundary.

Generating an Init Token

Lastly, we'll generate an initialization token for Paul. This token will allow Paul to set up the Fusebit CLI on his computer. We'll specify the dev-paul boundary again so that Paul's default profile is correctly configured as soon as he initializes the Fusebit CLI.

Generate an initialization token for Paul with the CLI user init command:

fuse user init usr-157bf2b190124d69 --boundary dev-paul

The output of the user init command should look like the following:

Init Token    │  Provide the following init token to the user. It is a single
              │  use token that will expire in 8 hours.
              │
              │  Have the user execute the following command:

fuse init <token>

Securely send this token to Paul and have him execute the CLI init command on his computer. He'll then be enabled to deploy and manage functions within the dev-paul boundary.

Granting Admin Access

If you wanted to grant admin access to a team member, you would follow the same steps as in the above example with Paul. You would create a new user, grant the user access and then generate an initialization token for the user.

The only difference is that you would grant the user access to additional resources within the Fusebit Platform.

Assuming a user id of usr-f4d8bc80014640dd, you would give this user admin access with the following CLI user access add commands:

fuse user access add usr-f4d8bc80014640dd user:*
fuse user access add usr-f4d8bc80014640dd client:*
fuse user access add usr-f4d8bc80014640dd issuer:*
fuse user access add usr-f4d8bc80014640dd function:*

The output of the final user access add command should look like the following:

Access Added  │  The access was successfully added to the user
              │  'usr-f4d8bc80014640dd'

Nancy Jones   │  Id:    usr-f4d8bc80014640dd
              │  Email: [email protected]
              │
              │  Allow:
              │  • action:   client:*
              │    resource: /account/acc-9d9341ea356841ed
              │  • action:   issuer:*
              │    resource: /account/acc-9d9341ea356841ed
              │  • action:   user:*
              │    resource: /account/acc-9d9341ea356841ed
              │  • action:   function:*
              │    resource: /account/acc-9d9341ea356841ed
              │              /subscription/sub-9d9341ea356841ed

Since this user has the ability to perform all actions on all user and client resources, she is able to add, remove and manage users and clients in the account. She can also associate a new trusted issuer with the account, or remove an existing issuer that is already associated with the account. Lastly, this user can manage any function in any boundary within the subscription because she has access with action function:* and the resource path only specifies the account and subscription.

See the Authorization Model section of this guide for more details on how to manage users, clients and issuers.


Did this page help you?