Uploaded image for project: 'Red Hat Advanced Cluster Management'
  1. Red Hat Advanced Cluster Management
  2. ACM-1292

ManifestWork - support for dynamic identity authentication and authorization

XMLWordPrintable

      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?

      • Separate the identity and its held permission for the work agent

      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

      1. ...

      Acceptance Criteria

      • CI - MUST be running successfully with tests automated
      • Release Technical Enablement - Provide necessary release enablement details and documents.
      • ...

      Dependencies (internal and external)

      1. ...

      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>

            showeimer Sho Weimer
            showeimer Sho Weimer
            Yuanyuan He Yuanyuan He
            Le Yang Le Yang
            Qiu Jian Qiu Jian
            Sho Weimer Sho Weimer
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated:
              Resolved: