Docs

People & Access

What this screen is for

People & Access decides who can do what. It holds four tabs that build on each other: you create policies (sets of permissions, optionally limited to particular clusters and environments), collect them into roles, assign roles to users, and use groups to organise those users.

Nothing here grants a permission directly to a person. Access always travels permission → policy → role → user, and the most common mistake is trying to skip a link in that chain.

Before you start

Tab Read permission Change permission
Users platform-settings.user.read .user.create .user.update .user.delete .user.assign-group
Groups platform-settings.group.read .group.create .group.update .group.delete .group.view-details
Roles platform-settings.role.read .role.create .role.update .role.delete
Policies platform-settings.permission-policy.read .permission-policy.create .update .delete

A tab you cannot read is not shown. Buttons for actions you cannot perform are hidden or disabled rather than failing on click.

Opening it

  1. Click Settings in the sidebar.
  2. Click People & Access.

Direct URL: /platform-settings/access

The interface

📸 Screenshot Placeholder: The People & Access page with the four tabs across the top and the Users table below. Mark: (1) the tab bar, (2) the Add User button, (3) the search field, (4) the per-row action icons.

# Control What it does When you’d use it
1 Tab bar — Users · Groups · Roles · Policies Switches between the four registries Depends on the job; see the order below
2 Add button Opens the creation dialog for the current tab Adding a user, group, role, or policy
3 Search field Filters the current table Any install with more than a screenful
4 Row action icons Edit and delete for that row Changing or removing one entry

Walkthroughs

The four tabs are used in a fixed order when setting up access from scratch, because each one consumes what the previous produced:

  1. Policies — define what a set of permissions is, and which clusters and environments it applies to.
  2. Roles — bundle policies into a job title.
  3. Users — create the person and give them the role.
  4. Groups — organise people for ownership and visibility.

Going the other way round is what produces “I created the user but they still can’t do anything”.

Scenario

Sarah joins as a backend developer. She must deploy to dev, but not to production.

This crosses every tab, which is why it is the scenario worth learning.

  1. Policies — create Dev Deploy. Add the deployment permissions, then scope the statement: select the dev cluster under resources, and set the environment condition to dev. Scoping is the whole point; an unscoped deployment policy grants production too.
  2. Roles — create Backend Developer and assign the Dev Deploy policy to it. Do not assign the admin role as a shortcut: admin bypasses policies entirely and grants everything, including clusters added later.
  3. Users — click Add User. Enter Sarah’s exact GitHub or Bitbucket username and the email on that account. Assign the Backend Developer role. Set her profile to Dev.
  4. Sarah signs in through GitHub. Fenwave creates her profile on first login — she does not register, and cannot edit her own account.
  5. Groups — add her to the Backend group so the team owns its components.
  6. Verify with Access Explorer: look up Sarah and confirm the dev deployment permission resolves as allowed and the production one does not.

Step 6 is not optional in practice. Scoping errors are silent — a too-broad policy looks identical to a correct one until someone deploys to production.

When it doesn’t work

Symptom Cause How to check Fix
User created, but they can do nothing A role was never assigned, or the role has no policies Access Explorer for that user Assign a role that carries at least one policy
User cannot sign in at all The email does not match their OAuth account Compare the user record to their GitHub/Bitbucket profile Correct the email; it must match exactly
Permission granted but the menu has not changed Permission results are cached for the session Ask the user to reload Reload the page
A user can reach production although the policy says dev The statement was left unscoped Open the policy and check its resources and conditions Add the cluster resource and the environment condition
A tab is missing You lack that tab’s read permission Access Explorer for yourself Ask for a role granting it

Next