Add opt-in RBAC management UI via rbacManagement flag by dimitri-nicolo · Pull Request #4865 · tigera/operator

dimitri-nicolo · 2026-05-26T23:45:20Z

Description

Type: New feature (Calico Enterprise only). Addresses PMREQ-824.

Adds an opt-in RBAC management UI feature, toggled by a new Manager.spec.rbac.ui field (Enabled | Disabled, defaults to Disabled). When enabled, the operator renders the additional RBAC and network access the UI needs to let an administrator manage role/group assignments from the Manager: maintaining a catalog of managed ClusterRoles, binding IdP groups to roles via the rbacsync controller, and resolving groups from an external LDAP/AD directory.

This should be merged because it is the operator-side enablement for the RBAC management UI; without it the UI's backend has no RBAC or egress to function. Gating on spec.rbac.ui keeps the feature — and its escalation-capable permissions — entirely dormant on clusters that don't opt in.

What the flag turns on, by layer

API (api/v1/manager_types.go) — new RBAC spec struct with a UI RBACUI enum field and a nil-safe Manager.RBACManagementEnabled() helper (returns false for a nil Manager or any value other than Enabled). Regenerated deepcopy and the Manager CRD.
Render
- calico-manager role (pkg/render/manager.go): adds the cluster-scoped RBAC management UI rules (full CRUD on managed RBAC objects + escalation-prevention coverage for tier/resource roles), plus a namespaced Role+RoleBinding in calico-system that scopes the create/named-resource access to the IdP ConfigMap/Secrets (tigera-idp-groups, tigera-idp-ldap-config) instead of granting it cluster-wide. Sets RBAC_UI_ENABLED on the ui-apis container and opens LDAP/AD egress (389/636) when OIDC authentication is configured.
- calico-kube-controllers (pkg/render/kubecontrollers/kube-controllers.go): enables the rbacsync controller and its RBAC only when the flag is set (dormant otherwise), and adds a namespaced Role+RoleBinding granting rbacsync read on the tigera-idp-groups ConfigMap in calico-system.
- tigera-network-admin (pkg/render/apiserver.go): grants the bind/escalate-capable rule a network-admin needs to assign managed roles via the UI, also gated on the flag.
- Shared escalation-prevention rules live in a new pkg/render/rbac_management.go so the manager and kube-controllers roles stay aligned (the SA writing a managed role must already hold every permission it grants, or K8s rejects the write as privilege escalation).

Why the installation and apiserver controllers read the Manager CR

The flag conceptually belongs to the Manager, but two of the resources it gates are not rendered by the manager controller:

The rbacsync controller runs inside calico-kube-controllers, rendered by the installation controller.
The tigera-network-admin ClusterRole is rendered by the apiserver controller.

So each of those controllers reads the Manager CR itself and passes a RBACManagementEnabled bool into its render config. To support this, GetManager was moved out of the manager controller into pkg/controller/utils so the apiserver and installation controllers can reuse it without importing the manager controller package. Both callers treat a missing Manager as not-found (feature off) rather than an error, and the installation controller only reads it for the enterprise variant.

Both controllers also add a watch on the Manager CR. Without it, toggling spec.rbac.ui would not re-trigger an installation/apiserver reconcile, so the rbacsync controller and the network-admin rule wouldn't appear or disappear until some unrelated event re-ran those controllers.

Per-cluster behavior

The feature is keyed off each cluster's own Manager.spec.rbac.ui, so a management cluster and a managed cluster opt in independently. Calico Enterprise evaluates a user's managed-cluster actions against that managed cluster's own RBAC (Voltron proxies the request to the managed cluster's apiserver), so the network-admin bind/escalate grant and the manager-SA rules are intentionally rendered on managed clusters too — that is where a user managing per-cluster RBAC needs them. In multi-tenant management clusters the manager-side rules and namespaced Role are not rendered (gated on !MultiTenant()).

Testing: unit tests added for all three render surfaces (manager, apiserver, kube-controllers) covering the enabled/disabled gate and the multi-tenant exclusion; make gen-files produces no drift; go build ./... and the affected pkg/render* / pkg/controller/apiserver suites pass.

Components affected: apiserver (tigera-network-admin), manager (calico-manager role + namespaced Role + network policy), kube-controllers (rbacsync), Manager CRD, installation & apiserver controllers, pkg/controller/utils.

