Role assignments

Groups and domains describe how access is meant to be organized. Role assignments show what is actually in force. Every grant in CyberGuard is a row here: a role, the domains it covers, and the group or user it was given to. When somebody asks “why can this person see that audit?”, this is the page that answers it in one screen instead of three.

Where to find it

Organization → Role assignments in the sidebar.

Reading a row

Each row is one grant, expressed as a role, on a scope, to a principal:

Column	What it holds
User	Set when the grant was made directly to a person rather than through a group
User group	The group the grant was made to — the usual case
Role	Which of the built-in roles is being granted
Perimeter	The domains the grant covers

Exactly one of User and User group is filled on a given row. A populated User group is the normal path — a user joins the group, the group carries the grant. A populated User is a direct grant, which gives precisely what the row names and nothing ambient.

Most rows are created for you. Every domain provisioned with Create IAM groups produces one assignment per built-in group, and the five global groups produce theirs against the root domain. Those are the assignments you will see immediately after setting up an instance, before anyone has configured anything.

Grants also cascade: an assignment made on a parent domain reaches its sub-domains, which is why one row can explain access several levels down the tree.

What this page is for

It is a reading surface, not the place where access is changed. To grant or revoke, you add or remove people from the relevant user group, and the assignment follows automatically.

Three jobs it does well:

Access review. Filter by Domain and read down the list. Anything granting a broad role on a broad scope deserves a second look — particularly rows pointing at the root domain, which reach everything in the instance.

Troubleshooting over-access. Someone sees more than they should. Find every row whose perimeter includes the domain in question, check which groups they carry, and the surplus is almost always a membership in a group scoped higher up the tree than anyone intended.

Troubleshooting missing access. Someone cannot see what they need. If no row grants their group a role on that domain, the fix is a group membership rather than a permission change. Remember that a role held on a sibling domain grants nothing here — the tree only flows downward.

Tip

When you cannot work out why a user’s view looks the way it does, read it as a sentence: this role, on these domains, to this group. If none of the sentences covers the object they are looking at, they should not be able to see it — and if one does, that is your answer.

What is not listed

Assignments belonging to machine identities are kept out of this list, so it stays a picture of human access. Deactivated users are another quiet exception: their groups still appear here, but an inactive account cannot sign in and therefore exercises none of it. When you review access, check the account’s Is active flag on the Users page alongside the grants shown here.

Related

• User groups — where you actually change access.
• Users — the accounts these grants reach.
• Domains — the scope every assignment is measured against.