• BU Features
    • False
    • None
    • False
    • None

      Note: Doc team updates the current version of the documentation and the
      two previous versions (n-2), but we address *only high-priority, or
      customer-reported issues* for -2 releases in support.
      Describe the changes in the doc and link to your dev story:

      1. - [X] Mandatory: Add the required version to the Fix version/s field.

      2. - [X] Mandatory: Choose the type of documentation change or review.

      • [X] We need to update to an existing topic
      • [ ] We need to add a new document to an existing section
      • [ ] We need a whole new section; this is a function not
        documented before and doesn't belong in any current section
      • [ ] We need an Operator Advisory review and approval
      • [ ] We need a z-Stream (Errata) Advisory and Release note for
        MCE and/or ACM

      3. - [X] Mandatory: Find the link to where the documentation update
      should go and add it to the recommended changes. You can either use the
      published doc or the staged repo for this step:

      Note: As the feature and doc is understood, this recommendation may
      change. If this is new documentation, link to the section where you think
      it should be placed.

      Customer Portal published version

      https://docs.redhat.com/en/documentation/red_hat_advanced_cluster_management_for_kubernetes/2.12

      Doc staged repo within the ACM Workspace:
      https://github.com/stolostron/rhacm-docs

      The only current doc I found for ClusterPermission is here however ClusterPermission is not only for Gitops, it offers a general way of giving permission on managed clusters.
      https://docs.redhat.com/en/documentation/red_hat_advanced_cluster_management_for_kubernetes/2.11/html/gitops/gitops-overview#creating_a_cluster_permission

      Creating a ClusterPermission using existing roles

      In the previous section, new roles will be created with the ClusterPermission resource. However, the ClusterPermission resource can also be used with existing roles if new roles are not needed. In this example, we are going to create a ClusterPermission using existing roles or cluster role.

      Example YAML:

      apiVersion: rbac.open-cluster-management.io/v1alpha1
      kind: ClusterPermission
      metadata:
        name: clusterpermission-existing-role-sample
      spec:
        roleBindings:
          - name: default-rb-cluster1
            namespace: default
            roleRef:
              apiGroup: rbac.authorization.k8s.io
              kind: ClusterRole
              name: argocd-application-controller-1
            subject:
              namespace: openshift-gitops
              kind: ServiceAccount
              name: sa-sample-existing
          - name: kubevirt-rb-cluster1
            namespace: kubevirt
            roleRef:
              apiGroup: rbac.authorization.k8s.io
              kind: Role
              name: argocd-application-controller-2
            subject:
              apiGroup: rbac.authorization.k8s.io
              kind: User
              name: user1
        clusterRoleBinding:
            name: crb-cluster1-argo-app-con-3
            roleRef:
              apiGroup: rbac.authorization.k8s.io
              kind: ClusterRole
              name: argocd-application-controller-3
            subject:
              apiGroup: rbac.authorization.k8s.io
              kind: Group
              name: group1 

      In the above example, we are no longer specifying a `spec.role` or `spec.clusterRole` field. The `roleRef` field under `spec.roleBindings[n]` and `spec.clusterRoleRinding` refers to existing roles and cluster role on the managed cluster. Also an optional `name` field can be used under `spec.roleBindings[n]` and `spec.clusterRoleRinding` to create the RoleBinding resource using a custom name instead of the default ClusterPermission name.

       

      4. - [ ] Mandatory for GA content:

      • [ ] Add steps, the diff, known issue, and/or other important
        conceptual information in the following space:
      • [ ] *Add Required access level *(example, *Cluster
        Administrator*) for the user to complete the task:
      • [ ] Add verification at the end of the task, how does the user
        verify success (a command to run or a result to see?)

      5. - [ ] Mandatory for bugs: What is the diff? Clearly define what the
      problem is, what the change is, and link to the current documentation. Only
      use this for a documentation bug.

              jberger@redhat.com Jacob Berger
              fxiang@redhat.com Feng Xiang
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

                Created:
                Updated: