Team & account
Roles, policies and teams
Decide exactly what each person may do: ready-made roles, your own policies, teams, exceptions for one person, and a simulator to check.
About 7 minutes
A person's role (Owner, Admin, Member or Viewer) sets what they may do by default. When that is not exactly right, you add roles and policies on top, give them to a whole team at once, or make an exception for one person. Every page, every API key and the AI assistant are checked against the same rules, and the Simulator tells you the answer before anyone tries.
Before you start
- To change access you need Manage roles and policies. Owners and Admins have it. Everyone else can look at the roles and policies and check their own access.
- Open Team in the sidebar and click Roles & policies, or go straight to Team › Access.
How Zaysa decides
For every action, Zaysa asks these questions in this order. The first one that answers decides.
- Is it Owner-only? Paying for the plan, transferring ownership, deleting the organization and a few Beam controls belong to the Owner alone. Nobody can be given them.
- Is it denied? A Deny in any policy, role, team or exception wins over every Allow.
- Is the cloud account theirs? If a person is limited to some cloud accounts, they cannot see or act on any other, whatever else they hold.
- Is it allowed? Their base role, a role or policy given to them or to one of their teams, or an exception.
- Otherwise the answer is no.
Two rules that keep it safe
The ready-made roles
(1) The Roles tab lists every role, how many people have it and what it may do. (2) Click a role to see every action in it. Everyone can always see what is in the cloud accounts they have; the list shows what they may change.
| Role | What it may do |
|---|---|
| Owner | Everything, including the subscription, ownership and deleting the organization. |
| Admin | Everything except the Owner-only actions. Includes the actions that change real infrastructure: clean up waste, run and destroy deployments, auto-stop rules, remove clusters, approve Autopilot fixes. Beam targets, direct grants and revokes stay with the Owner unless the Owner gives them. |
| Member | Looks, runs cost scans, plans deployments and workspaces, and manages cost settings such as budgets, alerts and saved views. Cannot clean up, run or destroy anything. |
| Viewer | Looks only, and can request access through Beam. |
| Developer | Given on top of a role. Adds: run scans, plan deployments and workspaces, request access. QA is the same today. |
| FinOps | Given on top of a role. Adds: set budgets, manage commitments, cost categories and saved views, share waste reports. |
| Read-only | Given on top of a role. Adds: see the audit log and Autopilot. Changes nothing. |
Ready-made roles and policies are marked Zaysa. They cannot be changed; make your own instead.
Write a policy
A policy is a list of rows. Each row allows or denies some actions, on all cloud accounts or only some.
Describe what it allows
Click New policy. (1) Give it a name. (2) Choose Allow or Deny, clickChoose actions and tick the actions; type in the search box to find one. Actions marked changes real infrastructure create, change or delete things in your cloud. (3) Choose All accounts orPick accounts and tick them. (4) Tick Require 2FA if this should only work right after a two-factor sign-in.
Actions you may not give yourself are greyed out. A row can never be left without an account: to switch accounts, tick the new one before you untick the old one.
Or write it as JSON
The JSON tab shows the same policy as text. You can edit either one; switching tabs carries your changes across. Save is blocked while the JSON is not valid.
Create it
Click Create policy. A policy does nothing until you give it to someone, a team or a role. While it is in use it cannot be edited or deleted; remove it from everyone first, so nobody's access changes by surprise.
Bundle policies into a role
When several people need the same set, click New role, give it a name and tick the policies, yours or the Zaysa ones. Here a Release engineer gets the Developer rights plus running deployments on Google Cloud.
Give access to a team
On the Teams tab, click New team, name it and click Create team. Then open the team. (1)Attach roles and policies. (2) Add people. Everyone in the team gets everything attached to it, and somebody added later gets it too. To delete a team, detach its roles and policies first.
Change one person's access
On the Team page, click the person and then Edit access. Everything about them is in this one window; click Save accesswhen you are done.
- (1) Cloud accounts: tick the only accounts this person may see and act on, everywhere in Zaysa, including the AI assistant and their API keys. Tick none for all accounts.
- (2) Roles and policies: add or remove roles and policies for this person. Ones they get from a team are listed under Also from teams.
- (3) Exceptions: Allow or Deny rows for this person only. Here the person may not set budgets, although every Member may.
The base role itself is changed with the Role selector in the same panel. See Invite your team.
Check before anyone tries
On the Simulator tab, choose a person, an action and, for actions on a cloud account, which account. Click Check. The answer names what decided it. People who do not manage access can check themselves.
The same person on the AWS account is refused, because the policy only names Google Cloud:
| Answer | Meaning |
|---|---|
| Allowed | They may do it now. The role or policy that allows it is named. |
| Needs 2FA | They may do it right after signing in with two-factor (within the last 30 minutes). This is always the case for Owner-only actions. |
| Blocked, … denies this | A Deny decided it. Deny wins over every Allow. |
| Blocked, outside this person’s cloud accounts | The account is not one of theirs. |
| Blocked, no role or policy allows this | Nothing gives it to them. |
Deployments: who runs and who approves
Deployments belong to the organization, not to the person who made them.
- Plan deployments (Members and up): create a deployment and see its plan, logs and state.
- Run deployments (Admins by default): press Run on any deployment of the organization on an account they may use, including a teammate's.
- Every run stops after the plan and waits for approval. Someone else who may run deployments on that account approves it. The person who pressed Run cannot approve their own run, unless they are the only person in the organization.
- Destroy deployments (Admins by default) tears it down again.
Good to know
- API keys follow their creator. A key may only do what the person who made it may do today. Remove someone or take a right away, and their keys lose it at once.
- Every change is recorded. Creating, changing and deleting policies, roles and teams, and every change to someone's access, is stored with who made it.
- Accounts that are no longer active have no access. A blocked or deleted account is signed out everywhere and gets nothing from any page or API key.
If something goes wrong
- “For your security, please sign in again to confirm this action”: the action needs a fresh two-factor sign-in. Turn on two-factor sign-in in your account settings if it is off, sign out, sign in again and retry within 30 minutes.
- “In use by … remove it there first”: the role or policy is given to someone. Remove it from those people, teams and roles, then edit or delete it.
- An action is greyed out: you do not hold it yourself, so you cannot give it. Ask someone who has it.
- “You can't change your own access”: ask another person who manages access.