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. - [ ] 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

https://docs.redhat.com/en/documentation/red_hat_advanced_cluster_management_for_kubernetes/2.11/html/gitops/gitops-overview#secret-gitops

go to Gitops section, update this part

1.2.3. GitOps token 

• in the first paragraph

remove the last sentence, 

When a user is given administrator access to a GitOps namespace to perform application lifecycle operations, the user also gains access to this secret and admin level to the managed cluster.

change it to:

By default, the service account application-manager with the cluster admin permissions on the managed cluster is used to generate the GitOps cluster secret in the GitOps instance server namespace (openshift-gitops by default)

• remove the second paragraph, 

If this is not desired, instead of binding the user to the namespace-scoped admin role, use a more restrictive custom role with permissions required to work with application resources that can be created and used to bound the user. See the following ClusterRole example:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole

change it to:

If this is not desired, users can create a service account with customized permissions on the managed cluster for generating the GitOps Cluster secret in the GitOps instance server namespace (openshift-gitops by default). For more details, refer to 

1.7. Creating a customized service account for Argo CD push model

• [X] We need to add a new document to an existing section

go to Gitops section, update this part

1.2.2. Registering managed clusters to GitOps

At the end, add this new part.

Prior to ACM 2.12, ACM gitopsCluster only supports to register OCP clusters to GitOps. This has been enhanced since ACM 2.12. ACM gitopsCluster now supports to register Non-OCP clusters to GitOps. Complete the following steps to register an Non-OCP cluster to GitOps cluster.

1. validate the api server url available in the Non-OCP managedCluster spec

% oc get managedclusters eks-1
NAME    HUB ACCEPTED   MANAGED CLUSTER URLS                                                      JOINED   AVAILABLE   AGE
eks-1   true           https://5E336C922AB16684A332C10535B8D407.gr7.us-east-2.eks.amazonaws.com  True     True        37m 

2. Manually update the api server URL to the managedCluster spec if it is empty

The api server URL of all types of Non-OCP managedCluster is rendered automatically since ACM 2.12 when using the two import mode

• Enter your Server URL and API token for the existing cluster
• Kubeconfig

If the api server URL of one ManagedCluster is empty, it could happen in the following cases:

• The Non-OCP cluster was imported to ACM hub prior to ACM 2.12.
• The Non-OCP cluster was imported to ACM hub in ACM 2.12 via the import mode "Run import commands manually"

To update the api server URL to the Non-OCP managedCluster spec

• edit the managedCluster spec, fill in the api server url like this

% oc edit managedclusters eks-1
spec:
  managedClusterClientConfigs:
  - caBundle: ZW1wdHlDQWJ1bmRsZQo=                =====> this is a fake base64 encoded string "emptyCABundle"
    url: https://5E336C922AB16684A332C10535B8D407.gr7.us-east-2.eks.amazonaws.com  ===> api server URL of the Non-OCP cluster
 

• save the changes, validate the api server is reported correctly now

% oc get managedclusters eks-1
NAME     HUB ACCEPTED  MANAGED CLUSTER URLS                                                      JOINED   AVAILABLE   AGE
eks-1    true          https://5E336C922AB16684A332C10535B8D407.gr7.us-east-2.eks.amazonaws.com  True     True        37m 

3. Now the cluster secret should be generated into the openshift-gitops NS. And the gitopsCluster resource status should report successful. Users are able to deploy application resources to the Non-OCP cluster via openshift gitops UI

• [ ] 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. - [ ] *Mandatory: *Use the following link to open the doc and find where the
documentation update should go. Note: As the feature and doc is
understood and developed, this placement decision may change:

• Published doc: https://access.redhat.com/documentation/en-us/red_hat_advanced_cluster_management_for_kubernetes/2.10
• Source: https://github.com/stolostron/rhacm-docs

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?)

• [ ] Add link to dev story here:

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.