Access requests¶

In Pro, people ask kubelatch for a role on a cluster or a namespace, for a while, with a reason and a ticket: from Home, from the link a cluster's 403 carries, or with kubelatch request. An administrator approves or denies each request on its own page, and the permission that results ends on its own. An environment can also grant some roles without approval. This page is for the people who decide and for the administrators who set up the environments; how people ask is in Ask for access.

Before you start¶

• The edition is Pro (Editions and license). In Free, nobody files a request.
• You're a kubelatch administrator. Every enabled administrator decides the requests of everyone else; nobody decides their own.

What can be asked for¶

An enabled person asks for a role on a registered cluster, on the whole cluster or in one namespace. Bots don't ask: they have no session. AI agents keep their own requests (AI agents). A request names one of these:

• one of the six system roles;
• a custom role the cluster takes: bootstrap v2, and the cluster among the role's clusters (Manage roles);
• a native role of that cluster.

The role and the place follow the rules of any permission (The rules): cluster-admin and native roles go on the whole cluster only, and a role made for namespaces goes in a namespace. A protected namespace, such as kube-system, can't be asked for. kubelatch doesn't check that the namespace exists when the request is filed, so it never tells someone without access what the cluster holds: the approval checks it.

How long¶

The time counts from the approval. A request asks for 15 minutes at least, and at most the smallest of:

• the maximum lifetime of the cluster's environment (Rules);
• the role's own maximum: cluster-admin lasts 8 hours at most;
• 30 days.

A request never asks for a permission without an end: a permanent one is granted in Permissions. The form proposes the environment's default expiry, 8 hours at most, or 8 hours without one, within those limits.

A request waits 24 hours for a decision; then it expires and the person can ask again. A person has at most 20 requests waiting, and files at most 30 in an hour, cancelled ones included. The same request (same person, cluster, role and place) is never filed twice: while one waits, asking again opens it.

Where they reach you¶

• Access requests, under Agents in the sidebar, counts the requests waiting for your decision.
• The bell says it in one line, "2 requests wait for your decision.", with a link to Access requests.
• Each request sends you an e-mail at once, with its link, when e-mail is set up (Access requests (Pro)).
• A webhook with the event access_request.created takes each request to Slack, Teams or your receiver, and access_request.decided its outcome (The events).

The Access requests page¶

Access requests has three tabs, kept in the address (?tab=):

• Waiting for you: the requests you can decide, oldest first, with their count.
• Yours: the requests you filed, and what became of them.
• Decided: the requests decided in the last 30 days, by you and by everyone else.

Each row is one sentence, "dev asks for debugger in prod/shop for 2 h", with the reason in quotes under it, the ticket, how long ago it was asked and when it expires, and Open. A row marks an Extension, with the end the permission has now, and a request that An administrator decides it. A decided row shows its status and who decided it, or "its environment's rule". Someone who decides nothing sees only their own requests, with no tabs.

Decide a request¶

Open the request from its row, its e-mail, the bell or the webhook's message. Its page, /requests/<id>, has:

• The request as its title, its status, how long ago and from where it was asked ("from a 403: create pods/exec", "from the CLI", "from the web") and when it expires.
• The request: Who, Role with what it does, Where, For, Reason, Ticket (a link when your kubelatch links tickets), Asked, Who decides, and Already holds here, the permissions the person has on that cluster and where each comes from.
• Your decision: For, the duration asked or a shorter one, and Note for dev, which the person reads with the decision, in the bell and by e-mail.
• Deny and Approve 2 h, under the decision. On a phone they stay at the foot of the screen.

An approval can shorten the request, never lengthen it. If the environment's maximum went down since the request, the page offers what fits now and says so: "It asked for 8 h; at most 1 h fits now."

Approve grants the permission with every check of a permission granted in Permissions: the namespace exists and enforces the Pod Security level the role needs, the cluster can name the person, and a role the cluster makes privileged lasts 8 hours at most (The rules). When a check fails, the page shows why and the request keeps waiting. The permission carries the request's reason and ticket, names you as the one who granted it, links to the request and ends on its own (Expiry and revocation).

Deny closes the request with your note. The person can ask again.

If someone else decided the request first, or it expired or was cancelled while you read it, the page says "This request is no longer waiting for a decision." and shows how it stands.

Deciding needs the browser: kubelatch request asks, waits, reads and cancels, but never approves or denies.

Decide several at once¶

On Waiting for you, each request you can decide has a box. Tick some and a bar appears with Approve N and Deny N, at most 50 at a time. A request only an administrator decides has no box for you.

Each button opens one confirmation that lists the requests. It takes an optional Note for the people who asked, which each of them reads with the decision. Approve grants each request for the time it asks, with the same checks as one approval; the batch is all or nothing, so if one request can't be approved (someone decided it first, or the cluster refuses it), none is, the page names that request and the boxes stay ticked. Deny closes them all or none.

In the audit log the batch reads as one line, "ana approved 3 access requests", with the permissions it granted counted as derived changes.

Extensions¶

A request for a role and a place the person already holds through a direct permission of their own asks to extend it: its row and its page say Extension, and For says how far it takes the permission. The approval moves that permission's end, within the environment's maximum; if the permission ended meanwhile, it grants a new one from the approval. A permission that comes from a group or a set isn't extended: the request grants a direct one.

When nobody else can decide¶

