Authorization and attribution

What this page covers

An authorization can come from a direct grant, a group, a node subtree, or a temporary ticket produced by an approval. When an auditor asks why a person can reach a machine, the answer has to name the source. This page covers how authorizations are maintained and how the two directions of the trail are used.

How to set it up

The Asset Authorization page has three tabs: authorization records, subject view, and object view.

Authorization records

The list columns are the subject, the target, the source and validity, and the account scope. A subject is a person or a group, and a target is an asset or a node. An authorization can carry a validity window.

Filters cover users, user groups, assets, and nodes, along with quick filters for valid and expired. Filtering by node covers every authorization that intersects that node’s subtree, so grants on an ancestor node, grants inside the subtree, and grants bridged in through multiple memberships all appear.

The account scope is all accounts by default, and it can name specific accounts on the asset instead.

An authorization produced by a temporary ticket is marked “temporary” with its expiry, and revoking it goes through the request revocation flow. The reason is required, and the interface explains that revocation invalidates the ticket at once and blocks new connections, and that whether connections in progress are cut depends on the “revocation cuts the connection” setting.

The three validity states

The server computes the state and returns it, and the interface derives none of it:

• Not in effect: the start time has not arrived, and the row is grayed out and marked as such.
• Valid: inside the window.
• Expired: the row is grayed out and marked expired. An expired ticket is kept read-only as audit evidence.

Expiry times are color-coded by the days remaining.

Attribution

Subject view

Pick a person and see which assets they can actually reach, and the source of each one. There are six sources: a direct grant, through a group, through a node and its subtree, the intersection of a group and a node, view rights that come with an approver scope, and rights implied by a role. Each entry names its path, for example “through the group Operations” or “through the node prod / kafka (subtree included)”.

For an account with the administrator role, a banner at the top explains that the role implies every asset and that the table below lists explicit grants only; for the auditor role the banner explains that view rights over every asset are implied, while connecting still needs an explicit grant.

Object view

Pick an asset and see who can reach it. What roles imply is summarized in one sentence rather than listed person by person.

The runtime semantics are: an administrator automatically holds every permission, connection included; the auditor role automatically holds view; and connecting needs an explicit grant.

What auditors can see

• Creating, changing, and deleting an authorization all leave records.
• A temporary authorization tied to a request cannot be deleted directly, and the request revocation flow is the only way to revoke it, so a revocation always carries a reason and an operator.
• Deleted groups, users, nodes, and assets are marked as such in the list, so a historical record stays readable after the entity is gone.
• Expired tickets stay under the expired filter as evidence of who held which permission at the time.