feat: Adding more to the intros for products (#2164)

Author: yhakbar

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

@@ -2,6 +2,27 @@
 
 Gruntwork Account Factory allows you to vend new AWS accounts with best practice account baselines.
 
-For enterprise customers new accounts can be created with their own delegated infrastructure repositories. This allows developer teams to self-service deploy their own infrastructure within the bounds of IAM roles controlled in your central repository.
+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.
+
+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.
+
+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.
+
+## 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.
+
+These baselines include things like:
+
+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:
+
+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.
 
-Account Factory is built into Gruntwork Pipelines. New account requests are tracked in git as IaC, triggering Terragrunt plans and applies to provision and baseline the new account.

docs/2.0/docs/library/concepts/overview.md

@@ -2,23 +2,23 @@ import OpenTofuNotice from "/src/components/OpenTofuNotice"
 
 # Gruntwork Library
 
-Gruntwork Library (formerly known as the "Gruntwork IaC Library") is a collection of reusable infrastructure-as-code modules that enables you to deploy and manage infrastructure quickly and reliably.
+Gruntwork Library (formerly known as the "Gruntwork IaC Library") is a collection of reusable Infrastructure as Code (IaC) modules that enables you to deploy and manage infrastructure quickly and reliably.
 
-It promotes code reusability, modularity, and consistency in infrastructure deployments. Essentially, we’ve taken the thousands of hours we spent building infrastructure on AWS and condensed all that experience and code into pre-built packages you can deploy into your own infrastructure.
+It promotes code reusability, modularity, and consistency in infrastructure deployments. Essentially, we’ve taken the thousands of hours we spent building infrastructure on AWS and condensed all that experience and code into pre-built modules you can deploy into your own infrastructure.
 
 ## Two types of modules
 
 Gruntwork Library contains two types of modules:
 
 ### "Building block" modules
 
-"Building block" modules (which we call simply **modules**) are "infrastructure building blocks" authored by Gruntwork and written in Terraform. They capture a singular best-practice pattern for specific pieces of infrastructure and are designed to be both limited in scope and highly reusable. They typically represent one part of a use case you want to accomplish. For example, the `vpc-flow-logs` module does not create a VPC, it only adds the VPC Flow Logs functionality to an existing VPC.
+"Building block" modules (which we call simply **modules**) are "infrastructure building blocks" authored by Gruntwork and written in OpenTofu configuration files. They capture a singular best-practice pattern for specific pieces of infrastructure and are designed to be both limited in scope and highly reusable. They typically represent one part of a use case you want to accomplish. For example, the `vpc-flow-logs` module does not create a VPC, it only adds the VPC Flow Logs functionality to an existing VPC.
 
 To learn more, refer to [Modules](./modules)
 
 ### Service modules
 
-**Service modules** are opinionated combinations of the "building block" modules described above. They are designed to be used "off the shelf" with no need to assemble a collection of “building block” modules on your own. They typically represent a full use case. For example, the `vpc` service module deploys a VPC, VPC Flow Logs, and Network ACLs. If you agree with the opinions embedded in a service module, they’re the fastest way to deploy production-grade infrastructure.
+**Service modules** are opinionated combinations of "building block" modules described above. They are designed to be used "off the shelf" with no need to assemble a collection of “building block” modules on your own. They typically represent a full use case to solve a business problem on their own. For example, the `vpc` service module deploys a VPC, VPC Flow Logs, and Network ACLs. If you agree with the opinions embedded in a service module, they’re the fastest way to deploy production-grade infrastructure.
 
 To learn more, refer to [Service Modules](./service-modules)
 

docs/2.0/docs/overview/concepts/devopsfoundations.md

@@ -10,22 +10,24 @@ In a modern cloud infrastructure there are many component parts, ranging from th
 - A streamlined approach to implementing the component in your environment
 - A commitment by Gruntwork to update the component to match the latest best practices
 
-When you set up a new DevOps component, you also have access to guidance from Gruntwork subject matter experts to make sure the component is applied correctly in your environment.
+When you set up a new DevOps component, you also have access to guidance from Gruntwork subject matter experts to make sure the component is applied correctly in your environment, and grows in capability as your needs evolve.
 
 ## Available components
 
 There are several DevOps components available today:
 
-* [Infrastructure-Live](./infrastructure-live.md): An opinionated structure for IaC repositories that includes a set of best practices for how to structure your Terraform code to keep things DRY at enterprise scale.
-* [Pipelines](/2.0/docs/pipelines/concepts/overview.md): A complete CI/CD pipeline for infrastructure code, a set of best practices for how to structure your Terraform code, and a set of scripts for managing the pipeline.
+* [Infrastructure-Live](./infrastructure-live.md): An opinionated structure for IaC repositories that includes a set of best practices for how to structure your OpenTofu code to keep things DRY at enterprise scale.
+* [Pipelines](/2.0/docs/pipelines/concepts/overview.md): A complete CI/CD pipeline for infrastructure code, a set of best practices for how to structure your OpenTofu code, and a set of scripts for managing the pipeline.
 * [Account Factory](/2.0/docs/accountfactory/concepts/): A set of automated workflows to provision new AWS accounts and apply compliance, security and infrastructure baselines to enforce business rules across many accounts.
 * [Patcher](/2.0/docs/patcher/concepts/): Identify out of date modules across your repositories and create pull requests that both updates versions and automatically refactors code to get through breaking changes without developer intervention.
 * [Library](/2.0/docs/library/concepts/overview): Over 300,000 lines of terraform code modules that are designed to be used as building blocks for your infrastructure. From VPCs to ECS clusters to S3 buckets, the library has you covered.
 <!-- * [Catalog]  -- see DEV-628 -->
 <!-- Something about networking / transit gateway? -->
 
-All DevOps components are focused on AWS and Terraform/OpenTofu. We may add support for additional technologies in the future.
+All DevOps components are focused on Terragrunt, OpenTofu/Terraform, GitHub and AWS. We may add support for additional technologies in the future.
 
 ## Building your own components
 
 The Gruntwork DevOps components implement a meaningful portion of a modern cloud infrastructure, but not 100% of it. We expect you to build on top of the Gruntwork DevOps components by adding your own solutions to build out your full infrastructure.
+
+All of the components in DevOps Foundations are designed to be extensible and customizable. We recognize that most of our customers are developers, and we want to make sure you are empowered to easily build the solutions you need instead of relying exclusively on Gruntwork to have them pre-built in every circumstance. We encourage collaboration with our customers, and are always looking for feedback, and contributions to improve our components.

docs/2.0/docs/patcher/concepts/index.md

@@ -1,6 +1,6 @@
 # What is Gruntwork Patcher?
 
-Gruntwork Patcher helps you automatically keep your infrastructure code ([Terraform](https://www.terraform.io/) and [Terragrunt](https://terragrunt.gruntwork.io/)) up to date, including patching your code to make it work with backward incompatible module releases.
+Gruntwork Patcher helps you automatically keep your infrastructure code ([Terragrunt](https://terragrunt.gruntwork.io/) and [OpenTofu](https://opentofu.org/)) up to date, including patching your code to make it work with backward incompatible module releases.
 
 Without Patcher, the manual process of discovering updates and determining if they can be safely applied can take hours of an engineer's time for each module dependency.
 

docs/2.0/docs/pipelines/concepts/overview.md

@@ -1,11 +1,11 @@
 # What is Gruntwork Pipelines?
 
-**Gruntwork Pipelines is designed to enable your organization to deploy infrastructure changes to cloud environments with control and confidence.**
+**Gruntwork Pipelines is designed to enable your organization to deploy infrastructure changes to cloud environments simply, with control and confidence.**
 
 Having worked with hundreds of organizations to help them improve DevOps, we've discovered two truths about making changes to infrastructure:
 
 1. Teams want to control exactly how infrastructure change gets rolled out
-2. Deploying infrastructure changes is scary!
+2. Deploying infrastructure changes can be scary!
 
 To address your need for _control_, we've designed Gruntwork Pipelines to use [configuration as code](../../../reference/pipelines/configurations-as-code.md), where you use HCL (a popular alternative to JSON and YAML) to set configuration values that apply to your entire git repo, to just one environment, or to a single deployable unit of infrastructure. For example, you can specify a unique AWS authentication strategy for each deployable unit of infrastructure, one per environment, or a single strategy for the entire git repo.
 
@@ -21,9 +21,17 @@ Gruntwork is the creator and maintainer of [Terragrunt](https://terragrunt.grunt
 
 We also make updates directly to Terragrunt to support the functionality we want to see in Gruntwork Pipelines.
 
+## Reduces the complexity of CI/CD
+
+One of the things we've discovered over the years helping customers automate their infrastructure management is that it can be _very_ costly and time-consuming to build and maintain a CI/CD pipeline that can efficiently handle the complexity of infrastructure changes. Customers typically don't want to trigger an update to _all_ of their infrastructure whenever _any_ component changes, and they typically want to have related changes coordinated and rolled out correctly.
+
+A driving design goal of Gruntwork Pipelines is to allow for a minimal setup experience, followed by a very intuitive model for driving infrastructure updates. Most customers can get Pipelines configured in less than an hour, then drive all of their infrastructure changes directly via pull requests to Infrastructure as Code. Most of the time, you do not need to think about how Grutnwork Pipelines works, or how it makes decisions about what to do. You simply update your Infrastructure as Code to reflect the desired state of your infrastructure, have the pull request reviewed and merged, then Gruntwork Pipelines takes care of the rest.
+
 ## Runs directly in GitHub Actions
 
-Gruntwork Pipelines runs directly in GitHub Actions, and uses a pull request-centric workflow. This means that all information about a proposed infrastructure change is added as comments to the applicable pull request, and that you apply the infrastructure change by interacting with the pull request.
+Gruntwork Pipelines runs directly in your GitHub Actions workflows, and uses a pull request-centric workflow. This means that all information about a proposed infrastructure change is added as comments to the applicable pull request, and that you apply the infrastructure change by interacting with the pull request.
+
+This also means that Gruntwork Pipelines does not depend on Gruntwork servers to perform any `terragrunt` operations. You are fully in control over the execution of your infrastructure automation, and can customize the behavior of Gruntwork Pipelines to suit your organization's needs.
 
 Gruntwork does not need access to your secrets or state files, as these remain in GitHub Actions. At the same time, we continually push new features and updates to Gruntwork Pipelines so that your user experience, security posture, and feature set continues to improve with no effort on your part.
 
@@ -41,10 +49,10 @@ Infra-changes can involve updates to OpenTofu/Terraform or Terragrunt code, or a
 
 Sometimes users create a pull request that changes more than one file at a time. And sometimes a change to a single file affects how multiple other files will be "applied" to your live cloud account. For example, many users of Terragrunt use a pattern known as "envcommon" as a way to specify a default set of values for modules.
 
-When more than one infra-change is made at a time, we call this an _infrastructure-change set._
+When more than one infra-change is made at a time, we call this an _infrastructure-change set_.
 
 ### Pipelines actions
 
-When a user proposes to make an infra-change by opening a pull request, we want to take some kind of "action" in response to that proposed-change. For example, we may want to run a `terragrunt plan` and estimate the cost of applying this Terragrunt plan. We call these _pipelines actions._
+When a user proposes to make an infra-change by opening a pull request, we want to take some kind of "action" in response to that proposed-change. For example, we may want to run a `terragrunt plan` and estimate the cost of applying this Terragrunt plan. We call these _pipelines actions_.
 
 Gruntwork is responsible for adding support for a growing library of Pipelines Actions and we will continue to add more over time.

yarn.lock

@@ -10723,7 +10723,7 @@ plugin-image-zoom@ataft/plugin-image-zoom:
   version "1.1.0"
   resolved "https://codeload.github.com/ataft/plugin-image-zoom/tar.gz/8e1b866c79ed6d42cefc4c52f851f1dfd1d0c7de"
   dependencies:
-    medium-zoom "^1.0.8"
+    medium-zoom "^1.0.4"
 
 [email protected], points-on-curve@^0.2.0:
   version "0.2.0"
@@ -12725,9 +12725,8 @@ trough@^2.0.0:
   resolved "https://registry.yarnpkg.com/trough/-/trough-2.2.0.tgz#94a60bd6bd375c152c1df911a4b11d5b0256f50f"
   integrity sha512-tmMpK00BjZiUyVyvrBK7knerNgmgvcV/KLVyuma/SC+TQN167GrMRciANTz09+k3zW8L8t60jWO1GpfkZdjTaw==
 
-ts-commons@gruntwork-io/ts-commons#5.3.1, ts-commons@gruntwork-io/ts-commons#v5.3.1:
+ts-commons@gruntwork-io/ts-commons#v5.3.1:
   version "5.3.1"
-  uid a02d6c5003b699e411520c5a180ab5d3264cbf88
   resolved "git+ssh://[email protected]/gruntwork-io/ts-commons.git#a02d6c5003b699e411520c5a180ab5d3264cbf88"
 
 ts-dedent@^2.2.0: