Teams and roles

A workspace is your team's space in Vulnara. Every repository, scan, finding and setting belongs to exactly one workspace, and only its members can see them. Each member holds a role that decides what they may do there. The account menu calls a workspace a team, for example Create New Team, and the members screen is Team.

What it is for

• Keeping each team's or customer's data apart.
• Giving people read-only access, or the right to change things, or full control.
• Bringing colleagues in by email, whether or not they already use Vulnara.

How it works

You can belong to several workspaces. The account menu lists them, and choosing one switches the whole app to it. Vulnara remembers your choice when you reload the page.

Every request, from the web app, the CLI, the API or an AI client, names one workspace. Vulnara checks that you belong to it and checks your role there before doing anything.

The roles

• Viewer: read-only access to everything in the workspace. A member with no role set is a viewer.
• Editor: everything a viewer can do, plus changing things: adding and deleting repositories, git workspaces and networks, starting and cancelling scans, managing schedules, ignore paths, alert rules, remediation templates and triage decisions.
• Admin: everything an editor can do, plus the team and the money: inviting and removing members, changing roles, managing invitations, git tokens and service accounts, transferring git workspaces and networks to another workspace, changing the plan and managing payment methods.

A higher role always includes the lower ones.

In the app, an action your role does not allow is still shown, but disabled, with a note naming the role it needs.

What you can set

• Workspace name: set when you create it. It must be unique across Vulnara, and it becomes the workspace id you use in the CLI, the API and the GitHub Action.
• Members: who belongs to the workspace.
• Roles: Viewer, Editor or Admin for each member.
• Invitations: pending invitations, which you can revoke.

Do it

Create a workspace

1. Open the account menu and choose Create New.
2. Enter a Name and confirm.

You become its admin, and the app switches to it. API: createTenant. CLI: create_tenant.

Invite a member

1. Go to Settings, then Team.
2. Choose Invite Team Member.
3. Enter their Email and choose Invite.

Vulnara emails them a link, in the language you are using the app in. API: inviteTenantMember.

• Someone who already has a Vulnara account gets a link to an invitation page in the app. It shows the workspace name, with Join Team and Reject Invitation. They are let into the workspace as soon as you invite them, so that they can sign in and reach the invitation.
• Someone with no account gets a sign-up link. Creating the account through it joins them to the workspace.

A new member starts as a viewer. Change their role once they have joined.

Change a member's role

1. Go to Settings, then Team.
2. Select one member and choose to update their roles.
3. Pick the role and save.

API: updateUserRoles.

Remove a member

On the Team screen, select the members and choose Remove. API: deleteTenantMember.

Revoke an invitation

Pending invitations are listed on the Team screen. Choose Revoke on one. If the invitation had already let an existing user into the workspace, revoking it takes that access away again. API: deleteInvitation.

Move a git workspace or a network to another workspace

1. In Workspaces, choose Transfer on the git workspace.
2. Enter the id of the destination workspace in New Tenant and confirm.

To transfer, you need the admin role in the current workspace and at least the editor role in the destination. Networks move the same way through the API. API: transferGitEntity and transferNetwork. CLI: transfer_git_entity and transfer_network.

Good to know

• Invitations expire after two days. Send a new one if it runs out.
• Existing members cannot be invited again. Inviting someone who is already in the workspace is refused.
• An invitation is personal. Only the person it was sent to can open, accept or reject it.
• Rejecting undoes the early access. If an existing user rejects an invitation, the access they were given when you invited them is removed.
• Adding a member does not subscribe them to alerts. Recipients are set on each alert rule.
• Viewers do not see email addresses. In the member list, a viewer sees other members' names and roles, but only their own email address.
• Service accounts are not members. They do not appear on the Team screen and are managed separately. See Service accounts.
• Transfers have to change something. A transfer to the workspace the item is already in is refused. A destination you do not belong to, or where you are only a viewer, is refused with the same error as one that does not exist.
• Plan limits belong to the workspace. Each workspace has its own plan and usage. See Plans, usage and billing.