Skip to content

Commit d181d67

Browse files
camilamacedo86camilamacedo86
committed
test: Add RBAC escalation test for installer ServiceAccount permissions
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
1 parent 1fa4169 commit d181d67

File tree

5 files changed

+273
-0
lines changed

5 files changed

+273
-0
lines changed

‎test/e2e/features/rbac-escalation.feature‎

Lines changed: 37 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,37 @@
1+
Feature: RBAC Permissions for Extension Installation
2+
3+
Background:
4+
Given OLM is available
5+
And ClusterCatalog "test" serves bundles
6+
And ServiceAccount "olm-sa" with needed permissions is available in ${TEST_NAMESPACE}
7+
8+
# This test verifies that the ClusterExtension installer ServiceAccount has the necessary
9+
# RBAC permissions to install operators with different permission requirements.
10+
#
11+
# The rbac-escalation-operator requires permissions beyond what test-operator needs,
12+
# testing that the installer SA can create ClusterRoleBindings for roles with
13+
# permissions the SA itself doesn't directly possess (via bind/escalate verbs).
14+
#
15+
# See: docs/concepts/permission-model.md for OLMv1 permission requirements
16+
Scenario: Install operator with different RBAC requirements
17+
When ClusterExtension is applied
18+
"""
19+
apiVersion: olm.operatorframework.io/v1
20+
kind: ClusterExtension
21+
metadata:
22+
name: rbac-escalation-test
23+
spec:
24+
namespace: ${TEST_NAMESPACE}
25+
serviceAccount:
26+
name: olm-sa
27+
source:
28+
sourceType: Catalog
29+
catalog:
30+
packageName: rbac-escalation-operator
31+
selector:
32+
matchLabels:
33+
"olm.operatorframework.io/metadata.name": test-catalog
34+
"""
35+
Then ClusterExtension is available
36+
And bundle "rbac-escalation-operator.1.0.0" is installed in version "1.0.0"
37+

‎testdata/images/bundles/rbac-escalation-operator/README.md‎

