docs: Breaking down installation guide to avoid assuming AWS (#2759)

* docs: Nested AWS into `Authenticating to the Cloud`

* Fix build issues.

* fix: Addressing markdown lints

* fix: Reworked components page into execution flow page

* docs: Migrating out AWS specific security controls for Pipelines to Account Factory

* docs: Updating `ci-workflows.md` with call outs for Account Factory stuff

* docs: Addressing PR feedback

* fix: Adding abbreviation to dictionary

* docs: Nested AWS into `Authenticating to the Cloud`

* Fix build issues.

* docs: Moving AWS Landing Zone prereq to Account Factory

docs: Adjusting redirects for moving AWS Landing Zone to Account Factory

* docs: Restructured initial setup to avoid assuming AWS

docs: Splitting up different cloud providers

wip: Progress on stacks

* feat: Set up full Azure installation guide

* fix: Fixing the checkbox ids

* fix: Fixing up some paper cuts in the top-level setup & installation docs

* fix: Fixing path to new prerequisites for Account Factory

* chore: Making sure this is pinned to `v4` before I forget

* fix: Cleaning up Azure guide

* docs: Adding AWS docs

* fix: Cleaning up language for sidebar on GitHub

* docs: WIP progress on adding Pipelines to an existing repo

* docs: More troubleshooting guidance

* docs: Adjusting language in `Setup & Installation`

* docs: Adjusting logic for repo setup

* fix: Cutting down on steps for adding a new repo

* feat: Adding instructions for additional accounts and subscriptions

* fix: Preventing ToC from breaking by using h3 tags

* fix: Adding existing guide docs

* fix: Redoing GitLab install instructions for parity with GitHub

* fix: Removing unnecessary GitLab content

* docs: Adding existing repository instructions for GitLab

* docs: Adding note for self-hosted GitLab instance

* fix: Fixing URL for pipelines machine users install

* fix: Satisfying spellcheck

* fix: Fixing auth links

* fix: Addressing easy to address PR feedback

---------

Co-authored-by: Josh Padnick <[email protected]>

Author: yhakbar

custom-dictionary.txt

@@ -62,3 +62,7 @@ hcledit
 self-hosting
 infrachanges
 Entra
+GLMU
+myprodsa
+azuread
+mysa

docs/2.0/docs/accountfactory/architecture/security-controls.md

@@ -79,7 +79,7 @@ Requires the following tokens be created:
 - `INFRA_ROOT_WRITE_TOKEN`: Fine-grained PAT with read/write access to infrastructure repositories
 - `ORG_REPO_ADMIN_TOKEN`: Fine-grained PAT with admin access for repository management
 
-See [Setup via Machine Users](/2.0/docs/pipelines/installation/viamachineusers.md) for more details.
+See [Setup via Machine Users](/2.0/docs/pipelines/installation/viamachineusers) for more details.
 
 </TabItem>
 <TabItem value="gitlab" label="GitLab">

docs/2.0/docs/pipelines/installation/addingnewrepo.md renamed to docs/2.0/docs/accountfactory/installation/addingnewrepo.md

@@ -1,6 +1,6 @@
-# Initial Setup
+# Adding Account Factory to a new repository
 
-To configure Gruntwork Pipelines in a new GitHub repository, complete the following steps:
+To configure Gruntwork Account Factory in a new GitHub repository, the following steps are required (and will be explained in detail below):
 
 1. Create your `infrastructure-live-root` repository using Gruntwork's GitHub template.
 2. Configure the Gruntwork.io GitHub App to authorize your `infrastructure-live-root` repository, or ensure that the appropriate machine user tokens are set up as repository or organization secrets.
@@ -23,7 +23,7 @@ Navigate to the template repository and select **Use this template** -> **Create
 
 Use the Gruntwork.io GitHub App to [add the repository as an Infra Root repository](/2.0/docs/pipelines/installation/viagithubapp#configuration).
 
-If using the [machine user model](/2.0/docs/pipelines/installation/viamachineusers.md), ensure the `INFRA_ROOT_WRITE_TOKEN` (and `ORG_REPO_ADMIN_TOKEN` for enterprise customers) is added to the repository as a secret or configured as an organization secret.
+If using the [machine user model](/2.0/docs/pipelines/installation/viamachineusers), ensure the `INFRA_ROOT_WRITE_TOKEN` (and `ORG_REPO_ADMIN_TOKEN` for enterprise customers) is added to the repository as a secret or configured as an organization secret.
 
 ## Updating the Bootstrap Workflow
 
@@ -47,5 +47,5 @@ Each of your repositories will contain a Bootstrap Pull Request. Follow the inst
 
 :::info
 
-The bootstrapping pull requests include pre-configured files, such as a `mise.toml` file that specifies versions of OpenTofu and Terragrunt. Ensure you review and update these configurations to align with your organization's requirements.
+The bootstrapping pull requests include pre-configured files, such as a `.mise.toml` file that specifies versions of OpenTofu and Terragrunt. Ensure you review and update these configurations to align with your organization's requirements.
 :::

docs/2.0/docs/accountfactory/installation/index.md

@@ -2,23 +2,20 @@
 
 ## Overview
 
-Account Factory is automatically integrated into [new Pipelines root repositories](/2.0/docs/pipelines/installation/addingnewrepo) during the bootstrapping process.
+Account Factory is automatically integrated into [new Pipelines root repositories](/2.0/docs/accountfactory/installation/addingnewrepo) during the bootstrapping process.
 
 By default, Account Factory includes the following components:
 
 - 📋 An HTML form for generating workflow inputs: `.github/workflows/account-factory-inputs.html`
-  
+
 - 🏭 A workflow for generating new requests: `.github/workflows/account-factory.yml`
-  
+
 - 🗃️ A root directory for tracking account requests: `_new-account-requests`
-  
+
 - ⚙️ A YAML file for tracking account names and IDs: `accounts.yml`
 
 For detailed instructions on using these components, refer to the [Vending a New AWS Account Guide](/2.0/docs/accountfactory/guides/vend-aws-account).
 
 ## Configuring account factory
 
 Account Factory is fully operational for vending new accounts without requiring any configuration changes. However, a [comprehensive reference for all configuration options is available here](/2.0/reference/accountfactory/configurations), allowing you to customize values and templates for generating Infrastructure as Code (IaC) for new accounts.
-
- 
-

docs/2.0/docs/pipelines/installation/prerequisites/awslandingzone.md renamed to docs/2.0/docs/accountfactory/prerequisites/awslandingzone.md

@@ -1,11 +1,10 @@
 import CustomizableValue from '/src/components/CustomizableValue';
 
- 
 # Landing Zone
 
 ## Overview
 
-The Landing Zone component establishes an initial best-practice AWS multi-account setup.
+The Landing Zone component establishes an initial best-practice AWS multi-account setup for use with Gruntwork Account Factory.
 
 ## Extending AWS Control Tower
 
@@ -242,16 +241,15 @@ Complete the following steps to prepare for Gruntwork Account Factory:
 
       3. Switch to the `Users` tab, select your management user from the list and click **Next**
 
-      4.  Select `AWSAdministratorAccess` from the list of Permission Sets, then click **Next**
+      4. Select `AWSAdministratorAccess` from the list of Permission Sets, then click **Next**
 
-      5.  Click `Submit` to finish assigning access to your user
+      5. Click `Submit` to finish assigning access to your user
 
 ## Next steps
 
 Now that Control Tower is configured, consider these next steps:
+
 - [Set up IAM Identity Center](https://docs.aws.amazon.com/singlesignon/latest/userguide/get-started-choose-identity-source.html) for access control.
 - [Apply required controls or SCPs](https://docs.aws.amazon.com/controltower/latest/userguide/controls.html).
 - [Install Gruntwork Pipelines](/2.0/docs/pipelines/installation/viagithubapp).
 - [Set up Gruntwork Account Factory](/2.0/docs/accountfactory/installation).
-
-

docs/2.0/docs/overview/getting-started/index.md

@@ -7,7 +7,7 @@ Create your Gruntwork account and invite your team members to access Gruntwork r
 
 <PersistentCheckbox id="install-df-1" label="Gruntwork Account Ready" />
 
-### Step 2: [Set up a Landing Zone](/2.0/docs/pipelines/installation/prerequisites/awslandingzone)
+### Step 2: [Set up a Landing Zone](/2.0/docs/accountfactory/prerequisites/awslandingzone)
 
 Follow Gruntwork's AWS Landing Zone walkthrough to implement a best-practice multi-account setup, ready for use with DevOps Foundations.
 

docs/2.0/docs/pipelines/architecture/execution-flow.md

@@ -10,6 +10,6 @@ The orchestrator analyzes each infrastructure change in a pull request or git co
 
 ## Executor
 
-The executor receives as inputs a pipeline action (e.g. `terragrunt plan`) and a specific unit of infrastructure that has been changed (e.g. `/path/to/changed-unit/terragrunt.hcl`) and executes the specified action on the specified unit. 
+The executor receives as inputs a pipeline action (e.g. `terragrunt plan`) and a specific unit of infrastructure that has been changed (e.g. `/path/to/changed-unit/terragrunt.hcl`) and executes the specified action on the specified unit.
 
 For example, when responding to a `ModuleUpdated` event for `/some/unit/terragrunt.hcl`, the executor might execute a `terragrunt apply` on `/some/unit/terragrunt.hcl`. Or when responding to `AccountsAdded` events on merge, the executor may create a follow-up pull request in the `infrastructure-live-root` repository to include additional IaC code for baselining the newly added accounts.

docs/2.0/docs/pipelines/architecture/index.md

@@ -8,7 +8,7 @@ Outside of the main binary, Pipelines has several other components that work tog
 
 By design, customers run the binary as part of their CI/CD pipelines (e.g. GitHub Actions, GitLab CI, etc.). As such, Gruntwork provides out-of-the-box CI/CD configurations for supported platforms when customers sign up for Gruntwork Pipelines.
 
-We likewise provide CI/CD configurations for [Gruntwork Account Factory](https://docs.gruntwork.io/account-factory/overview). 
+We likewise provide CI/CD configurations for [Gruntwork Account Factory](https://docs.gruntwork.io/account-factory/overview).
 
 When using Gruntwork Pipelines without Gruntwork Account Factory, customers are responsible for configuring their repositories to use the appropriate CI/CD configuration for that platform (see [Adding Pipelines to an Existing Repository](/2.0/docs/pipelines/installation/addingexistingrepo) for more information). This code is typically fairly minimal, and the majority of the work is done by reusable workflows made available by Gruntwork, and the binary itself.
 

docs/2.0/docs/pipelines/architecture/security-controls.md

@@ -47,7 +47,7 @@ Requires that the following tokens are created:
 - `INFRA_ROOT_WRITE_TOKEN`: Fine-grained PAT with read/write access to infrastructure repositories
 - `ORG_REPO_ADMIN_TOKEN`: Fine-grained PAT with admin access for repository management
 
-See [Setup via Machine Users](/2.0/docs/pipelines/installation/viamachineusers.md) for more details.
+See [Setup via Machine Users](/2.0/docs/pipelines/installation/viamachineusers) for more details.
 
 </TabItem>
 <TabItem value="gitlab" label="GitLab">

docs/2.0/docs/pipelines/concepts/cloud-auth/index.md

@@ -17,9 +17,9 @@ Cloud authentication in Pipelines is built on the principle of least privilege a
 
 Currently, Pipelines supports authentication to the following cloud providers:
 
-- [AWS](./aws.mdx) - AWS authentication using OIDC
-- [Azure](./azure.md) - Azure authentication using OIDC
-- [Custom](./custom.md) - Custom authentication you can implement yourself
+- [AWS](/2.0/docs/pipelines/concepts/cloud-auth/aws) - AWS authentication using OIDC
+- [Azure](/2.0/docs/pipelines/concepts/cloud-auth/azure) - Azure authentication using OIDC
+- [Custom](/2.0/docs/pipelines/concepts/cloud-auth/custom) - Custom authentication you can implement yourself
 
 ## Security Best Practices