Grant permissions¶

A permission gives a person or a bot a role on a cluster, over a namespace or over the whole cluster. The role is one of the six system roles, the tiers, or a custom role. A permission is granted directly, here, or through a group, which gives the same permissions to all its members. Here's how to grant and revoke permissions in Permissions, how to read the page, and what rules kubelatch applies.

What each tier does and why these rules exist is in System roles and Security model; custom roles are in Roles and Manage roles.

Before you start¶

• The subject exists and is enabled (Users and bots).
• The cluster is registered and enrolled: it reads Ready or Error, not Not enrolled (Register a cluster).
• For developer, debugger, admin or a custom role that requires Pod Security, the namespace has the pod-security.kubernetes.io/enforce label set to baseline or restricted.
• For a custom role, the cluster has the current bootstrap manifest (Update the bootstrap).

Grant a permission¶

The form grants one role to several accounts on several clusters, each with its scopes, in one go: one permission per account, cluster and scope, all granted or none.

1. Open Permissions and click Grant permissions. The form opens in a panel on the right, in three groups: Who and where, What and Until when.

2. Fill in the form:

   Field	What to put
   Accounts	One or more people or bots, picked in the Add an account… selector. Each shows as a chip you can remove. Disabled accounts don't show up.
   Where	Specific clusters, the default, or, in Pro, An environment or A label: the permission then follows every cluster of that environment or with that label (Permissions on a set). In Free, the last two carry Pro and See Pro.
   Clusters	With Specific clusters: one or more enrolled clusters, picked in the Add a cluster… selector; one that is Not enrolled doesn't show up.
   Scopes	Under each chosen cluster, one checkbox per namespace, with its PSA level; tick as many as you need. First comes whole cluster (*) when the role can take it, and it goes alone in its cluster: ticking it clears and locks that cluster's namespaces. A role granted only to a whole cluster, like cluster-admin, shows Scope with whole cluster (*) and no checkbox. Protected namespaces don't show up.
   What	The role, each with its description under it: first System roles (viewer, developer, debugger, secrets-reader, admin, cluster-admin), then Custom roles, then Native roles, each with the cluster groups it sends. A custom role the cluster can't take is disabled and says why (Grant a custom role); a native role is explained in Grant a native role.
   Until when	8 h, 7 days, 30 days, 90 days, Date… or Never, limited to what the chosen role allows. 30 days is the default; Date… shows the Expires field; Never only shows for a role with no maximum (all but cluster-admin). For a person on a cluster whose environment has rules, the choices stop at its maximum, with no Never, and the default is the environment's: its length, or Default for prod (2 h) when no length matches.
   Reason	Why the permission is granted. The person and the audit log see it. It goes on every permission of the batch.
   Ticket	The ticket behind it: an https:// link, a key such as INC-123, or a number such as #512. A key is stored in capitals. With KUBELATCH_TICKET_URL set, the field shows the link a key or a number will be: Will link to … (The reason and the ticket).

3. Click Grant N permissions. The panel closes, the notice says Granted N permissions., and the permissions show up on the map and in List, under Active.

A link can open the panel with part of the form already filled in. Grant permissions, in the Access card of an account's page, chooses the account under Accounts (Users and bots); Grant, in the Access card of a cluster's page (for the whole cluster, or beside one scope) and on each row of its Namespaces card, chooses the cluster and the namespace; ticking several namespaces in that card and choosing Grant in N namespaces chooses them all. What the form wouldn't offer, a disabled account or a cluster that is Not enrolled or no longer exists, is left empty for you to choose.

As soon as the accounts, the clusters, the scopes, the role and a valid expiry are set, a line counts what will be granted, accounts times scopes, for example "4 permissions: developer on apps, web in kind to alice, bob, until …". With several clusters it says what multiplies: "6 permissions (2 accounts × 3 scopes in 2 clusters): …". Under it, admin, cluster-admin and Never each get a warning about what that grant lets someone do.

A permission that already exists, active and direct, for the same account, role and scope, is left out of the count and named: "alice on apps: already granted, so 3 are granted." If they all exist, the line reads Every one of these permissions already exists. and the button stays off. A permission the account has through a group doesn't count as existing: the direct one is granted, and the line of one of the two says it's redundant (Overlaps).

