Merge branch main into pipelines-section-4

Author: ZachGoldberg

custom-dictionary.txt

@@ -44,6 +44,8 @@ mimecast
 slugified
 dlist
 DEPENDENCYID
+subfolders
 MTTR
 terrapatch
-Terrapatch
+Terrapatch
+KodeKloud

docs/2.0/docs/accountfactory/architecture/index.md

@@ -2,21 +2,21 @@
 
 ## Overview
 
-Account Factory builds upon Gruntwork's [AWS Control Tower Multi Account Factory](/reference/modules/terraform-aws-control-tower/control-tower-multi-account-factory/) and Pipelines to provide automated account creation, baselining, and managed IAM policies.
+Account Factory uses Gruntwork's [AWS Control Tower Multi Account Factory](/reference/modules/terraform-aws-control-tower/control-tower-multi-account-factory/) and Pipelines to automate account creation, baselining, and IAM policy management.
 
-In your `infrastructure-live-root` repository, the `_new-account-requests` directory acts as input for the Gruntwork Control Tower Module. This module runs within your management account and uses AWS Control Tower to provision new accounts and manage existing ones.
+In your `infrastructure-live-root` repository, the `_new-account-requests` directory acts as input for the Gruntwork Control Tower Module. The module, functioning within your management account, employs AWS Control Tower to efficiently provision new accounts and manage existing ones.
 
 Pipelines tracks each provisioned account as a new base directory containing Terragrunt units in your `infrastructure-live-root` repository.
 
 ![Architecture Overview Diagram](/img/accountfactory/architecture.png)
 
-## Account Vending
+## Account vending
 
-Account Vending starts when the Account Factory Workflow generates a Pull Request against `infrastructure-live-root`, adding a file to the `_new-account-requests` directory. Pipelines detects these new account requests and runs terragrunt plan/apply commands on the `control-tower-multi-account-factory` unit in the management account.
+Account vending begins when the Account Factory Workflow creates a pull request in `infrastructure-live-root`, adding a file to the `_new-account-requests` directory. Pipelines detects these new account requests and runs terragrunt plan/apply commands on the `control-tower-multi-account-factory` unit in the management account.
 
-After creating the account(s), Pipelines provisions resources, including IaC-controlled OIDC authenticated roles, which Pipelines can later use to deploy infrastructure changes within the account, and IAM policies that define the scope of changes Pipelines can deploy.
+After creating the account(s), Pipelines provisions resources such as IaC-controlled OIDC-authenticated roles. These roles, combined with IAM policies that define the scope of permissible changes, allow Pipelines to deploy infrastructure updates within the account.
 
-After adding this infrastructure to the repository, Pipelines deploys the resources into the AWS account and runs account baselines in the logs, security, and shared accounts to complete the provisioning process.
+Once this infrastructure is added to the repository, Pipelines deploys the resources into the AWS account and runs account baselines in the logs, security, and shared accounts to complete the provisioning process.
 
 ```mermaid
 sequenceDiagram
@@ -28,12 +28,14 @@ sequenceDiagram
   Infra Live Repository ->> Pipelines: Trigger Account Added
   Pipelines ->> Core Accounts: Execute terragrunt to baseline account
 ```
-## IAM Roles
+## IAM roles
 
-Each new account includes IAM policies that define the scope of changes Pipelines can make within AWS. Pipelines automatically assumes the appropriate roles for each account when changes are detected. Read about the [roles in full here](/2.0/docs/pipelines/architecture/security-controls#roles-provisioned-by-devops-foundations).
+Newly created accounts include IAM policies that define the scope of changes Pipelines is authorized to perform within AWS. Pipelines automatically assumes the necessary roles for each account when it detects changes. Detailed information about the provisioned roles can be found [here](/2.0/docs/pipelines/architecture/security-controls#roles-provisioned-by-devops-foundations).
 
-## Delegated Repositories
+## Delegated repositories
 
-Delegated repositories expand the architecture of your infrastructure estate management and provide additional access control for your infrastructure. When vending delegated repositories, Pipelines continues tracking new account security baselines in your `infrastructure-live-root` repository, while other infrastructure is tracked in a new repository specific to the account(s). Pipelines inherits new IAM roles from your `infrastructure-live-access-control` repository when deploying infrastructure in delegated repositories. This setup allows the central platform team to control what changes individual teams can make via Pipelines in the delegated repository.
+Delegated repositories enhance the architecture of infrastructure management by introducing additional layers of access control. When delegated repositories are created, Pipelines continues to manage new account security baselines within the `infrastructure-live-root` repository, while other infrastructure resources are managed in a new repository specific to the delegated account(s). 
+
+Pipelines uses IAM roles from the `infrastructure-live-access-control` repository to deploy infrastructure in these delegated repositories. This setup enables the central platform team to define and restrict the scope of changes individual teams can make via Pipelines in delegated repositories.
 
 ![Delegated Architecture Overview Diagram](/img/accountfactory/delegated-architecture.png)

docs/2.0/docs/accountfactory/concepts/delegated-repositories.md

@@ -1,21 +1,31 @@
 # Delegated Repositories
 
-:::note
-Account Factory created Delegated Repositories are only available to DevOps Foundations Enterprise customers.
+:::note 
+
+Account Factory-created Delegated Repositories are only available to DevOps Foundations Enterprise customers.
+
 :::
 
-As enterprises scale their usage of IaC across more teams there often arises a need to enforce least-privilege access control to both IaC source code and the CI/CD of that code. Gruntwork's recommendation is to leverage multiple source code repositories to create hard-boundaries that enforce least-privilege access control. The pattern we recommend consists of three parts:
+As enterprises scale their usage of IaC across multiple teams, the need to enforce least-privilege access control to both IaC source code and its CI/CD processes becomes increasingly important. Gruntwork recommends leveraging multiple source code repositories to establish clear boundaries that enforce least-privilege access control. 
+
+This approach involves a structured pattern that includes: 
+
+-  **Centralized `infrastructure-live-root` repository**  
+   Governed by the core platform team, this repository contains IaC for essential security and shared infrastructure. Examples include account creation, central logging/auditing, and networking controls (e.g., GuardDuty, SecurityHub, Macie, Transit Gateway).
+
+-  **Team-specific delegated repositories**  
+   Named using a convention such as `infrastructure-live-$TEAM_NAME`, these repositories enable individual teams to manage their own IaC. The core platform team creates delegated repositories through the Account Factory. The `infrastructure-live-access-control` system controls access to these repositories, granting teams permissions specific to their infrastructure responsibilities.
+
+By adopting this pattern, core platform teams can:
+
+- Centrally manage compliance and security infrastructure.
+- Define and enforce which teams are authorized to deploy specific types of infrastructure, ensuring alignment with architecture board-approved plans.
+- Oversee shared and per-team infrastructure tags for consistency and governance.
+- Enforce least-privilege access policies, restricting teams to access only the IaC and deployment capabilities necessary for their responsibilities.
 
-1. A single `infrastructure-live-root` repository, ideally governed by the core platform team. This repository includes IaC for security and shared infrastructure including core-account creation, central logging/auditing and networking controls (e.g. GuardDuty, SecurityHub, Macie, Transit Gateway etc.).
-1. Many _delegated_ repositories, often named using the pattern `infrastructure-live-$TEAM_NAME`, where individual teams can manage their own IaC. These repositories are created by the core platform team using the Account Factory and, via `infrastructure-live-access-control`, are granted limited permissions to manage their own infrastructure.
-Using this pattern core platform teams have the ability to:
-* Centrally manage core compliance and security infrastructure
-* Centrally manage which teams have permission to deploy different types of infrastructure, allowing their team to enforce compliance with architecture-board approved plans
-* Centrally manage tags for shared and per-team infrastructure
-* Enforce least-privilege access to IaC, restricting teams to have access only to IaC and deployment capability / role assumptions for resources that they are responsible for.
+## Delegated repository creation
 
-## Delegated Repository Creation
-Delegated repositories are optionally created by [Account Factory](/2.0/docs/accountfactory/concepts) during account creation. A delegated account vend follows the following (automated) workflow:
+Delegated repositories can be optionally created by the [Account Factory](/2.0/docs/accountfactory/concepts) as part of the account provisioning process. The workflow for vending a delegated account follows these automated steps:
 
 ```mermaid
 sequenceDiagram

docs/2.0/docs/accountfactory/concepts/index.md

@@ -1,28 +1,29 @@
 # Gruntwork Account Factory
 
-Gruntwork Account Factory allows you to vend new AWS accounts with best practice account baselines.
+Gruntwork Account Factory lets you create new AWS accounts with best-practice baselines.
 
-For enterprise customers, new accounts can be created with their own delegated Infrastructure as Code repositories automatically when vending accounts. This allows a central platform team to automate the process by which new AWS accounts are created, and delegation of select infrastructure management to particular teams.
+Enterprise customers can create dedicated Infrastructure as Code repositories for new accounts during the vending process. As a result, central platform teams can automate AWS account creation and delegate infrastructure management to individual teams for scalability and autonomy.
 
-This allows developer teams to self-service deploy their own infrastructure within the bounds of IAM roles controlled in a dedicated access control repository, allowing for a combination of least privilege access to AWS resources and self-service infrastructure deployment.
+This approach empowers developer teams to self-service deploy infrastructure within the confines of IAM roles managed in a centralized access control repository. This approach ensures least-privilege access to AWS resources while enabling flexible, self-service infrastructure deployment.
 
-Gruntwork Account Factory is built on top of Gruntwork Pipelines. New account requests are tracked in git as IaC, triggering Terragrunt plans and applies to provision and baseline the new account. This allows the provisioning of new AWS accounts to be proposed and reviewed in the same way as any other infrastructure change, via pull requests.
+Gruntwork Account Factory is built on Gruntwork Pipelines, ensuring reliable and automated account provisioning. Account creation requests are tracked in Git as Infrastructure as Code (IaC), triggering Terragrunt plans and applies to set up and baseline the accounts. By following this approach, account provisioning follows the same review and collaboration steps as other infrastructure changes, using pull requests for validation
 
 ## Account baselines
 
-When provisioning new accounts, Gruntwork Account Factory doesn't just provision new AWS accounts, but also provisions a set of customizable baseline resources within those AWS accounts that make them ready to use for production workloads immediately.
+Gruntwork Account Factory does more than create AWS accounts—it also provisions a set of customizable baseline resources to prepare accounts for immediate use in production workloads.
 
-These baselines include things like:
+These baselines include:
+
+1. Security configurations for services such as [GuardDuty](https://aws.amazon.com/guardduty/), [SecurityHub](https://aws.amazon.com/security-hub/), and [Macie](https://aws.amazon.com/macie/), following best practices.
+2. Networking configurations aligned with best practices for [AWS VPCs](https://aws.amazon.com/vpc/).
+3. IAM roles designed for least privilege access, enabling CI/CD pipelines to manage AWS resources using [GitHub OIDC](https://docs.github.com/en/actions/security-for-github-actions/security-hardening-your-deployments/configuring-openid-connect-in-amazon-web-services).
 
-1. Best practice security settings for services like [GuardDuty](https://aws.amazon.com/guardduty/), [SecurityHub](https://aws.amazon.com/security-hub/) and [Macie](https://aws.amazon.com/macie/).
-2. Best practice networking configurations for [AWS VPCs](https://aws.amazon.com/vpc/).
-3. Best practice IAM roles for least privilege access to manage AWS resources in CI/CD via [GitHub OIDC](https://docs.github.com/en/actions/security-for-github-actions/security-hardening-your-deployments/configuring-openid-connect-in-amazon-web-services).
 
 ## White glove support
 
-Enterprise customers can expect white glove support in customizing their account baselines and vending process to meet their specific requirements. This includes:
+Enterprise customers benefit from tailored white glove support to customize account baselines and the vending process according to their needs. This support includes:
 
-1. Customizing the security configurations of the account baseline, and support in validating CIS compliance on day one.
-2. Customizing the networking configurations of the account baseline, and support for [AWS Transit Gateway](https://aws.amazon.com/transit-gateway/) configurations, including setup of network inspection appliances, like [AWS Network Firewall](https://aws.amazon.com/network-firewall/).
-3. Customizing the access control for delegated infrastructure management repositories, automatically granting particular teams access to manage their Infrastructure as Code for newly vended accounts.
+1. Adjusting security configurations within the account baseline and ensuring compliance with frameworks like CIS from the outset.
+2. Modifying networking configurations in the account baseline, including support for [AWS Transit Gateway](https://aws.amazon.com/transit-gateway/) setups and integration of network inspection appliances like [AWS Network Firewall](https://aws.amazon.com/network-firewall/).
+3. Customizing access control for delegated infrastructure management repositories, automatically assigning specific teams the necessary permissions to manage IaC for newly created accounts.
 

docs/2.0/docs/accountfactory/guides/collaborators.md

@@ -6,41 +6,41 @@ Delegated Repositories are only available to DevOps Foundations Enterprise custo
 
 ## Introduction
 
-When vending new delegated repositories you can configure a list of GitHub collaborators and permissions that will be added to the new repository.
+When creating new delegated repositories, you can configure a list of GitHub collaborators and their permissions to be added to the repository.
 
 ## Understanding collaborator settings
 
-GitHub collaborators can be defined in [account-factory configuration](/2.0/reference/accountfactory/configurations#github-collaborators).
+GitHub collaborators are defined in the [account-factory configuration](/2.0/reference/accountfactory/configurations#github-collaborators).
 
-Each object in the sequence is a pair of **Team Name** and **Permission**.
+Each collaborator entry consists of a **Team Name** and a **Permission**.
 
-#### Team Name
+#### Team name
 
-Teams must exist within your GitHub Organization where Account Factory is running.
+Teams must exist within the GitHub organization where Account Factory is running.
 
-To find a Team Name navigate to your Organization, and select the Teams tab. The Team Name is the unique identifier for each team.
+To locate a Team Name, navigate to your GitHub organization and select the "Teams" tab. The Team Name is the unique identifier for each team.
 
 ![Screenshot of Team Settings showing Team Name](/img/accountfactory/team-name.png)
 
-In the above screenshot the Team Name is `platform-team`.
+In the example above, the Team Name is `platform-team`.
 
 #### Permission
 
-Permissions directly map to the <span class="external-link"><a href="https://docs.github.com/en/rest/teams/teams?apiVersion=2022-11-28#add-or-update-team-repository-permissions">GitHub Teams API</a></span>
+Permissions correspond to the <span class="external-link"><a href="https://docs.github.com/en/rest/teams/teams?apiVersion=2022-11-28#add-or-update-team-repository-permissions">GitHub Teams API</a></span>. 
 
-The options are `pull`, `triage`, `push`, `maintain`, `admin`, or a custom repository role name, if the your organization has defined any.
+Available options include `pull`, `triage`, `push`, `maintain`, `admin`, or a custom repository role name if defined by your organization.
 
 ## Adding collaborators
 
-To add a team to new delegated repositories add a new item to the collaborators block in your account factory configuration.
+To add a team to new delegated repositories, include a new entry in the `collaborators` block of your Account Factory configuration.
 
-All collaborators in each account type will be added to new repositories of that type when the repository is created. If you want to add a team to vended repositories of different types you will need to add them in multiple places.
+Collaborators for each account type are automatically added to the corresponding repositories when they are created. To give a team access to multiple repository types, add them to the configuration for each type.
 
-A common scenario is to create a team for administration that is granted access everywhere, and individual teams for each delegated repository.
+A common practice is to create an administrative team with access to all repositories, along with separate teams for each delegated repository.
 
-For example you might have the existing team `platform-admins`, and two account types `foo` and `bar`. For each account type you would then create a development team that should be granted push access to the repository `foo-devs` and `bar-devs`.
+For example, consider an organization with an administrative team called `platform-admins` and two account types, `foo` and `bar`. For each account type, you might create development teams with push access to their respective repositories, such as `foo-devs` and `bar-devs`.
 
-Your Account Factory configuration would look something like:
+The Account Factory configuration would look like this:
 
 ```yml title="./.gruntwork/config.yml"
 
@@ -62,6 +62,6 @@ pipelines:
 
 ## Updating existing repositories
 
-To update existing repositories you will need to manually make changes to the repository settings.
+To update existing repositories, you must manually modify the repository settings.
 
-See the <span class="external-link"><a href="https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/managing-repository-settings/managing-teams-and-people-with-access-to-your-repository">documentation on GitHub</a></span> for more information.
+Refer to the <span class="external-link"><a href="https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/managing-repository-settings/managing-teams-and-people-with-access-to-your-repository">GitHub documentation</a></span> for detailed instructions.