Roles, policies and teams

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 Check access 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 IAM in the sidebar. Teams, Roles, Policies and Check access are tabs next to People.

How Zaysa decides

For every action, Zaysa asks these questions in this order. The first one that answers decides.

1. 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.
2. Is it denied? A Deny in any policy, role, team or exception wins over every Allow.
3. 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.
4. Is it allowed? Their base role, a role or policy given to them or to one of their teams, or an exception.
5. Otherwise the answer is no.

The ready-made roles

The Roles tab lists every role, how many people have it and what it may do. Click the arrow next to 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.

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.

1. 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.

2. 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.

   

3. 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.

On-prem sites and VMs

On-prem access uses the same policies. A resource name starts with zrn:onprem:. Use a site ID for one site, or add :vm/, :network/, :cluster/, or :image/ and an ID for one resource. Policy patterns may use * for any characters and ? for one character.

Example policies

Replace the IDs below with resource names copied from your site, VM, network or image page. A site team can view one site: {"effect":"Allow","actions":["privateCloud:View"],"resources":["zrn:onprem:SITE_ID"]}.

For power only, use {"effect":"Allow","actions":["privateCloud:StartVm","privateCloud:StopVm"],"resources":["zrn:onprem:SITE_ID:vm/*"]}.

For team ownership, add {"resourceTag":{"team":["web"]},"requestTag":{"team":["web"]},"tagKeys":["team"]} as the conditions on a privateCloud:TagResource Allow. Resource tags describe the current VM; request tags describe the proposed change. A Deny with matching tag conditions still wins.

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 People tab, 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 Check access 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:

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.

Next steps