Choosing a role changes the scopes when it has to (cluster-admin sets whole cluster (*); a namespace-only role clears it), and says so under them. Removing a cluster drops its scopes.

The rules of an environment apply as soon as a person is among the accounts. When they leave out the expiry you chose, the form sets the one they propose and says so: Expiry changed to 8 h by the rules of prod. With clusters of several environments, the shortest maximum and the shortest default apply. A date past the maximum keeps the button off, with prod allows a person's permission to last at most 8 h.

The form warns before submitting if something doesn't add up, for example a namespace without PSA. The server applies the same rules to every entry, at most 200 per batch: over that, the button stays off and a line says At most 200 permissions at a time: choose fewer accounts, scopes or clusters. If one is refused, nothing is granted: the panel shows the reason, and a line under the summary names the entry, for example Refused at bob on web in kind. It goes away as soon as you change the form.

The reason and the ticket are optional unless the clusters' environment requires them for people and groups. Then the field says where (Reason · required in prod), and Grant stays off with what is missing under it: prod asks for a reason., then prod asks for a ticket: a link, or a key such as INC-123. Free text is not a ticket there. A bot is asked for neither.

Under the summary, The same set for more people? Create it as a group opens Groups with its creation panel: a group keeps these permissions in step for whoever joins it later.

Each grant reconciles the cluster right away: within a second or two the binding exists and the person can use it. If the cluster is in Error, see Troubleshooting.

Each permission translates into a group the proxy impersonates, for example kubelatch:ns:apps:viewer, or kubelatch:ns:apps:role-<id> for a custom role. Click the role on the permission's line to see it, on any list, the person's Home included.

The rules¶

To work in a protected namespace, use the cluster's native administrator access: Accounts and recovery.

Two more warnings:

• viewer on * sees nodes, PersistentVolumes, StorageClasses, CRDs and the pod logs of every namespace. Logs can contain secrets.
• With KUBELATCH_REQUIRE_PSA=false, the PSA check is turned off, and kubelatch warns about it at the top of Permissions and under Notices, the bell in the top bar. Only use this if something else (OPA, Kyverno) enforces the same thing: without PSA, anyone who can create pods can create a privileged one and take over the node.

Grant emergency access with cluster-admin¶

cluster-admin is the preferred route for an urgent intervention while kubelatch is working. It's audited: the control plane logs who granted it and to whom, and every request made with it is logged.

1. In Permissions, click Grant permissions, pick the person in Accounts, then the cluster and the cluster-admin tier. The scope switches to whole cluster (*).
2. 8 h is already selected; pick Date… instead for a shorter expiry.
3. Write the reason in Reason, the incident in Ticket, and click Grant 1 permission.
4. Revoke it as soon as the intervention is done.

cluster-admin is always a direct permission: a group can't give it (Groups).

Read a permission¶

Every list draws a permission as the same line: on the page of an account, a cluster, a group or a role, in My clusters on Home and in Permissions. A list leaves out what its page already fixes, such as the account on the account's page, and keeps the rest in this order:

When something stops a permission from counting, a second line under it says so: No effect or No access to and the cluster (Permissions without effect), a redundant permission (Overlaps), or Account disabled: the permission counts for nothing while it stays so. On a phone the line takes two rows: the role and its expiry, then the rest.

On an administrator's lists, the menu at the end of the line depends on the permission:

• A direct one: View details, Requests, Extend and Revoke. A disabled account's has no Extend.
• One from a group, say Backend: Open Backend, View details, Requests and Remove from Backend, which takes the account out of the group after a confirmation that lists everything it loses.
• One that a set puts on a cluster, in a list by cluster: View details, Requests and the three items of the permission on the set, below.
• An expired or revoked one: View details and Requests.