Nobody decides their own request. When the only administrator asks and no one else owns the place, the request isn't filed: the form says "Nobody else can decide it." and leads to Permissions, where an administrator grants the permission as always. A request only an administrator decides isn't filed either when the only administrator asks for it, whoever owns the place.

Requests only an administrator decides¶

Some requests are marked An administrator decides it: cluster-admin, a native role, or a role that the live read of the cluster's RBAC says is privileged for that person and place. When the cluster can't be read, the request is marked too: it fails towards the safe side. An owner of the place can't decide it, and it's never granted without approval.

Without approval (Pro)¶

An environment can grant some roles without approval: a request for one of them, on its clusters, is granted as it's filed, with every check of a permission.

1. On the environment's page, click Change rules in the Rules card.
2. Under Without approval, tick the roles. System roles lists every system role but cluster-admin, with the line "An administrator always decides cluster-admin."; Custom roles lists the custom roles. Native roles are never offered.
3. Click Save.

The Rules card then says them under Without approval, such as viewer, developer, or None.

What happens to a request for one of those roles:

• When every check passes, the permission is granted at once, and the request reads "Granted without approval by its environment's rule".
• When a check fails (the namespace doesn't exist, it lacks Pod Security, the cluster can't name the person), no request is filed: the person gets the error, as in the Permissions form.
• When the role is privileged for that person and place, or the cluster can't be read, the request is filed and waits for an administrator.

A role that isn't ticked always needs approval, so a new custom role needs approval until someone ticks it. A deleted custom role stays ticked, marked "(deleted)", until you untick it.

Owners (Pro)¶

An administrator can name owners: people, or kubelatch groups, who manage a place without being administrators. An owner is an enabled person (a bot never owns), and a group counts for the members it has in force.

Administrators keep everything else: accounts, roles, clusters, environments, credentials and the naming of owners.

Name an owner¶

Each of these pages has an Owners card: a cluster's page in the Access tab, an environment's page after its Permissions card, and a group's page before Details.

1. Click Add owner.
2. Under Who, choose A person or A group. A group can't own itself.
3. On a cluster, under Where, choose The whole cluster or One namespace and type the namespace; the cluster's namespaces are offered as you type.
4. Click Add owner.

The card lists each owner with the place it covers. On a cluster it also shows the owners of its environment, marked "inherited from prod": remove those from the environment's page. A group that owns something is marked on its own page: only an administrator changes its members.

To remove an owner, open the row's menu, click Remove owner and confirm. The owner stops acting at once; the permissions they granted stay.

Naming an owner is part of Pro. In Free, or with a lapsed key, the cards show the owners already named and let you remove them, but Add owner gives way to See Pro, and owners don't act until the edition is Pro again.

Who decides¶

A request asks the owners of its place, the most specific that has any: the namespace's owners, else the cluster's, else its environment's. Its page, the form and kubelatch request name them with their place, "luis, carmen (owners of prod/shop) or an administrator", up to 50 and how many more. With no owner other than the person who asks, the administrators decide, as without owners.

Every owner of the place decides, not only those named: the owner of prod also decides a request in prod/shop, and finds it in Waiting for you. An administrator decides every request.

The e-mail of a new request goes to the people it names. Before each e-mail goes out, kubelatch checks that its recipient still decides the request: someone whose ownership ended, or whose membership of the owner group ended, doesn't get it.

Only an administrator decides a request marked An administrator decides it: an owner sees it in the list but can't approve or deny it. When an owner approves a permission the cluster has made privileged since the request was filed, the approval is refused with 403 access_request.admin_only, the request gets the mark and the administrators get its e-mail.

What an owner sees¶

An owner who isn't an administrator gets Access requests in the sidebar and a What you manage group with Permissions and Groups: the same pages and actions, showing only their places and groups. To choose whom to grant or add, an owner sees the enabled people, by login and name only, the groups, and the namespaces of each cluster they own whole. A request's page lists what the person already holds in what the owner manages, and nothing of the rest of the cluster. Their Grant form follows the rules of each cluster's environment, as an administrator's does: it proposes the default expiry, stops at the maximum and asks for the reason or the ticket the environment requires. Users, Roles, Credentials and Audit stay with administrators.

In the audit log¶

The control log has a sentence for every step, with the request as the target, which links to its page (The control plane):

• "ana" asked for debugger in shop on prod for 2 h, or asked to extend … by 1 h;
• Request of "ana" approved: debugger in shop on prod, until …, or, with no person, Request of "ana" granted by the rule of staging: …;
• Request of "ana" denied: …, "ana" cancelled their request: …, Request of "ana" expired undecided: …, and Request of "ana" cancelled when the account was disabled: ….

The permission's own grant.create reads "granted to "ana" by the rule of staging" when an environment granted it: the person who asked is its actor, but nobody decided it.

In Free and with a lapsed key¶

In Free, filing a request answers 403 edition.feature (Errors). Access requests stays in the sidebar for administrators, with Pro, and its page explains the feature with See Pro. Ticking a role under Without approval needs Pro.

With a lapsed key nobody files a new request and nothing is granted without approval, but the requests already waiting are still decided by the administrators: Access requests keeps their list and their count while there are any. Unticking a role under Without approval never needs Pro: in Free, Change rules stays while one is ticked.

Via the API¶

/api/access-requests lists, reads, files, approves, denies and cancels requests, and PATCH /api/environments/{id} takes auto_approve_roles (HTTP API).