Lines changed: 122 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,122 @@
1+
# RBAC Escalation Test Operator
2+
3+
## Purpose
4+
5+
This operator bundle tests that the ClusterExtension installer ServiceAccount has proper RBAC permissions to install operators with varying permission requirements.
6+
7+
## Why This Bundle Exists
8+
9+
### Testing RBAC Escalation Scenarios
10+
11+
The standard `test-operator` bundle has minimal RBAC requirements (only `tokenreviews` and `subjectaccessreviews`) that happen to match what the test ServiceAccount already has. This operator tests a more realistic scenario where an operator requires **different permissions**:
12+
13+
**Required Permissions** (from CSV clusterPermissions):
14+
- `storage.k8s.io/storageclasses` [create, update, delete, list, watch, get]
15+
- `scheduling.k8s.io/priorityclasses` [create, update, delete, list, watch, get]
16+
17+
**Test SA Permissions** (from rbac-template.yaml):
18+
- Does NOT have `storage.k8s.io` permissions directly
19+
- Does NOT have `scheduling.k8s.io` permissions directly
20+
- **Must have** `bind` and `escalate` verbs to create the necessary RBAC
21+
22+
**Kubernetes RBAC Check**:
23+
When OLMv1 tries to create the ClusterRoleBinding for this operator, Kubernetes checks:
24+
1. Can SA create clusterrolebindings resource? → YES ✅
25+
2. Can SA bind this specific role?
26+
- Option A: Has `bind` verb? → Required when role has permissions SA doesn't have
27+
- Option B: Has ALL permissions in role? → Not applicable (SA doesn't have storage.k8s.io)
28+
3. **Result**: Requires `bind` verb for successful installation
29+
30+
## Expected Behavior
31+
32+
### With Proper RBAC (bind/escalate verbs)
33+
34+
**Test SA must have** in `test/e2e/steps/testdata/rbac-template.yaml`:
35+
```yaml
36+
- apiGroups: ["rbac.authorization.k8s.io"]
37+
resources: [clusterroles, roles, clusterrolebindings, rolebindings]
38+
verbs: [ update, create, list, watch, get, delete, patch, bind, escalate ]
39+
```
40+
41+
The `bind` and `escalate` verbs allow the installer SA to create RBAC resources that grant permissions beyond what the SA itself has, which is required per the OLMv1 permission model.
42+
43+
## Bundle Structure
44+
45+
```
46+
rbac-escalation-operator/
47+
└── v1.0.0/
48+
├── manifests/
49+
│ └── rbac-escalation-operator.clusterserviceversion.yaml
50+
└── metadata/
51+
└── annotations.yaml
52+
```
53+
54+
## Integration
55+
56+
### Catalog Entry
57+
58+
Added to `testdata/images/catalogs/test-catalog/v1/configs/catalog.yaml`:
59+
```yaml
60+
schema: olm.package
61+
name: rbac-escalation-operator
62+
defaultChannel: stable
63+
---
64+
schema: olm.channel
65+
name: stable
66+
package: rbac-escalation-operator
67+
entries:
68+
- name: rbac-escalation-operator.1.0.0
69+
---
70+
schema: olm.bundle
71+
name: rbac-escalation-operator.1.0.0
72+
package: rbac-escalation-operator
73+
image: docker-registry.operator-controller-e2e.svc.cluster.local:5000/bundles/registry-v1/rbac-escalation-operator:v1.0.0
74+
```
75+
76+
### E2E Test
77+
78+
Test scenario in `test/e2e/features/rbac-escalation.feature`:
79+
- Installs rbac-escalation-operator
80+
- Expects installation to succeed
81+
- On main: **WILL FAIL** (proves bug)
82+
- After fix: **WILL PASS** (proves fix works)
83+
84+
## Usage
85+
86+
### Running the Test
87+
88+
```bash
89+
# Run all e2e tests (includes this test)
90+
make test-e2e
91+
92+
# Or run just this feature
93+
go test -v ./test/e2e/features_test.go -godog.paths=test/e2e/features/rbac-escalation.feature
94+
```
95+
96+
**Expected**: Test passes when test SA has `bind` and `escalate` verbs
97+
98+
### What This Test Validates
99+
100+
1. Installer SA can create RBAC for operators with different permission needs
101+
2. Kubernetes escalation prevention works correctly with `bind`/`escalate` verbs
102+
3. OLMv1 permission model is correctly implemented
103+
4. Regression prevention for RBAC permission requirements
104+
105+
## References
106+
107+
- **Permission Model Documentation**: `docs/concepts/permission-model.md`
108+
- **Kubernetes RBAC**: https://kubernetes.io/docs/reference/access-authn-authz/rbac/#privilege-escalation-prevention-and-bootstrapping
109+
- **Related PR**: #2429 - Adds bind/escalate to fix this issue
110+
111+
## Notes
112+
113+
This operator is intentionally minimal - it exists solely to test RBAC escalation scenarios. The bundle requires permissions (storage.k8s.io, scheduling.k8s.io) that are different from what simpler test operators need, ensuring that the installer ServiceAccount's `bind` and `escalate` verbs are properly exercised.
114+
115+
This validates that OLMv1 can install operators with diverse permission requirements, not just operators that happen to need the same permissions as the installer SA.
116+
117+
---
118+
119+
**Created**: 2026-01-12
120+
**Purpose**: Test RBAC escalation handling with bind/escalate verbs
121+
**Type**: Regression test for proper RBAC permission model implementation
122+

‎testdata/images/bundles/rbac-escalation-operator/v1.0.0/manifests/rbac-escalation-operator.clusterserviceversion.yaml‎

Lines changed: 85 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,85 @@
1+
apiVersion: operators.coreos.com/v1alpha1
2+
kind: ClusterServiceVersion
3+
metadata:
4+
name: rbac-escalation-operator.v1.0.0
5+
namespace: placeholder
6+
spec:
7+
apiservicedefinitions: {}
8+
customresourcedefinitions:
9+
owned: []
10+
description: Test operator for validating RBAC escalation handling with diverse permission requirements
11+
displayName: RBAC Escalation Test Operator
12+
install:
13+
spec:
14+
deployments:
15+
- name: rbac-escalation-operator
16+
spec:
17+
replicas: 1
18+
selector:
19+
matchLabels:
20+
app: rbac-escalation
21+
template:
22+
metadata:
23+
labels:
24+
app: rbac-escalation
25+
spec:
26+
terminationGracePeriodSeconds: 0
27+
containers:
28+
- name: manager
29+
image: busybox:1.37
30+
command: ["/bin/sh", "-c", "sleep 3600"]
31+
serviceAccountName: rbac-escalation-sa
32+
# These permissions differ from test-operator's requirements to validate
33+
# that the installer SA can handle operators with diverse RBAC needs
34+
clusterPermissions:
35+
- rules:
36+
# Requires storage.k8s.io permissions to test RBAC escalation handling
37+
- apiGroups:
38+
- storage.k8s.io
39+
resources:
40+
- storageclasses
41+
verbs:
42+
- create
43+
- update
44+
- delete
45+
- list
46+
- watch
47+
- get
48+
# Requires scheduling.k8s.io permissions to test diverse RBAC scenarios
49+
- apiGroups:
50+
- scheduling.k8s.io
51+
resources:
52+
- priorityclasses
53+
verbs:
54+
- create
55+
- update
56+
- delete
57+
- list
58+
- watch
59+
- get
60+
serviceAccountName: rbac-escalation-sa
61+
strategy: deployment
62+
installModes:
63+
- supported: false
64+
type: OwnNamespace
65+
- supported: false
66+
type: SingleNamespace
67+
- supported: false
68+
type: MultiNamespace
69+
- supported: true
70+
type: AllNamespaces
71+
keywords:
72+
- rbac-testing
73+
- escalation
74+
links:
75+
- name: RBAC Escalation Operator
76+
url: https://github.com/operator-framework/operator-controller
77+
maintainers:
78+
- email: dev@operatorframework.io
79+
name: OLM Team
80+
maturity: alpha
81+
provider:
82+
name: Operator Framework
83+
url: https://operatorframework.io
84+
version: 1.0.0
85+

‎testdata/images/bundles/rbac-escalation-operator/v1.0.0/metadata/annotations.yaml‎

Lines changed: 8 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,8 @@
1+
annotations:
2+
operators.operatorframework.io.bundle.channel.default.v1: stable
3+
operators.operatorframework.io.bundle.channels.v1: stable
4+
operators.operatorframework.io.bundle.manifests.v1: manifests/
5+
operators.operatorframework.io.bundle.mediatype.v1: registry+v1
6+
operators.operatorframework.io.bundle.metadata.v1: metadata/
7+
operators.operatorframework.io.bundle.package.v1: rbac-escalation-operator
8+

‎testdata/images/catalogs/test-catalog/v1/configs/catalog.yaml‎

Lines changed: 21 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -159,3 +159,24 @@ properties:
159159
value:
160160
packageName: single-namespace-operator
161161
version: 1.0.0
162+
---
163+
schema: olm.package
164+
name: rbac-escalation-operator
165+
defaultChannel: stable
166+
---
167+
schema: olm.channel
168+
name: stable
169+
package: rbac-escalation-operator
170+
entries:
171+
- name: rbac-escalation-operator.1.0.0
172+
---
173+
schema: olm.bundle
174+
name: rbac-escalation-operator.1.0.0
175+
package: rbac-escalation-operator
176+
image: docker-registry.operator-controller-e2e.svc.cluster.local:5000/bundles/registry-v1/rbac-escalation-operator:v1.0.0
177+
properties:
178+
- type: olm.package
179+
value:
180+
packageName: rbac-escalation-operator
181+
version: 1.0.0
182+

0 commit comments

Comments
 (0)