View details opens Permission detail: the Kubernetes group (for a native role, Cluster groups, one per line), Enters as while the permission is in force (the name the person carries inside the cluster, as its identity template renders it, or why it can't; a name shared with other accounts says so, because none of them gets in; a bot always enters as bot:<name>), the Source, the status (Active, Expired or Revoked on …), the Reason, the Ticket and Granted: by whom and when. For a permission from a group, Granted names the administrator whose change in the group created it.

Active direct permissions take a checkbox. Ticking the first one brings up a bar under the list with Select all (N), the count, Extend N and Revoke N (Revoke several permissions).

A permission on a set¶

A permission on a set is drawn differently in each kind of list:

• In the lists by account (List in Permissions, By account, an account's page and a group's page) it's one line and counts once. The lines form their own section, On a set, which goes first in a list with sections; in a flat list they sort by their end among the rest. The line says the role and the set (viewer on staging); under Where, the set, the scope and 3 of 4 clusters; under Until, its end; and under Why, follows the environment or follows the label, then the ticket and the reason.
• In the lists by cluster (By cluster, the map, a cluster's page, an environment's page and My clusters on Home) each cluster has a line of its own, and Why reads via staging, with the set in mono, where it would say direct or the group. Source, in Permission detail, says the same.

Click Where on the line of a set to unfold one line per cluster of the set: its end where the cluster holds the permission, and No effect: with the reason where it doesn't. While kubelatch hasn't decided some clusters yet, No effect yet on 1 cluster. goes under the line.

The line has one menu, which acts on the whole permission: Extend the permission on staging, Check again and Revoke the permission on staging. A disabled account's line keeps only Revoke. A line on a set takes no checkbox.

The reason and the ticket¶

The field the forms called Note is now Reason; the API keeps calling it note. Beside it, Ticket links the permission to the team's tracker. kubelatch recognises three forms:

KUBELATCH_TICKET_URL is the tracker's template, such as https://acme.atlassian.net/browse/{key} (Configuration). Without it, a key or a number shows as text. Anything else, up to 200 characters, is kept as typed and never becomes a link; only https:// links ever do. kubelatch doesn't check that the ticket exists in the tracker.

The ticket shows on the permission's line, in Permission detail, in My clusters on Home, and in Activity beside each request the permission let through (Activity). Extending or revoking a permission never asks for it again.

Revoke a permission¶

1. In Permissions, find the permission: select its account in By account or its cluster in By cluster, click the account's cell on the map, or search for it in List. The account's and the cluster's pages list it too.
2. Open the menu at the end of its line, choose Revoke and confirm.

Revoking reconciles the cluster: the binding and the group disappear within seconds. The person's credentials still work for the rest of their permissions. If they're left with no permission on a cluster, the proxy responds 403 … has no active permissions on cluster ….

A permission that comes from a group has no Revoke: it changes in its group, by removing the member (Remove from Backend, in its line's menu, does it from here) or by revoking the group permission (Groups). Through the API, DELETE /api/grants/{id} on it answers 409 grant.derived, with the group in params.group_id.

A permission that a set puts on a cluster has no Revoke of its own either: revoke the permission on the set, from its line's menu, or take the cluster out of the set. DELETE /api/grants/{id} on it answers 409 grant.set_derived, with the set in params.selector and its id in params.set_grant_id.

A permission that expires stops counting on the proxy at that exact instant. Its binding is removed by the periodic pass (every 10 minutes) or a manual Reconcile.

Revoke several permissions¶

1. In Permissions, open List on Active and narrow it with the search, a chip or a link from another page; or select an account in By account or a cluster in By cluster, or open a cell's panel on the map.
2. Tick what to revoke: a line's checkbox, or Select all (N) in the bar that the first tick brings up under the list, which ticks everything the filter shows. Shift and a click tick every line between the last one you ticked and this one.
3. Choose Revoke N. The confirmation names the accounts that lose access and the clusters kubelatch reconciles, lists the permissions cluster by cluster and takes an optional reason, which stays in the control log.

A batch is all or nothing, up to 500 permissions. If one can't go, nothing changes: the alert names it, its row says why, and the marks stay so you can untick it and try again. A permission another administrator revoked meanwhile is not an error: the notice counts it as already revoked.

Only active direct permissions take a checkbox; a permission from a group is revoked in its group. The page of an account, a cluster or a role revokes several the same way. When the revoked permissions share one role and one cluster, and covered each of their accounts on each of their scopes, the notice offers Grant again, which opens the grant form with those accounts, scopes and role.

Each permission leaves its own grant.revoke row, and the control log shows the batch as one line (The control plane).

Extend permissions¶

To extend one permission, choose Extend in its row menu. To extend several, tick them as for revoking and choose Extend N in the bar. Then choose the new expiry:

• +7 d or +30 d adds that time to each permission's own date. A permission with no end date can't take it: choose a date.
• One date for all sets the same date on every one; the list marks Shortens on those it brings forward.
• Never removes the end date, offered only when every role allows it and no person's permission sits on an environment with a maximum.

On such an environment, a person's permission that the choice would take past the maximum is marked prod: at most 8 h, and the confirmation waits, with a line that gives the latest date it can take.

The confirmation lists each permission with its expiry before and after and takes an optional reason, which stays in the control log. A batch is all or nothing, up to 50 permissions, and refuses the permission of a disabled account. A privileged permission, such as cluster-admin, keeps its 8 hours counted from when it was granted: to go further, revoke it and grant it again (The rules).

Each permission leaves its own grant.expiry row, with the expiry before and after (The control plane).

A permission on a set is extended as a whole, from its line's menu, and the extension checks each of its clusters (Extend a permission on a set). Through the API, PATCH /api/grants/{id} on what a set put on a cluster answers 409 grant.set_derived.

Owners¶

In Pro, an administrator names the Owners of an environment, a cluster or a namespace of a cluster: people, or a group whose members count while their membership lasts. Without being administrators, the owners grant, extend and revoke the permissions of that place:

An owner never gives themselves access: granting to themselves, or lengthening their own permission, answers that an owner cannot give access to themselves. Only an administrator grants or lengthens cluster-admin, a native role, a permission the cluster makes privileged, or a bot's permission; and only an administrator shortens or revokes a cluster-admin or native role permission. An owner shortens and revokes every other permission of their place, a bot's or an administrator's included. The environment's rules apply to them as to an administrator.

Permissions on a set, accounts, roles, clusters and environments stay with the administrators, and so does naming owners. A write outside the place answers that it is outside what you manage. Each owner's change leaves its usual row in the control log, with as: owner and the scope that allowed it (The control plane). Without Pro the owners stop acting, and their rows stay.

Permissions without effect¶

When a cluster gives a name privileged access, a permission that gives that name for more than 8 hours, or any group permission that gives it, breaks the 8-hour rule: the reconciliation leaves the name out, and everyone who enters the cluster with it loses access there. Every list marks both sides, under the permission's line:

• No effect on the permission that breaks the rule, with the reason, how many people it leaves without access, and See why, which opens the problem on the cluster's page.
• No access to and the cluster on the other permissions of those people there, with the permission that keeps them out, linked.

See them in Permissions, on the cluster's page, opens List with only the permissions without effect on that cluster (Showing only the permissions without effect., with Show all to go back). Tick them and revoke them at once; a permission from a group is fixed in its group. In every view, the N with problems chip shows both sides at once. Only administrators see these marks.

The views¶

Permissions shows the permissions in force in four views: By cluster, By account, Map and List. With more than 6 registered clusters, counting those not enrolled yet, it opens on By cluster; with 6 or fewer, on Map. The page's address keeps the view you choose, so a link opens it too.

• By cluster says who reaches a cluster, and until when.
• By account says everything an account reaches, and takes it all away in one step.
• Map shows accounts against clusters at a glance.
• List holds every permission, expired and revoked ones included.

The header counts what the page holds before the search and the chips narrow it, for example "577 permissions of 66 accounts in 42 clusters". Accounts with no permission in force are in Users.

Search and chips¶

The search finds logins, names, roles, clusters, namespaces, groups, reasons and tickets. Each chip keeps what its name says, and its count leaves out disabled accounts:

Click a chip again to lift it. While a chip or the search is on, a line says what matches, for example "57 permissions of 46 accounts on 23 clusters match the filter.", with Clear filters, which lifts the chips and empties the search without changing the view or what it has selected; a selection a filter hid comes back. List has no such line: its tabs count already.

Environment and Label, after the chips, keep every view to the permissions on the clusters of one environment or with one label (Filter Clusters and Permissions). Clear filters leaves them as they are: choose All environments or All labels to lift them.

What a filter does depends on the view:

• By cluster and By account list only the clusters or the accounts with a match, each saying how many match, and the detail shows only the lines that match.
• Map drops the clusters with no match, from the rest column too, and puts first the ones with the most. It keeps the rows with a cell that matches and dims the cells that don't.
• List keeps the lines that match. Pressing a chip opens Active, which is what the chips count.

A permission expires soon when it has 7 days or less left: its expiry turns amber, and red with under 24 hours left; the two expiry chips take the same colours. The sidebar marks Permissions with the same counts on every page: a red number for those under 24 hours and an amber one for the rest of the week. Click a number to open Permissions.

By cluster¶

By cluster lists the clusters on the left and, on the right, the permissions on the one you select.

The list says how many clusters it holds and orders them by Risk, A–Z or Accounts. Risk puts first the clusters in error, then those with the most permissions without effect, expiring today, expiring this week and with cluster-admin, in that order. Accounts puts first the clusters with the most accounts. Each cluster shows its provider, how many accounts have a permission there, and at most two pills: in error, "1 without effect", "3 today" or else "2 this week". A cluster not enrolled yet says not enrolled.

The detail opens with the cluster, a line such as "EKS · 29 accounts · 39 permissions", Cluster page and Grant on prod, which opens the grant form with the cluster chosen. Its permissions follow as on the cluster's page: Whole cluster first, then each namespace, the nearest expiry first, each line with its menu and its checkbox (Read a permission). Click a login to open By account on that account. A cluster with no permissions says "Nobody holds a permission on prod." and offers Grant on prod.

Under a filter, the detail ends with "4 more permissions on prod don't match the filter." and Show all; Show only the ones that match goes back to the filter.

The list is one Tab stop: the up and down arrows move through it and select as they go, and Home and End go to its ends. On a phone the list sits on top, and tapping a cluster takes you to its detail.

By account¶

By account works the same way over the accounts: the accounts with a permission in force on the left and, on the right, everything the one you select holds.

The list orders them by Risk, A–Z or Clusters. Risk puts first the accounts with the most permissions without effect, then those with the most expiring today and this week; A–Z puts the bots last; Clusters puts first the accounts on the most clusters. Each account shows "7 clusters · 12 permissions" and at most two pills: "1 without effect", "3 today" or else "2 this week". A disabled account says Disabled: its permissions are still there but count for nothing, so they carry no pill.

The detail opens with the account and its name, its groups as links ("Member of Backend and Security"), a line such as "25 clusters · 38 permissions: 3 direct and 35 via groups", and its actions: alice's page, Grant to alice (not on a disabled account) and Remove all permissions…, when there is something to remove. Its permissions follow by cluster, as on the account's page, and See who else has access, at the right of each cluster, opens By cluster on it. Filters work as in By cluster.

An account with nothing in force, reached by a link from its page, ⌘K or Audit, shows all the same, with no permissions and Grant to alice. A link that narrows the page to one cluster, such as the Accounts figure in Clusters (Links from other pages), limits By account to that cluster, under "Only on prod." with Show all their clusters.

Remove all permissions¶

Remove all permissions… takes away everything an account reaches in one confirmation: it revokes its direct permissions and takes it out of its groups. The account, its credentials and its sessions stay: from the next request it reaches no cluster. To offboard someone, disable the account on its page (Disable and enable).

1. In By account, select the account and click Remove all permissions….
2. The confirmation, Remove alice's permissions, has one box per step, all ticked: Revoke 3 direct permissions, with their clusters, and Remove from Backend for each group, with what the group gives the account; the other members don't change. Untick what should stay.
3. Write a reason if you want one: it goes with every step and stays in the control log. Click Remove N permissions.

The steps run one after another: the direct permissions first, then each permission on a set as a whole, then each group. The notice says what was done, for example "Removed alice's permissions: 3 revoked and out of Backend and Security.". If a step fails, the run stops there: the notice says what was done and the alert what failed. What was done stays done, so a failure always leaves less access, never more. A permission or a membership that ended meanwhile counts as done. Each revoked permission leaves its grant.revoke row, each permission on a set its set.grant.revoke and each group its group.member.remove, all with the reason, as when you do them one by one (The control plane).

The map¶

Map shows who has what, where: a row per account with a permission in force and a column per registered cluster, enrolled or not.

• Each column is a cluster: its id and how many accounts have a permission there, then "· 3 today" or "· 2 this week" when something there expires soon, or "· 57 match" under a filter. Click it to open By cluster on that cluster; the search and the chips stay.
• With By group, the rows fall into one band per group, by name: the group as a link, its members and what it gives, for example "gives developer on prod (shop, payments) and viewer on staging". Its members follow, and someone in two groups shows under both, the second time with "also in Backend". No group and Bots come last. A–Z drops the bands and lists everyone by login, the bots last. A disabled account's row is dimmed and says Disabled. Click an account to open By account on it.
• Each cell sums up an account on a cluster: its strongest role, with "+2" for its permissions of other roles there; where it holds that role (a namespace, two of them, "3 namespaces" or whole cluster); its nearest expiry; and the problem, if there is one: No effect, No access to and the cluster, or "1 redundant". A dot means no access. The strongest role is a sensitive one first, then the system roles in this order: cluster-admin, admin, debugger, secrets-reader, developer, viewer.

The map is one Tab stop, which starts on the first cell with access: the arrows move between cells and also reach the column headers, the accounts and the groups' links; Home and End go to the ends of a row (with Ctrl, of the map), Page Up and Page Down move ten rows, and Enter or Space opens a cell. On a phone each account is a card with one line per cluster it reaches.

Columns¶

The map draws the cluster columns that fit the width of the page, never fewer than two, and fits them again when the window changes width. When some don't fit, a last column, +36 clusters (the rest, by account), sums them up for each account: on how many clusters it holds each role, counting the strongest on each and the strongest role first, for example "developer on 3 · viewer on 12". Under a filter it adds "2 more clusters match". A dash means nothing in the rest; a cell with something opens By account on that account.

Columns chooses which clusters come first:

• Most at risk, the default: the clusters in error first, then those with the most permissions without effect, expiring today, expiring this week and with cluster-admin.
• Most accounts: the clusters with the most accounts first.
• Chosen…: starts from the columns on screen and brings Clusters to choose them. Every chosen cluster shows, even past the width, and the map then scrolls sideways. With none chosen, the map says Choose at least one cluster.

Clusters opens a list with a search by id or provider, All, None, how many are chosen ("3 of 42"), and Only beside each cluster, which keeps just that one.

A cell's panel¶

Click a cell to open that account's permissions on that cluster on the right, for example alice on prod with "4 permissions: 2 direct and 2 via Backend" ("via groups" when several groups give them). When the map shows one group, from that group's page, the panel lists only what the group gives. Each one is a line with its menu and its checkbox (Read a permission), so you extend, revoke or remove from a group right there. Grant on prod opens the grant form with the account and the cluster chosen, and alice's page opens the account. Closing the panel takes you back to the cell. The page's address holds the panel (?cell=), so a link opens it too.

The list¶

List shows every permission as a line, the nearest expiry first, in three tabs: Active, Expired and Revoked, each with its count. While the search holds text, each count reads how many match out of the total (2 of 40). A revoked permission says when and by whom. With more than 8 clusters, Clusters chooses which ones the list shows, as on the map.

A permission of a disabled account stays under Active, dimmed, with Account disabled: the permission counts for nothing while it stays so. under it. It applies nowhere, so the chips and the sidebar leave it out.

Links from other pages¶

Other pages open Permissions on an account, a cluster or a filter, in the view the link names or, if it names none, in the one the page opens on (The views). That view stays put while you filter or close a panel. A line above it says what a filter shows, with its button to lift it, for example Only what Backend gives with Clear filter.

Home¶

An administrator's Home is the day's briefing: what waits for you, what changed in the last 24 hours and how much stays exposed, on one laptop screen.

• The line under the title says how many clusters there are and how many are ready, how many accounts, and when the latest reconciliation ran. 2 installation recommendations links to the health list in Edition (The Edition page), and Nothing pending ends the line when there is nothing to do.
• Set up kubelatch lists four steps that tick themselves, until a cluster is enrolled and some permission is in force.
• Pending has one line per thing that waits for you, each with its way out: a cluster in error (View problems), the permissions that end today and who loses a cluster with them, an agent's approval and the people who ask to join through SSO (Review), the bots' credentials that expire today and the invitations that expire this week. More than three of a kind fold into one line, and past six, and N more shows the rest. With nothing pending, the card isn't shown.
• Last 24 h has the five latest entries of the control log, each with who made it, and Control plane opens the whole log (The control plane). Under them, Sensitive access counts the exec (and attach), Secret reads and port-forward of those 24 hours, allowed and denied. Each figure opens Audit with only those requests, and hovering over it says who made them. Once an environment is marked as production, the line reads Sensitive access in production and counts the clusters of those environments alone (with none marked, it counts every cluster); each figure then opens Audit with Production set in Environment, so it still matches the list it opens. Operations keeps counting every cluster.
• Trends has four figures over 30 days. Cluster operations, in its header, opens the Operations page, and each figure leads to its part of the page:
  • Short-lived credentials: the share of accounts that got in only with credentials that expire on their own, with a row each for People, Bots and Agents, split into Short-lived, Long-lived and Unused (Short-lived and long-lived). N long-lived still active opens them in Credentials.
  • Permissions that end on their own: the share of permissions in force with an end date and how it moved in 30 days, with links to those without expiry and to the accounts with cluster-admin.
  • Requests, 7 days: the total of the last seven days and the share denied, with a column per day.
  • Unused in 30 days: the permissions in force whose account made no request in their scope in 30 days, and the credentials nobody used. Review all N opens them in List (Revoke several permissions).

In Free, the four figures are there, and the two that need more than 24 hours of audit say what Pro adds instead of a number: Requests, 24 h shows the last 24 hours by the hour, with With Pro: 14 days of history, and Unused in 30 days says With Pro: permissions nobody uses in 30 days. If your audit retention keeps less than 30 days, Unused in 30 days says it can't measure them.

Under all this comes your own access, as anyone who works with the clusters sees it (See your access). Without permissions or credentials of your own, one line says administering kubelatch doesn't need them, with Grant yourself one.

Overlaps¶

A permission is redundant when another active permission of the same account, on the same cluster and scope, already gives everything it does:

• the other one's role is a system role that covers this one's: developer covers viewer, admin covers developer and viewer, cluster-admin covers admin, developer and viewer (Which tier covers which);
• or the other one has the same role and comes from a group or from a permission on a set, while this one is direct.

The redundant permission gets an amber line under its own, on every list: "developer (direct) already includes viewer: this permission is redundant", or "developer via Platform already includes viewer: this permission is redundant" when the covering one comes from the group Platform, or "developer via staging already includes viewer: this permission is redundant" when it comes from a permission on staging. The line is worked out over all of the account's permissions, so a search or a chip that leaves out the covering one doesn't hide it. On the map, the cell counts them: "1 redundant".

Nothing is revoked on its own. Revoke the redundant direct permission if it's no longer needed; one from a group is changed in its group. debugger and secrets-reader cover no other role: only the same role from a group or from a permission on a set makes them redundant. Custom roles never get the line, because a custom role doesn't say what it covers.

Add CRDs to a tier¶

A custom role with an advanced rule is the way to grant a CRD's resources to some people only. To add them to everyone holding a tier instead: the viewer, developer, debugger and secrets-reader tiers are aggregated ClusterRoles. To have them include a CRD's resources, create a small ClusterRole on the cluster with the label kubelatch.io/aggregate-to-<tier>: "true":

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: certificates-viewer
  labels:
    kubelatch.io/aggregate-to-viewer: "true"
rules:
  - apiGroups: ["cert-manager.io"]
    resources: ["certificates", "issuers"]
    verbs: ["get", "list", "watch"]

Anything you add to viewer also reaches developer, which contains it. admin and cluster-admin are Kubernetes' own roles and follow their own aggregation rules.

Check what someone can do¶

kubelatch doesn't support kubectl --as: the proxy rejects any Impersonate-* header from the client with a 400. To check what a subject can do, use the cluster's native administrator access with its user and group:

kubectl --kubeconfig <cluster-admin-kubeconfig> auth can-i create pods --subresource=exec -n apps \
  --as user:alice --as-group kubelatch:ns:apps:debugger

Bots show up as bot:<name>.