ReleasesBEBeta

Deckhouse Basic Edition

user-authz

moduleSubsystem: IAM ·Documentation
Changes on Beta
newest first · a suspension is a segment, a rollback is a step back
1.76.16·arrival time on the release channel unknown

That is the whole history

1.76.16

built into Deckhouse 1.76.16
Dates
released 01.10.2026 15:54 detected 05.10.2026 01:20
Requirements
  • autoK8sVersion 1.33
  • disabledModules delivery,l2-load-balancer,ceph-csi
  • ingressNginx 1.10
  • istioMinimalVersion 1.21
  • k8s 1.31
  • metallbHasStandardConfiguration true
  • migratedModules pod-reloader,runtime-audit-engine,dashboard
  • nodesMinimalLinuxKernelVersion 5.8.0
  • nodesMinimalOSVersionDebian 10
  • nodesMinimalOSVersionUbuntu 18.04
  • unmetCloudConditions true
Stage
General Availability · stage not recognised, shown as General Availability
On release channels
Beta — since unknown · Early Access — since unknown
Before
never
What changed in 1.76.16user-authz section of the platform changelog

Minor 1.76 starts at 1.76.14: 1.76.0, 1.76.1, 1.76.2, 1.76.3, 1.76.4, 1.76.5, 1.76.6, 1.76.7, 1.76.8, 1.76.9, 1.76.10, 1.76.11, 1.76.12, 1.76.13 are not in the registry

Fixes 3

  • user-authzGrant custom ClusterRoles (annotated with `user-authz.deckhouse.io/access-level`) through one aggregated ClusterRole per access level, so the number of bindings per ClusterAuthorizationRule/AuthorizationRule no longer depends on the number of such roles.#229681.76.14
    impactDuring the first `user-authz` release after the update the per-role bindings are protected from the release engine, the aggregated ones are created, and the per-role bindings are deleted right after the release. Permissions granted through annotated ClusterRoles stay in place throughout. The `user-authz.deckhouse.io/access-level` label is now set automatically on annotated ClusterRoles. In audit logs, access granted through annotated ClusterRoles is attributed to `user-authz:<level>:custom` instead of the individual ClusterRole.
  • user-authzGroup the module alerts under a group named apart from the alerts themselves, so the incident shelf accepts them.#229991.76.14
  • user-authzThe D8UserAuthzRenderSlow and D8UserAuthzReleaseSlow alerts no longer fire on a single slow render or release, such as a cluster bootstrap under CPU pressure or the one-time migration pass.#230021.76.14
    impactD8UserAuthzRenderSlow requires at least three renders averaging above 30 seconds over 30 minutes, D8UserAuthzReleaseSlow at least two releases averaging above 5 minutes over one hour, and both must hold for 15 minutes. Severities are one step lower (6 and 7). Their descriptions now point at CPU shortage on the node rather than at the number of ClusterAuthorizationRules, which does not affect render time.