You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Switch from token-based auth to ServiceAccount impersonation
This commit replaces token-based authentication with ServiceAccount
impersonation for better security and simpler token management.
Changes:
Authentication layer:
- Added ServiceAccountImpersonationConfig() function that returns an
ImpersonationConfig for a ServiceAccount user
- Updated ServiceAccountRestConfigMapper() to use impersonation via
NewImpersonatingRoundTripper instead of TokenInjectingRoundTripper
- Removed TokenGetter parameter from ServiceAccountRestConfigMapper
- Deleted tokengetter.go, tokengetter_test.go, and tripper.go as
they are no longer needed
RBAC:
- Changed from serviceaccounts/token create to serviceaccounts
impersonate permission
Controller:
- Removed ServiceAccountNotFoundError handling since impersonation
doesn't require the ServiceAccount to exist beforehand
- Removed authentication package import from controller
Main setup:
- Removed TokenGetter initialization
- Updated userInfoMapper to use ServiceAccountImpersonationConfig
Tests:
- Updated tests to verify impersonation headers instead of token
injection
- Added tests for ServiceAccountImpersonationConfig
- Updated controller tests that referenced TokenGetter
Benefits of impersonation over tokens:
- No need to manage token lifecycle or expiration
- No need to check if ServiceAccount exists before use
- Simpler code with fewer moving parts
- More secure as no tokens are created or cached
- More secure as it is no longer required to create highly privileged
ServiceAccounts that could be used by workloads in the install
namespace.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
Copy file name to clipboardExpand all lines: docs/howto/derive-service-account.md
+14-6Lines changed: 14 additions & 6 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -300,12 +300,20 @@ Therefore, the following permissions must be given to the installer service acco
300
300
Once the installer service account required cluster-scoped and namespace-scoped permissions have been collected:
301
301
302
302
1. Create the installation namespace
303
-
2. Create the installer `ServiceAccount`
304
-
3. Create the installer `ClusterRole`
305
-
4. Create the `ClusterRoleBinding` between the installer service account and its cluster role
306
-
5. Create the installer `Role`
307
-
6. Create the `RoleBinding` between the installer service account and its role
308
-
7. Create the `ClusterExtension`
303
+
2. Create the installer `ClusterRole`
304
+
3. Create the `ClusterRoleBinding` between the installer service account and its cluster role
305
+
4. Create the installer `Role`
306
+
5. Create the `RoleBinding` between the installer service account and its role
307
+
6. Create the `ClusterExtension`
308
+
309
+
!!! important "Do Not Create the ServiceAccount Resource"
310
+
OLM v1 uses Kubernetes impersonation and does not require the ServiceAccount to exist as an actual resource.
311
+
For security reasons, you should **NOT** create a ServiceAccount resource for the installer,
312
+
as it would be highly privileged and could be mounted by other pods in the namespace.
313
+
314
+
Instead, only create the RBAC resources (ClusterRole, ClusterRoleBinding, Role, RoleBinding)
315
+
that reference the ServiceAccount name. OLM will impersonate that ServiceAccount and be subject
316
+
to these RBAC permissions without the ServiceAccount resource actually existing in the cluster.
309
317
310
318
A manifest with the full set of resources can be found [here](https://github.com/operator-framework/operator-controller/blob/main/config/samples/olm_v1_clusterextension.yaml).
0 commit comments