WIP 🌱 Add RBAC escalation test for installer ServiceAccount permissions #2441
Conversation
openshift-ci
bot
added
the
do-not-merge/work-in-progress
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
✅ Deploy Preview for olmv1 ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
camilamacedo86
force-pushed
the
big-hidden-sa-fix
branch
from
d181d67 to
a27aaae
Compare
There was a problem hiding this comment.
Pull request overview
This PR adds a new test operator bundle (rbac-escalation-operator) and corresponding e2e test scenario to validate that the ClusterExtension installer ServiceAccount can install operators with diverse RBAC requirements. The test operator requires storage.k8s.io and scheduling.k8s.io permissions that differ from existing test operators, ensuring proper exercise of the installer SA's bind/escalate verbs.
Changes:
- Added rbac-escalation-operator bundle v1.0.0 with ClusterServiceVersion requiring storage.k8s.io and scheduling.k8s.io permissions
- Added catalog entry for the new operator to test-catalog
- Added e2e test feature file to validate RBAC escalation handling
Reviewed changes
Copilot reviewed 4 out of 4 changed files in this pull request and generated no comments.
Show a summary per file
| File | Description |
|---|---|
| testdata/images/catalogs/test-catalog/v1/configs/catalog.yaml | Added catalog entry for rbac-escalation-operator package with stable channel |
| testdata/images/bundles/rbac-escalation-operator/v1.0.0/metadata/annotations.yaml | Standard bundle metadata annotations |
| testdata/images/bundles/rbac-escalation-operator/v1.0.0/manifests/rbac-escalation-operator.clusterserviceversion.yaml | ClusterServiceVersion defining operator with storage.k8s.io and scheduling.k8s.io permissions |
| testdata/images/bundles/rbac-escalation-operator/README.md | Comprehensive documentation explaining the purpose and expected behavior of the test |
| test/e2e/features/rbac-escalation.feature | E2E test scenario validating installation with different RBAC requirements |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
camilamacedo86
changed the title
openshift-ci
bot
removed
the
do-not-merge/work-in-progress
camilamacedo86
changed the title
openshift-ci
bot
added
the
do-not-merge/work-in-progress
Add rbac-escalation-operator test bundle and e2e scenario to validate that the ClusterExtension installer ServiceAccount can install operators with diverse RBAC requirements. This operator requires storage.k8s.io and scheduling.k8s.io permissions that differ from the basic test-operator, ensuring the installer SA's bind/escalate verbs are properly exercised per the documented permission model in docs/concepts/permission-model.md. The test validates: - Installer SA can create RBAC for operators with different permissions - Kubernetes escalation prevention works with bind/escalate verbs - OLMv1 permission model supports diverse operator requirements - Regression prevention for RBAC permission issues
camilamacedo86
force-pushed
the
big-hidden-sa-fix
branch
from
114b868 to
d192d08
Compare
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 4 out of 4 changed files in this pull request and generated 1 comment.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Add bind and escalate verbs to test RBAC template to comply with documented prerequisites in docs/concepts/permission-model.md. These verbs are REQUIRED per our documentation for installer ServiceAccounts that install operators with their own RBAC. The missing prerequisites were exposed by the rbac-escalation e2e test, which uses an operator requiring permissions the test SA doesn't have (storage.k8s.io, scheduling.k8s.io). Without bind/escalate verbs, Kubernetes rejects the ClusterRoleBinding creation with escalation prevention errors. Previous tests passed because they only used test-operator, which has minimal RBAC (tokenreviews, subjectaccessreviews) that the test SA coincidentally already has. This created false confidence and hid the incomplete RBAC template. Fixes: rbac-escalation e2e test Aligns: test template with docs/concepts/permission-model.md See: https://github.com/operator-framework/operator-controller/actions/runs/20920337864/job/60103970542?pr=2441
Add startup, liveness, and readiness probes to rbac-escalation-operator deployment so the pod can report ready status and the ClusterExtension can reach Available condition. Without probes, the deployment never reports ready, causing the test to timeout waiting for 'ClusterExtension is available'. Fixes: rbac-escalation.feature test availability check
camilamacedo86
force-pushed
the
big-hidden-sa-fix
branch
from
67349fa to
bf17ecc
Compare
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 5 out of 5 changed files in this pull request and generated no new comments.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
1 participant
Add rbac-escalation-operator test bundle and e2e scenario to validate that the ClusterExtension installer ServiceAccount can install operators with diverse RBAC requirements.
This operator requires storage.k8s.io and scheduling.k8s.io permissions that differ from the basic test-operator, ensuring the installer SA's bind/escalate verbs are properly exercised per the documented permission model in docs/concepts/permission-model.md.
The test validates:
The error can be faced with: https://github.com/operator-framework/operator-controller/actions/runs/20921664760/job/60108536707?pr=2441#step:4:1414
The
bindandescalateverbs are documented prerequisites and should have been included in the test RBAC. We’re adding a test to ensure this scenario is exercised and validated correctly.