-
Epic
-
Resolution: Done
-
Blocker
-
None
-
ManifestWork - support for dynamic identity authentication and authorization
-
False
-
None
-
False
-
To Do
-
ACM-944 - Workload Delivery and Scheduling
Epic Goal
- Enhance ManifestWork to use different authorization and authentication prior to execution of the manifest resources
Issue: https://github.com/open-cluster-management-io/work/issues/124
Enhancement proposal: https://github.com/open-cluster-management-io/enhancements/pull/41
Why is this important?
There can be different actors using the work api to distribute resource from the hub cluster. Currently the work agent has the cluster-admin access to the managed cluster which means that every hub users with write access to the work resources will be able to dispatch any resources to the managed cluster. This can be a security hole for OCM, e.g. one can apply/overwrite some cluster-scoped configuration to the managed cluster which potentially break/halt the cluster. Hence, we need a way to clarify the owner identity/role of the "ManifestWork" before it takes effect so that we can explicitly check whether that owner has sufficient permission in the managed cluster.
https://github.com/open-cluster-management-io/enhancements/blob/d36a0bf9547e3c64b3f78265a2611887a61b8ce6/enhancements/sig-architecture/34-work-executor-group/README.md#auditing-the-api-request-history-from-work-agentAuditing the API request history from work agent
Currently all the API requests raised by work agent in the managed cluster are from a fixed service account ("open-cluster-management-agent/klusterlet-work-sa" under the default installation). However in some cases, we need to clarify the source/owner identity of the ManifestWork resource so that we can record the api audits in a finer granularity. This will be helpful for the managed cluster's admin to be capable of knowing "who is operating that ManifestWork from the hub cluster".
Scenarios
- ...
Acceptance Criteria
- CI - MUST be running successfully with tests automated
- Release Technical Enablement - Provide necessary release enablement details and documents.
- ...
Dependencies (internal and external)
- ...
Previous Work (Optional):
- …
Open questions::
- …
Done Checklist
- CI - CI is running, tests are automated and merged.
- Release Enablement <link to Feature Enablement Presentation>
- DEV - Upstream code and tests merged: <link to meaningful PR or GitHub Issue>
- DEV - Upstream documentation merged: <link to meaningful PR or GitHub Issue>
- DEV - Downstream build attached to advisory: <link to errata>
- QE - Test plans in Polarion: <link or reference to Polarion>
- QE - Automated tests merged: <link or reference to automated tests>
- DOC - Downstream documentation merged: <link to meaningful PR>