Permission groups

A personal binding maps one person to one Kubernetes identity; you still write the RBAC itself by hand, in the cluster. A permission group instead defines a pre-selected set of Kubernetes capabilities (reading Secrets, exec/shell, redeploy, creating/deleting workloads, node operations…), scopes it to one or more namespaces, and generates real RBAC objects in the cluster with the "Create RBAC" button in the UI. People assigned to the group are authorized through that RBAC.

The permission decision itself always stays in the cluster — a group is a shortcut, not a second source of authority that replaces RBAC (see Limits).

Capabilities

Capabilities are grouped by family: Visibility, Code execution, Workload and configuration, Node and cluster. Any capability in the code-execution family (shell access, an ephemeral debug container, running a Job/CronJob, editing or creating a workload) puts the group in a class that cannot be narrowed further: a group that can run code can already read everything that code can read. Logs are not a separate capability — the single read baseline is Kubernetes's view aggregation, and it includes the log stream.

Scope

One or more namespaces, or "All namespaces". Cluster-scoped objects (nodes, PersistentVolumes, CustomResourceDefinitions, namespaces themselves) fall outside namespace scope: when selected, they are granted through a separate cluster-wide binding even in selected-namespace mode. System namespaces (kube-system and similar) can never be added to scope.

Members

Add a YEKE user or a directory group. A member gains the group's access only once the group has been applied to a cluster — membership has no effect before that. If a user with the admin role is added to a group, their admin access is NOT narrowed by it; the screen warns about this separately.

Cluster status

Measuring the actual state in the cluster and the "Create / update RBAC" button are owner-only — the group definition and membership are open to every admin, but applying it to a cluster is not. This tab shows applied/pending/drift/error state and, if present, drift (the difference between the requested RBAC and what's measured in the cluster).

Saving is not applying to the cluster. Saving a change on the Capabilities or Scope tab moves the screen to Cluster status automatically and shows a warning that doesn't dismiss itself: if a cluster is in scope, "Saved, but not applied to the cluster yet — the cluster still enforces the old permissions. Update the RBAC."; if the group isn't in force anywhere yet, "Saved. The group isn't in force on any cluster yet — permissions take effect once the RBAC is applied." Only the owner can apply the RBAC; if you aren't the owner the warning still shows.

• One subject. The group exists in the cluster as a Group subject named yeke:g:<slug>.
• A main role plus extra roles. A main role for yeke:g:<slug> (Kubernetes's view aggregation plus the selected extra rules); cluster-scoped rules go to a third role, and that role is ALWAYS bound with a ClusterRoleBinding — independent of the namespace-scoped rules that remain.
• A binding per namespace. In selected-namespace mode, each namespace gets its own RoleBinding; in "All namespaces" mode, a single ClusterRoleBinding is enough.
• A second subject if the Secret-keys capability is selected. The cluster also gets yeke:gs:<slug> and a single-rule role bound to it; this subject is only impersonated on YEKE's own Secret screen, only for that one request (below).
• Writes still go through the ONE path. Dry-run → approval card → apply — under the administrator's OWN identity. The agent's ServiceAccount never gains RBAC-write access through this path.

Enterprise — secret-keys (E6, "Access and Secret management"). This capability shipped flagless, i.e. free, up to 0.58.0. From this release, ADDING it to a group and building an RBAC plan (create/update) for a group that carries it require a license; REMOVING it and tearing down the group's RBAC do not. The foundation of permission groups — definition, membership, templates, namespace scope, RBAC generation — stays Community.

Even when a group carries the Secret-keys capability, its main subject (yeke:g:<slug>) gets no Secret RBAC rule at all in the cluster. The rule goes to a second subject (yeke:gs:<slug>), and that subject is impersonated only for requests on YEKE's Secret screen, only for the duration of that request. On the cluster's general paths (the resource browser, the browser shell, watch/monitoring, AI tools) the same user still gets a 403 for Secrets.

The rules are written on the Access tab: for every Secret within the group's namespace scope it draws a key × group matrix, and each cell is marked individually:

The matrix's "All keys" row sets every key currently listed for that group to one level in a single step — this is not a wildcard: a key added later still starts "Hidden", and the "All keys" row has to be saved again to cover it.

Group-level wildcards: Secret rules

A real wildcard lives NOT in the matrix but in the Scope tab's cluster card, under "Secret rules" — the rule is per cluster and only effective within that cluster's scope. The namespace, Secret name and key fields accept *, but only as a SUFFIX: when namespace is "All namespaces" the Secret and key fields close too; when Secret is "all Secrets" the key field closes. The "Every Secret in scope:" preset sets the group's default level in one row.

Priority is key > Secret > namespace > group default — inside a group the most specific rule wins, regardless of level: even if the group default is "Can edit", a "Hidden" rule written on a single key closes that key. Across groups the widest level wins — if a member belongs to more than one group, one group's "Hidden" cannot take back another group's "Can view". "Hidden" can now be written explicitly, only to narrow a wildcard. Writing a wildcard to a namespace outside the scope is rejected.

When a member opens a Secret they have a rule for, YEKE's Data tab shows a key–value table: keys marked "Can view" or "Can edit" open their value per row with Show/Copy, and a key marked "Hidden" shows only its fingerprint. Changing a key marked "Can edit" still goes through a "New value" field that creates a plan and passes through the approval card — the member never writes to the cluster directly.

These levels apply TOGETHER with the install-wide Secret display ceiling (YEKE_SECRET_DISPLAY), not instead of it: effective visibility is the stricter of the two — even a key marked "Can view" in this group stays masked while the ceiling is masked/hidden, and the Data tab draws no Show/Copy. The same boundary applies when restoring from Secret versions: restoring with "Can edit" access can only change a key that already EXISTS.

Inherited cells in the access matrix

When a key has no rule of its own for this Secret, the matrix cell shows the most specific wildcard that falls to it from the group's Secret rules with a dashed border — the cell is NOT selected, it only states which level currently applies. The inherited source can be a Secret rule, a namespace rule or the group default; in a group with no wildcard the cell stays empty and the key starts "Hidden". Picking a level in a dashed cell writes a SEPARATE rule specific to that key — it does not change the inheritance chain.

• RBAC doesn't add restrictions — it only grants. Permission groups are not a new restriction layer on the cluster; everything they grant is a real RBAC object subject to the cluster's own decision — disabling a group doesn't create a second prohibition that revokes something the apiserver already allows elsewhere.
• The admin role cannot be narrowed by group membership. Like a personal binding, admin sits outside the permission-group axis entirely.
• Redeploying and changing the image cannot be separated in RBAC. The workload-edit capability grants both through the same write rule; one cannot be enabled without the other.
• In a group that can execute code, hiding keys is not a boundary. If the group carries shell access, an ephemeral debug container, running a Job/CronJob, or editing or creating a workload, code running inside the pod can already read every Secret attached to it — the screen shows this combination as an unavoidable warning, it doesn't refuse to save the rule.