WIP - Single install docs that simplify, streamline install process for both manual or cli

website/docs/enterprise/getting-started/install-enterprise-cli.mdx

@@ -118,7 +118,7 @@ For SSH, `private key path` & `private key password`. For HTTPS, `username` and
 
 #### Verify Entitlement
 
-Weave GitOps Enterprise Entitlement is your obtained license to use our product. The Entitlements file is a Kubernetes secret that contains your licence.
+Weave GitOps Enterprise Entitlement is your obtained license to use our prodct. The Entitlements file is a Kubernetes secret that contains your licence.
 `Bootstrapping` checks that the secret exists on the management cluster, and that it is valid will check if it has valid content and the entitlement is not expired.
 To get the entitlement secret please contact *sales@weave.works*, then apply it on your management cluster with the name `weave-gitops-enterprise-credentials` under `flux-system` namespace. 
 

website/docs/enterprise/getting-started/install-enterprise-getting-started-advanced-topics.mdx

@@ -0,0 +1,204 @@
+---
+title: Advanced Topics
+hide_title: true
+toc_max_heading_level: 4
+pagination_prev: enterprise/getting-started/install-enterprise-getting-started-harden
+pagination_next: enterprise/getting-started/install-enterprise-getting-started-expand
+
+---
+
+import Tabs from "@theme/Tabs";
+import TabItem from "@theme/TabItem";
+import TierLabel from "@site/docs/_components/TierLabel";
+import AlphaWarning from "../../_components/_alpha_warning.mdx";
+import CurlCodeBlock from "../../_components/CurlCodeBlock";
+import oauthBitbucket from '/img/oauth-bitbucket.png';
+import oauthAzureDevOps from '/img/oauth-azure-devops.png';
+import oauthAzureDevOpsSuccess from '/img/oauth-azure-devops-success.png';
+
+# Advanced Topics
+
+## OIDC
+
+### Customization
+
+For some OIDC configurations, you may need to customise the requested [scopes](https://openid.net/specs/openid-connect-core-1_0.html#ScopeClaims) or [claims](https://openid.net/specs/openid-connect-core-1_0.html#Claims).
+
+The `oidcUsernamePrefix` and `oidcGroupsPrefix` work in the same way as the Kubernetes [kube-apiserver](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-apiserver/) command-line options, if you need them for Kubernetes, you will likely need them here.
+
+### Scopes
+
+By default, the following scopes are requested: "openid","offline_access","email","groups".
+
+The "openid" scope is **mandatory** for OpenID auth and will be added if not provided. The "email" and "groups" scopes are commonly used as unique identifiers in organisations.
+
+"offline_access" allows us to refresh OIDC tokens to keep login sessions alive for as long as a refresh token is valid. You can, however, change the defaults.
+```sh
+kubectl create secret generic oidc-auth \
+  --namespace flux-system \
+  --from-literal=issuerURL=$oidc-issuer-url \
+  --from-literal=clientID=$client-id \
+  --from-literal=clientSecret=$client-secret \
+  --from-literal=redirectURL=redirect-url \
+  --from-literal=tokenDuration=token-duration \
+  --from-literal=customScopes=custom,scopes
+```
+The format for the `customScopes` key is a comma-separated list of scopes to request. In this case, "custom", "scopes", and "openid" would be requested.
+
+### Claims
+
+By default, the following claims are parsed from the OpenID [ID Token](https://openid.net/specs/openid-connect-core-1_0.html#CodeIDToken) "email" and "groups". These are presented as the `user` and `groups` when WGE communicates with your Kubernetes API server.
+
+This is equivalent to [configuring](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#configuring-the-api-server) your `kube-apiserver` with `--oidc-username-claim=email --oidc-groups-claim=groups`.
+
+Again, you can configure these from the `oidc-auth` `Secret`.
+
+```sh
+kubectl create secret generic oidc-auth \
+  --namespace flux-system \
+  --from-literal=issuerURL=oidc-issuer-url \
+  --from-literal=clientID=client-id \
+  --from-literal=clientSecret=client-secret \
+  --from-literal=redirectURL=redirect-url \
+  --from-literal=tokenDuration=token-duration \
+  --from-literal=claimUsername=sub \
+  --from-literal=claimGroups=groups
+```
+There are two separate configuration keys. You can override them separately. They should match your `kube-apiserver` configuration.
+
+## Cluster User
+
+### Update Username or Password
+
+To change either the username or the password, recreate the `cluster-user-auth`
+with the new details.
+
+Only one Cluster User can be created this way. To add more users, enable an OIDC provider.
+
+### Update Permissions
+
+If required, the permissions can be expanded with the `rbac.additionalRules` field in the
+[Helm Chart](../../references/helm-reference.md).
+
+Follow the instructions in the next section in order to configure RBAC correctly.
+
+### Remove It
+
+To remove the Cluster User as a login method, set the following values in the
+[Helm Chart](../../references/helm-reference.md):
+
+```yaml
+#
+adminUser:
+  create: false
+#
+additionalArgs:
+- --auth-methods=oidc
+#
+```
+:::caution If you are disabling an already existing Cluster User
+
+If you are disabling an already existing Cluster User, you will need to
+manually delete the Kubernetes Secret and any User Roles that were created on
+the cluster.
+
+:::
+
+## User Permissions
+
+This section discusses the [Kubernetes permissions](https://kubernetes.io/docs/reference/access-authn-authz/rbac/)
+needed by Weave GitOps application users and groups. At a minimum, a User should be bound to a Role in the `flux-system` namespace—which is where
+Flux stores its resources by default—with the following permissions:
+
+```yaml
+rules:
+  # Flux Resources
+  - apiGroups: ["source.toolkit.fluxcd.io"]
+    resources: [ "buckets", "helmcharts", "gitrepositories", "helmrepositories", "ocirepositories" ]
+    verbs: [ "get", "list", "watch", "patch" ]
+
+  - apiGroups: ["kustomize.toolkit.fluxcd.io"]
+    resources: [ "kustomizations" ]
+    verbs: [ "get", "list", "watch", "patch" ]
+
+  - apiGroups: ["helm.toolkit.fluxcd.io"]
+    resources: [ "helmreleases" ]
+    verbs: [ "get", "list", "watch", "patch" ]
+
+  - apiGroups: [ "notification.toolkit.fluxcd.io" ]
+    resources: [ "providers", "alerts" ]
+    verbs: [ "get", "list", "watch", "patch" ]
+
+  - apiGroups: ["infra.contrib.fluxcd.io"]
+    resources: ["terraforms"]
+    verbs: [ "get", "list", "watch", "patch" ]
+
+  # Read access for all other Kubernetes objects
+  - apiGroups: ["*"]
+    resources: ["*"]
+    verbs: [ "get", "list", "watch" ]
+```
+
+For a wider scope, the User can be bound to a ClusterRole with the same set.
+
+On top of this you can add other permissions to view WGE resources like `GitOpsSets` and `Templates`.
+
+### Flux Resources
+
+The following table lists resources that Flux works with directly.
+
+| API Group                      | Resources                                                               | Permissions      |
+| ------------------------------ | ----------------------------------------------------------------------- | ---------------- |
+| kustomize.toolkit.fluxcd.io    | kustomizations                                                          | get, list, patch |
+| helm.toolkit.fluxcd.io         | Helm Releases                                                            | get, list, patch |
+| source.toolkit.fluxcd.io       | buckets, Helm charts, Git repositories, Helm repositories, OCI repositories | get, list, patch |
+| notification.toolkit.fluxcd.io | providers, alerts                                                       | get, list        |
+| infra.contrib.fluxcd.io        | [Terraform](https://github.com/weaveworks/tf-controller)                                                             | get, list, patch |
+
+Weave GitOps needs to be able to query the [CRDs](https://fluxcd.io/docs/components/) that Flux uses before it can accurately display Flux state. The
+`get` and `list` permissions facilitate this.
+
+The `patch` permissions are used for two features: to suspend and resume
+reconciliation of a resource by modifying the 'spec' of a resource,
+and to force reconciliation of a resource by modifying resource annotations. These features work in the same way that `flux suspend`,
+`flux resume`, and `flux reconcile` does on the CLI.
+
+### Resources Managed via Flux
+
+| API Group                 | Resources                                                                      | Permissions      |
+|---------------------------|--------------------------------------------------------------------------------|------------------|
+| ""                        | configmaps, secrets, pods, services, persistent volumes, persistent volume claims | get, list, watch |
+| apps                      | deployments, replica sets, stateful sets                                         | get, list, watch |
+| batch                     | jobs, cron jobs                                                                 | get, list, watch |
+| autoscaling               | horizontal pod autoscalers                                                       | get, list, watch |
+| rbac.authorization.k8s.io | roles, cluster roles, rolebindings, cluster role bindings                         | get, list, watch |
+| networking.k8s.io         | ingresses                                                                      | get, list, watch |
+
+Weave GitOps reads basic resources so that it can monitor the effect that Flux has
+on what's running.
+
+Reading `secrets` enables Weave GitOps to monitor the state of Helm releases
+as that's where it stores the [state by default](https://helm.sh/docs/faq/changes_since_helm2/#secrets-as-the-default-storage-driver).
+For clarity this these are the Helm release objects _not_ the Flux HelmRelease
+resource (which are dealt with by the earlier section).
+
+### Feedback from Flux
+
+Flux communicates the status of itself primarily via events.
+These events will show when reconciliations start and stop, whether they're successful,
+and information as to why they're not.
+
+## Customise the UI
+
+### Login
+
+The label of the OIDC button on the login screen is configurable via a feature flag environment variable.
+This can give your users a more familiar experience when logging in.
+
+Adjust the configuration in the Helm `values.yaml` file or the `spec.values` section of the Weave GitOps `HelmRelease` resource:
+
+```yaml
+extraEnvVars:
+  - name: WEAVE_GITOPS_FEATURE_OIDC_BUTTON_LABEL
+    value: "Login with ACME"
+```

website/docs/enterprise/getting-started/install-enterprise-getting-started-expand.mdx

@@ -0,0 +1,148 @@
+---
+title: Step 3 - Expand Capabilities
+hide_title: true
+toc_max_heading_level: 4
+pagination_prev: enterprise/getting-started/install-enterprise-getting-started-harden
+---
+
+import Tabs from "@theme/Tabs";
+import TabItem from "@theme/TabItem";
+import TierLabel from "@site/docs/_components/TierLabel";
+import AlphaWarning from "../../_components/_alpha_warning.mdx";
+import CurlCodeBlock from "../../_components/CurlCodeBlock";
+import oauthBitbucket from '/img/oauth-bitbucket.png';
+import oauthAzureDevOps from '/img/oauth-azure-devops.png';
+import oauthAzureDevOpsSuccess from '/img/oauth-azure-devops-success.png';
+
+# Step 3 - Expand Capabilities
+
+:::info What to expect
+You are a Platform Engineer onboarded to Weave GitOps Enterprise that wants to either explore or to
+setup WGE capabilities beyond Flux. Use this guide to help you doing so.At the end of it, your Platform would be ready to start onboarding your Developers.
+:::
+
+## Enable Cluster Management via Cluster API
+
+<Tabs groupId="clusterManagement" defaultValue="manual">
+<TabItem value="cli" label="cli">
+
+:::caution
+
+Not yet supported but planned as part of https://github.com/weaveworks/weave-gitops-enterprise/issues/3698
+
+:::
+
+</TabItem>
+<TabItem value="manual" label="manual">
+
+Our user guide provides two pathways to deployment:
+
+- One path that shows you how to manage clusters [without adding Cluster API](managing-clusters-without-capi.mdx). Join a cluster by hooking WGE to it, then install an application on that cluster.
+- An **optional** path that shows you how to create, provision, and delete your first API cluster with [EKS/CAPA](../cluster-management/deploying-capa-eks.mdx).
+
+Just click the option you want to get started with, and let's go.
+
+</TabItem>
+</Tabs>
+
+## Enable Policy via Weave Policy
+
+To install [Policy Agent](../../policy/intro.mdx) follow any of the following approaches:
+
+<Tabs groupId="policy agent" defaultValue="cli">
+<TabItem value="cli" label="cli">
+
+Installing Weave Policy Agent is possible using CLI interactive session questions or via `components-extra` flag as shown:
+
+```bash
+ # install Policy Agent alongside Weave GitOps Enterprise
+ gitops bootstrap --components-extra="policy-agent"
+```
+
+:::note
+The controller will be installed with the default values. To customize controller values, Please edit the corresponding values file and reconcile
+:::
+
+For more information about the CLI configurations, check the below sections [here](#cli-configurations)
+
+</TabItem>
+<TabItem value="manual" label="manual">
+
+[Policy agent](../../policy/intro.mdx) comes packaged with the WGE chart. To install it, set the following values:
+
+- `values.policy-agent.enabled`: set to true to install the agent with WGE
+- `values.policy-agent.config.accountId`: organization name, used as identifier
+- `values.policy-agent.config.clusterId`: unique identifier for the cluster
+
+Commit and push all the files
+
+```bash
+git add clusters/management/weave-gitops-enterprise.yaml
+git commit -m "Add Policy Agent"
+git push
+```
+
+Flux will reconcile the helm-release and WGE will be deployed into the cluster. You can check the `flux-system` namespace to verify all pods are running.
+
+</TabItem>
+</Tabs>
+
+## Enable Infrastructure Management via Tf-Controller
+
+To install [Policy Agent](../../policy/intro.mdx) follow any of the following approaches:
+
+<Tabs groupId="tf-controller" defaultValue="cli">
+<TabItem value="cli" label="cli">
+
+Installing TF-Controller is possible using CLI interactive session questions or via `components-extra` flag as shown:
+
+```bash
+ # Install TF-Controller alongside Weave GitOps Enterprise
+ gitops bootstrap --components-extra="tf-controller"
+```
+
+:::note
+The controller will be installed with the default values. To customize controller values, Please edit the corresponding values file and reconcile
+:::
+
+For more information about the CLI configurations, check the below sections [here](#cli-configurations)
+
+</TabItem>
+<TabItem value="manual" label="manual">
+
+You could install TF-Controller in two steps:
+1. Install the controller via its [getting started](../../../terraform/get-started-terraform).
+2. Enable it Weave GitOps Enterprise by adding `enableTerraformUI` values to `true`:
+
+```yaml
+---
+apiVersion: helm.toolkit.fluxcd.io/v2beta1
+kind: HelmRelease
+metadata:
+  name: weave-gitops-enterprise
+  namespace: flux-system
+spec:
+  values:
+    ...
+    enableTerraformUI: true
+```
+
+Commit and push all the files
+
+```bash
+git add clusters/management/weave-gitops-enterprise.yaml
+git commit -m "Add Tf-Controller"
+git push
+```
+
+Flux will reconcile the helm-release and WGE will be deployed into the cluster. You can check the `flux-system` namespace to verify all pods are running.
+
+</TabItem>
+</Tabs>
+
+## Next Steps
+
+Congratulations! You have successfully installed Weave GitOps Enterprise and enabled its capabilities.
+
+Next steps for you are to start onboarding your Developers and operate the platform.
+