Release Note

Added an opt-in `Manager.spec.rbacManagement.enabled` flag that enables the RBAC management UI. When enabled, the operator grants the additional RBAC and LDAP egress the UI requires; it defaults to disabled and is supported in zero-tenant management clusters only. Disabling the flag does not remove RBAC objects already created while it was enabled.

For PR author

Tests for change.
If changing pkg/apis/, run make gen-files
If changing versions, run make gen-versions

For PR reviewers

A note for code reviewers - all pull requests must have the following:

Milestone set according to targeted release.
Appropriate labels:
- kind/bug if this is a bugfix.
- kind/enhancement if this is a a new feature.
- enterprise if this PR applies to Calico Enterprise only.

rene-dekker · 2026-05-27T23:07:07Z

+// that need a tenant-scoped Manager (the manager controller itself) must use
+// GetManager from pkg/controller/manager. Non-manager controllers reading
+// zero-tenant-only flags (e.g. spec.rbacManagement) belong here.
+func GetZeroTenantManagerOrNil(ctx context.Context, c client.Client) (*operatorv1.Manager, error) {


Can't we move the GetManager func from manager_controller to the utils package and re-use it? There is no reason that apiserver should throw an error if manager is not present. We should however only fetch it when enterprise CRDs exist and we are not running in cloud.

I see that you moved the func to here, but I also meant to delete this func entirely as well.

I think the code is more clear if we delete this method, remove any notion of "zero tenant" from the code including comments (it's not yargon that is used today) and use the multitenant booleans explicitly at the caller. I think that will be more understandable to the average reader.

rene-dekker · 2026-05-28T20:53:27Z

 	// +optional
 	ManagerDeployment *ManagerDeployment `json:"managerDeployment,omitempty"`
+
+	// RBAC configures the RBAC management UI feature. Only honored in


I don't think we should leak cloud (internal) implications into the API comments. Our users don't need to be aware/think about those.

rene-dekker · 2026-05-28T20:59:02Z

+	// Disabled.
+	// +optional
+	// +kubebuilder:validation:Enum=Enabled;Disabled
+	Mode RBACMode `json:"mode,omitempty"`


What do you think of the following field names?

Management: Enabled|Disabled

UI: Enabled|Disabled

or values: Visible | Hidden

rene-dekker · 2026-05-28T23:44:59Z

+
+		// RBAC management UI: when enabled on the Manager CR, the rbacsync
+		// controller runs inside calico-kube-controllers to reconcile the
+		// catalog of managed ClusterRoles (per-tier + 32 fine-grained + 6


nit: This number is not likely to hold up over time, best to keep the comment succinct.

rene-dekker · 2026-05-28T23:50:17Z

General comment: the AI generated comments in this code are a bit excessive. An extreme example may be the permissions. The func explains in comments twice which permissions are added + the code to add them. They are making the code less readable. And now we need to also keep the comments up to date when we add more. The operator code is not super complicated, I'd much rather have comments be only used if it adds critical information you couldn't get from simply reading the code (or have your ai read it for you).

rene-dekker · 2026-05-28T23:55:45Z

+		},
+		// Escalation coverage for webhook-mod resource roles (create/patch on
+		// Secrets to wire up webhook auth).
+		rbacv1.PolicyRule{


Could we be more specific with secrets and configmaps and bind them to the namespaces we actually need?

The named-resource access moved to a new Role + RoleBinding in calico-system, where tigera-idp-groups and tigera-idp-ldap-config actually live. The broad create is bound to that one namespace now.

Dropped the tigera-known-oidc-users rule (it lives in tigera-elasticsearch and is already granted by logstorage.go), and tightened the activation gate to !Tenant.MultiTenant() since the IdP resources are pinned to calico-system and the RBAC UI is zero-tenant-only anyway.

Is that what you meant by "bind them to the namespaces we actually need" — or were you pointing at something narrower?

rene-dekker · 2026-05-29T22:33:57Z

+		// management UI's directory cache and the cascading cleanup of managed
+		// bindings when a group is removed).
+		{
+			APIGroups:     []string{""},


This one should be in a role.

pasanw · 2026-06-24T01:58:19Z

 			return reconcile.Result{}, err
 		}

+		if instance.Spec.Variant.IsEnterprise() {


Wondering if you found the variant check to be necessary here?

pasanw · 2026-06-24T02:18:02Z

+		rbacv1.PolicyRule{
+			APIGroups: []string{"rbac.authorization.k8s.io"},
+			Resources: []string{"clusterroles", "clusterrolebindings"},
+			Verbs:     []string{"escalate", "bind"},


Is it possible to avoid giving escalate and bind privileges? It essentially means that this controller can become a superuser if it chooses to be (i.e. is compromised)

pasanw · 2026-06-24T02:18:52Z

+		rules = append(rules, rbacv1.PolicyRule{
+			APIGroups: []string{"rbac.authorization.k8s.io"},
+			Resources: []string{"clusterroles", "roles", "clusterrolebindings", "rolebindings"},
+			Verbs:     []string{"get", "list", "watch", "create", "update", "patch", "delete", "bind", "escalate"},


Similar to previous comment - can we avoid bind and escalate? This one seems a bit more serious since it is given to users

pasanw · 2026-06-24T02:21:37Z

+		rbacv1.PolicyRule{
+			APIGroups:     []string{""},
+			Resources:     []string{"configmaps"},
+			ResourceNames: []string{"tigera-known-oidc-users"},


Does this controller access this config map? I thought only the ui-apis endpoint would consult this config map when listing users

pasanw · 2026-06-24T02:24:14Z

+// UI adds to calico-manager-role. Named-resource access is scoped separately
+// on rbacManagementUINamespacedRole.
+func rbacManagementUIRules() []rbacv1.PolicyRule {
+	rules := RBACManagementEscalationRules()


Does the manager use its own SA when creating RBAC via the UI? Or is it impersonating the user?

pasanw · 2026-06-24T02:29:46Z

 		})
 	}

+	if c.cfg.Manager.RBACManagementEnabled() && c.cfg.Authentication != nil && c.cfg.Authentication.Spec.OIDC != nil {


Why do we gate on OIDC being enabled? I'm wondering what that has do to with the user deciding they want to do an LDAP sync for RBAC UI.

To me I would have expected that this block conditionally renders depending on whether the LDAP secret is placed by the user, and that we could parse the LDAP URL to scope the network policy (we do a similar thing for guardian policy)

…ileges (PR tigera#4865 review) Addresses Pasan's review comment on the tigera-network-admin escalate/bind grant. The RBAC management UI must never let an admin grant more than they already hold, so this grants NO escalate and NO bind. ui-apis performs the /team/* RBAC writes by impersonating the calling user, so the kube-apiserver runs its privilege-escalation check against the admin's own permissions. Without escalate/bind that means: an admin can assign a calico-ui- role to a group only if they personally hold every rule in it, and can edit a role only if they already hold its rules — otherwise the apiserver returns 403. The UI is a convenience layer over the user's own privileges, not an amplifier; deciding which admins may delegate which capabilities is then a matter of what those admins are granted, under the operator's control. The grant is also narrowed to what the handlers actually do (verified against the /team/* implementation): roles are read-only (the UI lists/inspects the catalog, never authors roles); clusterrolebindings get create/update/delete for group and member writes; rolebindings are never created (only cluster-scoped groups are), so they get update/delete only. Gated behind the RBAC-UI feature flag. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

…issions instead (PR tigera#4865 review) Addresses Pasan's review comment that the rbacsync controller can become a superuser if compromised, via cluster-wide escalate/bind on RBAC objects. The verbs aren't actually needed: rbacSyncControllerRules already grants the SA the full permission set the calico-ui- roles contain (RBACManagementEscalationRules), so it satisfies Kubernetes' privilege-escalation check by *holding* the rules it writes, rather than by escalate/bind. Removing the verbs means a compromised SA can only assign permissions it already has — it cannot mint an arbitrary cluster-admin role. This relies on RBACManagementEscalationRules staying a superset of the managed roles' contents (which live in calico/kube-controllers). That drift risk is accepted here and is better caught by E2Es than guarded by a standing escalate grant. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

…ing on variant (PR tigera#4865 review) Addresses Pasan's review comment asking whether the variant check before the GetManager read is necessary. It was — but it was the wrong tool. The Manager type is registered in the scheme unconditionally, so on a Calico (OSS) cluster the cached client returns a NoMatchError (not NotFound) when the Manager CRD is absent; the previous error check only tolerated IsNotFound, so without the variant guard the installation controller would degrade on OSS. Drop the redundant variant check (the block already sits under r.enterpriseCRDsExist) and instead tolerate meta.IsNoMatchError alongside IsNotFound, mirroring how this same function handles the calico-system Tier read a few lines below. This is more robust than the variant guard: it also covers the case where enterpriseCRDsExist is true but the Manager CRD has not yet registered. managerCR stays nil on those paths and RBACManagementEnabled() is nil-safe, so behavior is unchanged on OSS. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

… SA (PR tigera#4865 review) Addresses Pasan's review comment asking whether the kube-controllers (rbacsync) controller actually accesses the tigera-known-oidc-users ConfigMap — he believed only the ui-apis endpoint consults it. Verified against the RBAC management UI feature branches (calico-private kube-controllers PR #12077 and ui-apis PR #12088): the rbacsync controller never reads this ConfigMap (no direct CoreV1().ConfigMaps() access and no rbaccache path to it; the only ConfigMap it reads is tigera-idp-groups, covered by its own namespaced Role). The actual consumers are in ui-apis — the user-handler middleware writes it and idp/reader.go reads it to surface idp-group members at /team/groups time — using ui-apis's own identity in the tigera-elasticsearch namespace, not the kube-controllers SA. The legitimate kube-controllers/authorization access is already granted separately by logstorage.go. So this rule was dead RBAC on the kube-controllers SA, also gated on the unrelated RBACManagementEnabled flag. Remove it. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

…not OIDC (PR tigera#4865 review) Addresses Pasan's review comment: the manager's LDAP/AD egress (389/636) was gated on Authentication.Spec.OIDC != nil, which is the wrong signal. Verified against the RBAC management UI feature branches (ui-apis PR #12088): the LDAP dial is performed by ui-apis's rbacmanagement/idp client for the /team/idp-groups directory sync, gated solely on the presence of the tigera-idp-ldap-config Secret (in calico-system) — it does not consult the Authentication CR's OIDC connector at all (that path never dials LDAP from this pod). So the old gate opened the port for pure-OIDC setups that never use it and, worse, withheld it for LDAP-sync setups that need it, leaving the feature broken. Gate the egress on the secret instead: - manager controller discovers the tigera-idp-ldap-config Secret in calico-system and watches it (so the policy re-renders on add/remove), passing presence into the render config as RBACManagementLDAPConfigured. - the egress now renders iff RBACManagementEnabled && RBACManagementLDAPConfigured. Added focused tests including a regression guard that OIDC-configured + no LDAP secret produces no egress. Scoping the destination to the configured LDAP host remains tracked in EV-6665 (it needs the same secret read). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Add Manager.spec.rbac.ui (Enabled/Disabled enum, defaults to Disabled), the RBAC/RBACUI types, and the nil-safe Manager.RBACManagementEnabled() helper. Regenerate deepcopy methods and the Manager CRD manifest. This is the opt-in toggle for the RBAC management UI feature; the render and controller wiring that consume it follow in subsequent commits. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Add rbac_management.go with the escalation-prevention rule set shared by the calico-manager and calico-kube-controllers roles, and gate the feature's RBAC on Manager.spec.rbac.ui == Enabled: - manager: extend calico-manager-role with the cluster-scoped UI rules and add a calico-system Role+RoleBinding scoping Secret/ConfigMap access to the IdP resources; both gated on !MultiTenant() (the feature is zero-tenant-only). Set RBAC_UI_ENABLED on ui-apis, and allow LDAP egress when OIDC authentication is configured. - apiserver: extend tigera-network-admin with the manage-roles rule. - kube-controllers: enable the rbacsync controller, grant its rules, and add a calico-system Role+RoleBinding reading tigera-idp-groups. The Manager and Authentication CRs are surfaced through the render configs here; the controllers that populate them follow. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Move GetManager from the manager controller into pkg/controller/utils so the apiserver and installation controllers can read the Manager CR without importing the manager controller package. Behaviour is unchanged: it keys on tigera-secure, namespacing the lookup only in multi-tenant mode, and returns the raw client error so callers decide whether absence is fatal. Update the manager controller and its tests to the new location. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Read the Manager CR in the installation and apiserver controllers and pass RBACManagementEnabled into their render configs, and watch the Manager CR so toggling spec.rbac re-runs each reconcile. The installation controller only reads it for the enterprise variant; absence is treated as RBAC management disabled. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

…ileges (PR tigera#4865 review) Addresses Pasan's review comment on the tigera-network-admin escalate/bind grant. The RBAC management UI must never let an admin grant more than they already hold, so this grants NO escalate and NO bind. ui-apis performs the /team/* RBAC writes by impersonating the calling user, so the kube-apiserver runs its privilege-escalation check against the admin's own permissions. Without escalate/bind that means: an admin can assign a calico-ui- role to a group only if they personally hold every rule in it, and can edit a role only if they already hold its rules — otherwise the apiserver returns 403. The UI is a convenience layer over the user's own privileges, not an amplifier; deciding which admins may delegate which capabilities is then a matter of what those admins are granted, under the operator's control. The grant is also narrowed to what the handlers actually do (verified against the /team/* implementation): roles are read-only (the UI lists/inspects the catalog, never authors roles); clusterrolebindings get create/update/delete for group and member writes; rolebindings are never created (only cluster-scoped groups are), so they get update/delete only. Gated behind the RBAC-UI feature flag. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

…issions instead (PR tigera#4865 review) Addresses Pasan's review comment that the rbacsync controller can become a superuser if compromised, via cluster-wide escalate/bind on RBAC objects. The verbs aren't actually needed: rbacSyncControllerRules already grants the SA the full permission set the calico-ui- roles contain (RBACManagementEscalationRules), so it satisfies Kubernetes' privilege-escalation check by *holding* the rules it writes, rather than by escalate/bind. Removing the verbs means a compromised SA can only assign permissions it already has — it cannot mint an arbitrary cluster-admin role. This relies on RBACManagementEscalationRules staying a superset of the managed roles' contents (which live in calico/kube-controllers). That drift risk is accepted here and is better caught by E2Es than guarded by a standing escalate grant. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

…ing on variant (PR tigera#4865 review) Addresses Pasan's review comment asking whether the variant check before the GetManager read is necessary. It was — but it was the wrong tool. The Manager type is registered in the scheme unconditionally, so on a Calico (OSS) cluster the cached client returns a NoMatchError (not NotFound) when the Manager CRD is absent; the previous error check only tolerated IsNotFound, so without the variant guard the installation controller would degrade on OSS. Drop the redundant variant check (the block already sits under r.enterpriseCRDsExist) and instead tolerate meta.IsNoMatchError alongside IsNotFound, mirroring how this same function handles the calico-system Tier read a few lines below. This is more robust than the variant guard: it also covers the case where enterpriseCRDsExist is true but the Manager CRD has not yet registered. managerCR stays nil on those paths and RBACManagementEnabled() is nil-safe, so behavior is unchanged on OSS. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

… SA (PR tigera#4865 review) Addresses Pasan's review comment asking whether the kube-controllers (rbacsync) controller actually accesses the tigera-known-oidc-users ConfigMap — he believed only the ui-apis endpoint consults it. Verified against the RBAC management UI feature branches (calico-private kube-controllers PR #12077 and ui-apis PR #12088): the rbacsync controller never reads this ConfigMap (no direct CoreV1().ConfigMaps() access and no rbaccache path to it; the only ConfigMap it reads is tigera-idp-groups, covered by its own namespaced Role). The actual consumers are in ui-apis — the user-handler middleware writes it and idp/reader.go reads it to surface idp-group members at /team/groups time — using ui-apis's own identity in the tigera-elasticsearch namespace, not the kube-controllers SA. The legitimate kube-controllers/authorization access is already granted separately by logstorage.go. So this rule was dead RBAC on the kube-controllers SA, also gated on the unrelated RBACManagementEnabled flag. Remove it. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

…not OIDC (PR tigera#4865 review) Addresses Pasan's review comment: the manager's LDAP/AD egress (389/636) was gated on Authentication.Spec.OIDC != nil, which is the wrong signal. Verified against the RBAC management UI feature branches (ui-apis PR #12088): the LDAP dial is performed by ui-apis's rbacmanagement/idp client for the /team/idp-groups directory sync, gated solely on the presence of the tigera-idp-ldap-config Secret (in calico-system) — it does not consult the Authentication CR's OIDC connector at all (that path never dials LDAP from this pod). So the old gate opened the port for pure-OIDC setups that never use it and, worse, withheld it for LDAP-sync setups that need it, leaving the feature broken. Gate the egress on the secret instead: - manager controller discovers the tigera-idp-ldap-config Secret in calico-system and watches it (so the policy re-renders on add/remove), passing presence into the render config as RBACManagementLDAPConfigured. - the egress now renders iff RBACManagementEnabled && RBACManagementLDAPConfigured. Added focused tests including a regression guard that OIDC-configured + no LDAP secret produces no egress. Scoping the destination to the configured LDAP host remains tracked in EV-6665 (it needs the same secret read). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

…ks bundles Refresh the bundled enterprise CRDs after rebasing onto the latest master. make gen-files picks up upstream schema changes: istioDSCPMark becomes int-or-string (anyOf integer/string) on felixconfigurations, and ipamblocks allocations drops a stale controller-gen TODO and reorders nullable/type. No operator code change; satisfies make dirty-check / validate-gen-versions. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

marvin-tigera added this to the v1.43.0 milestone May 26, 2026

marvin-tigera added docs-pr-required release-note-required labels May 26, 2026

dimitri-nicolo changed the title ~~Dimitri pmreq 824 rbac mgmt~~ manager: add opt-in RBAC management UI via rbacManagement flag May 26, 2026

dimitri-nicolo changed the title ~~manager: add opt-in RBAC management UI via rbacManagement flag~~ Add opt-in RBAC management UI via rbacManagement flag May 26, 2026

dimitri-nicolo force-pushed the dimitri-PMREQ-824-rbac-mgmt branch from 504568c to 8239694 Compare May 27, 2026 00:13

dimitri-nicolo marked this pull request as ready for review May 27, 2026 00:33

dimitri-nicolo requested a review from a team as a code owner May 27, 2026 00:33

rene-dekker reviewed May 27, 2026

View reviewed changes

Comment thread api/v1/manager_types.go Outdated

rene-dekker reviewed May 27, 2026

View reviewed changes

Comment thread api/v1/manager_types.go Outdated

rene-dekker reviewed May 27, 2026

View reviewed changes

dimitri-nicolo requested a review from rene-dekker May 28, 2026 19:17

rene-dekker reviewed May 28, 2026

View reviewed changes

dimitri-nicolo requested a review from rene-dekker May 28, 2026 21:35

dimitri-nicolo force-pushed the dimitri-PMREQ-824-rbac-mgmt branch from b9493a6 to 94159c6 Compare May 28, 2026 21:53

rene-dekker reviewed May 28, 2026

View reviewed changes

Comment thread pkg/render/manager.go Outdated

dimitri-nicolo requested a review from rene-dekker May 29, 2026 00:49

dimitri-nicolo force-pushed the dimitri-PMREQ-824-rbac-mgmt branch from 8833288 to 2b749da Compare May 29, 2026 22:19

rene-dekker reviewed May 29, 2026

View reviewed changes

radTuti modified the milestones: v1.43.0, v1.44.0 Jun 12, 2026

dimitri-nicolo force-pushed the dimitri-PMREQ-824-rbac-mgmt branch from 2b749da to 6af6ea3 Compare June 18, 2026 21:04

dimitri-nicolo requested a review from marvin-tigera as a code owner June 18, 2026 21:04

pasanw reviewed Jun 24, 2026

View reviewed changes

dimitri-nicolo and others added 9 commits June 25, 2026 17:17

dimitri-nicolo force-pushed the dimitri-PMREQ-824-rbac-mgmt branch from 2d72d96 to 4aee36e Compare June 26, 2026 00:25

dimitri-nicolo requested review from pasanw and rene-dekker June 26, 2026 21:18

Uh oh!

Conversation

dimitri-nicolo commented May 26, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

What the flag turns on, by layer

Why the installation and apiserver controllers read the Manager CR

Per-cluster behavior

Release Note

For PR author

For PR reviewers

Uh oh!

Uh oh!

Uh oh!

rene-dekker May 27, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rene-dekker commented May 28, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

pasanw Jun 24, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

dimitri-nicolo commented May 26, 2026 •

edited

Loading

rene-dekker May 27, 2026 •

edited

Loading

rene-dekker commented May 28, 2026 •

edited

Loading

pasanw Jun 24, 2026 •

edited

Loading