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
Copy file name to clipboardExpand all lines: content/en/docs/concepts/work-distribution/manifestwork.md
+19-13Lines changed: 19 additions & 13 deletions
Original file line number
Diff line number
Diff line change
@@ -337,8 +337,9 @@ However, change from other actors on the `ManagedCluster` will be ignored.
337
337
338
338
## Permission setting for work agent
339
339
340
-
All workload manifests are applied to the managed cluster by the workagent, and by default the workagent has the
340
+
All workload manifests are applied to the managed cluster by the work-agent, and by default the work-agent has the
341
341
following permission for the managed cluster:
342
+
342
343
- clusterRole `admin`(instead of the `cluster-admin`) to apply kubernetes common resources
343
344
- managing `customresourcedefinitions`, but can not manage a specific custom resource instance
344
345
- managing `clusterrolebindings`, `rolebindings`, `clusterroles`, `roles`, including the `bind` and `escalate`
@@ -348,19 +349,23 @@ So if the workload manifests to be applied on the managed cluster exceeds the ab
348
349
Custom Resource instances, there will be an error `... is forbidden: User "system:serviceaccount:open-cluster-management-agent:klusterlet-work-sa" cannot get resource ...`
349
350
reflected on the ManifestWork status.
350
351
351
-
To prevent this, the service account `klusterlet-work-sa` used by the work-agent needs to be given the corresponding
352
-
permissions. There are several ways:
353
-
- add permission on the managed cluster directly, we can
354
-
- aggregate the new clusterRole for your to-be-applied resources to the existing `admin` clusterRole
355
-
- OR create role/clusterRole roleBinding/clusterRoleBinding for the `klusterlet-work-sa` service account
356
-
- add permission on the hub cluster by another ManifestWork, the ManifestWork includes
357
-
- an clusterRole with label `"open-cluster-management.io/aggregate-to-work": "true"` for your to-be-applied
358
-
resources, the rules defined in the clusterRole will be aggregated to the work agent(OCM version >= v0.12.0)
359
-
- OR role/clusterRole roleBinding/clusterRoleBinding for the `klusterlet-work-sa` service account
352
+
To prevent this, the work-agent needs to be given the corresponding permissions. You can add the permission by creating
353
+
RBAC resources on the managed cluster directly, or by creating a ManifestWork including the RBAC resources on the hub
354
+
cluster, then the work-agent will apply the RBAC resources to the managed cluster. As for creating the RBAC resources,
355
+
there are several options:
356
+
357
+
- Option 1: Create clusterRoles with label `"open-cluster-management.io/aggregate-to-work": "true"` for your
358
+
to-be-applied resources, the rules defined in the clusterRoles will be aggregated to the work-agent automatically;
359
+
(Supported since OCM version >= v0.12.0, Recommended)
360
+
- Option 2: Create clusterRoles with label `rbac.authorization.k8s.io/aggregate-to-admin: "true"` for your
361
+
to-be-applied resources, the rules defined in the clusterRoles will be aggregated to the work-agent automatically;
362
+
(Deprecated since OCM version >= v0.12.0, use the Option 1 instead)
363
+
- Option 3: Create role/clusterRole roleBinding/clusterRoleBinding for the `klusterlet-work-sa` service account;
364
+
(Deprecated since OCM version >= v0.12.0, use the Option 1 instead)
360
365
361
-
Below is an example use ManifestWork to give `klusterlet-work-sa` permission for resource `machines.cluster.x-k8s.io`
366
+
Below is an example use ManifestWork to give the work-agent permission for resource `machines.cluster.x-k8s.io`
362
367
363
-
- Option 1: Use aggregated clusterRole
368
+
- Option 1: Use label `"open-cluster-management.io/aggregate-to-work": "true"` to aggregate the permission; Recommended
0 commit comments