Skip to content

[backport v0.11 - rancher v2.15] reject user operations on rancher-managed resource quota and limit range resources - #1797

Open
andreas-kupries wants to merge 22 commits into
mainfrom
extended-quota-enforcement-2.15
Open

[backport v0.11 - rancher v2.15] reject user operations on rancher-managed resource quota and limit range resources#1797
andreas-kupries wants to merge 22 commits into
mainfrom
extended-quota-enforcement-2.15

Conversation

@andreas-kupries

Copy link
Copy Markdown
Contributor

Issue:

rancher/rancher#56773

Companion PR r/rancher rancher/rancher#56801

Problem

The NRQR (Rancher-managed namespace ResourceQuota, identified by label resourcequota.management.cattle.io/default-resource-quota: true) was enforced only at namespace creation time. Any user with RBAC access to resourcequotas could subsequently edit the object directly, fully bypassing project-level enforcement.

The same is true for the LimitRange resource managed by Rancher.

Solution

Added validating webhooks for ResourceQuota and LimitRange objects.
The companion PR modifies Rancher to send its requests using the webhook bypass.
This means that the new validators see only user initiated requests, and only have to reject operations involving the marker label. IOW

  • Reject attempts to create resources bearing the marker label
  • Reject attempts to delete resources bearing the marker label
  • Reject attempts to change resources bearing the marker label
    • This includes changes attempting to strip the marker (demotion to unmanaged)
  • Reject attempts to add a marker to to un-marked resources (i.e. prevent promotion to managed)

gehrkefc and others added 17 commits July 20, 2026 15:55
- ci.yaml: clone rancher release/v2.15, RANCHER_IMAGE_TAG v2.15-head, VERSION release/v2.15
- release-rancher.yaml: rancher_ref default release/v2.15
- sync-deps.yaml: rancher_ref default release/v2.15

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: release-automation <release-automation@users.noreply.github.com>
…creates (#1742)

Backport of #1729

* Set the creatorId annotation on dry-run provisioning Cluster creates

The mutating webhook for provisioning Clusters returned early on every
dry-run request, before setting the creatorId annotation. The
validating webhook requires that annotation on dry-run creates, so
every server-side dry-run create was denied while the identical real
create succeeded. For PSACT-configured clusters the validating webhook
also checks the admission-config secret the mutator writes, which
fails the same way on dry-run since the write never happens.

The mutator's early return is replaced with a guard around only the
PSACT secret handling, the one stage with a real side effect. On
dry-run, the object parse, the creatorId annotation, the
dynamic-schema revert, and the JSON patch generation now run as they
do on a real request, so the preview patch matches the eventual apply.
The validating webhook skips only its checks against that
mutator-produced state (the secret and the cluster fields derived from
it) on dry-run; its pure input checks — the kubernetes version floor
and the template's existence — still run, so invalid input is denied
in the preview exactly as it would be on a real request. The patch
changes only the in-flight request object, which a dry-run never
persists, so the webhook's SideEffects: NoneOnDryRun registration
remains accurate.

* Document provisioning Cluster dry-run behavior

The Cluster admission webhooks previously lacked documentation
about their behavior on server-side dry-run requests. The docs
now cover three key areas: the creatorId annotation is set on
dry-run creates; dynamic-schema reverts apply to dry-run updates;
and Pod Security Admission Configuration Template checks run on
dry-run while secret management is skipped. Updated both the
per-resource and aggregate documentation.
Co-authored-by: renovate-rancher[bot] <119870437+renovate-rancher[bot]@users.noreply.github.com>
Co-authored-by: rancher-pr-and-push-webhook[bot] <181785884+rancher-pr-and-push-webhook[bot]@users.noreply.github.com>
Co-authored-by: rancher-pr-and-push-webhook[bot] <181785884+rancher-pr-and-push-webhook[bot]@users.noreply.github.com>
Co-authored-by: rancher-pr-and-push-webhook[bot] <181785884+rancher-pr-and-push-webhook[bot]@users.noreply.github.com>
- github.com/rancher/dynamiclistener to v0.9.1
- github.com/rancher/norman to v0.9.10

Co-authored-by: release-automation <release-automation@users.noreply.github.com>
Co-authored-by: rancher-pr-and-push-webhook[bot] <181785884+rancher-pr-and-push-webhook[bot]@users.noreply.github.com>
* bypass read only settings for rancher service account

* update validator docs

* go generate

---------

Co-authored-by: joshmeranda <joshua.meranda@gmail.com>
Updates to User PrincipalIDs are now rejected, matching the existing immutability check for Username. The check applies regardless of the manage-users verb.
Co-authored-by: rancher-pr-and-push-webhook[bot] <181785884+rancher-pr-and-push-webhook[bot]@users.noreply.github.com>
….github.com>

boilerplate from copilot still present. unit tests and checks completely rewritten

added validators for resource quota to webhook
added docs, extended webhook codegen

the new validator rejects creation, edition, deletion of rancher managed resources.
the new validator further rejects promotion of unmanaged to managed resource, and vice versa.
the managed resource is recognized by its marker label.

the validator is written with the assumption that rancher requests are tagged
with webhook bypass and therefore do not reach the validator.

unit tests.

all of the above for limit range resources as well.
andreas-kupries and others added 5 commits August 26, 2026 12:21
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
fix Limitrange typo
fix Resourcequota typo
Co-authored-by: andreas-kupries <577247+andreas-kupries@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants