Skip to content

Restrict Redis tenant ACLs while preserving Lua on 0.9.0 - #140

Merged
sciabarracom merged 5 commits into
apache:0.9.0from
miki3421:security-0.9.0-redis-tenant-acl
Oct 20, 2026
Merged

sciabarracom merged 5 commits into
apache:0.9.0from
miki3421:security-0.9.0-redis-tenant-acl

Conversation

@miki3421

@miki3421 miki3421 commented Oct 19, 2026 •

Copy link
Copy Markdown
Contributor

Redis tenant accounts in 0.9.0 receive +@all: key-prefix restrictions do not restrict administrative commands or global key/channel operations. This change replaces tenant grants with a shared restricted policy during provisioning, reconciliation and quota transitions.

The policy resets legacy key/channel grants and ACL selectors, restricts keys and Pub/Sub channels to the tenant prefix, and denies administration, global enumeration, function management and global script-management commands. Application Lua remains available through EVAL/EVALSHA, their read-only variants, SCRIPT LOAD and SCRIPT EXISTS; scripts remain subject to the caller's command and key permissions. Quota recovery restores tenant writes without restoring +@all.

Provisioning uses structured Redis commands and password hashes instead of interpolating tenant credentials into a CLI script. Kopf handlers are loaded by module name so the package directory does not enter the top-level import search path: the local openserverless/redis.py must not shadow the third-party Redis driver during tenant provisioning. The legacy template permits its broad internal grant only for the explicitly selected OpenServerless system account. Existing tenant credentials, profile fields, Redis version, data and volumes are preserved. ACLs are saved when an ACL file is configured, preserving the existing 0.9.0 startup-reconciliation contract otherwise. Existing installations must reconcile their existing tenants to replace legacy grants; changing the operator image alone does not rewrite every existing identity.

Validation:

  • 13 focused unit tests passed; added to the pull-request Check workflow.
  • The complete isolated regression suite passes 34 tests, including six tests for loopback-only Kubernetes forwarding and cleanup and a regression exercising the actual Kopf loader from run.sh with a Redis client. Administration uses the internal service inside Kubernetes and authenticated, temporary localhost forwarding when invoked from an external integration runner.
  • 46 live lifecycle/security checks passed again on the patched 0.9.0 K3s lab: provisioning and reconciliation, stale selectors, peer-key/channel denial, Lua, Pub/Sub, quota enter/exit, credential compatibility and deletion with data retention. Dangerous commands were checked with administrator-side ACL DRYRUN rather than executing them.
  • The adapted candidate client passed the 46 live checks again in an isolated process in the baseline operator. The forwarding helper was also exercised from outside the cluster against the real Redis and etcd Services, retaining authentication requirements. These additional checks did not replace the deployed operator image.
  • Alpha and Beta application checks passed on both patched K3s labs with application source unchanged.

The optional live test requires an explicit --lab flag and is not run by unit-test discovery. This PR contains only the 0.9.0 authorization backport and its tests; it does not upgrade Redis or include Advanced component changes.

CI transparency: the existing task itest runner reports failures without a failing exit code. A final Check step now rejects any integration failure except the two reproduced in the unmodified 0.9.0 CI run 38893750250: tests/kind/ferretdb_test.ipy and tests/kind/runtimes_preloader_test.ipy. Those remain explicit warnings, not passing tests. In particular, a Redis tenant lifecycle regression now makes the Check fail.

Prior CI result for d9ae8e2: Check run 39258349764 succeeded. All 33 regression tests passed. Redis provisioning and user lifecycle passed among 36 passing integration scripts. The only two remaining failures are the baseline failures listed above; the new regression gate passed with no unexpected failures.

Launcher follow-up (fc6de79): the regression reproduces driver shadowing with the old launcher and passes with module-only loading. All 34 tests passed locally on this PR candidate. The same launcher fix was exercised during a clean patched 0.9.0 K3s installation, with unchanged Alpha/Beta applications passing their application and Redis Lua suites. Current-head CI: Check run 39286767053 succeeded on fc6de79: all 34 regression tests, the unit-test step and the final integration regression gate passed. The 2 pre-existing integration failures listed above remain explicit warnings; no new integration failures were accepted.

@sciabarracom
sciabarracom merged commit 68b8497 into apache:0.9.0 Oct 20, 2026
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants