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

Author: yhakbar

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

@@ -2,6 +2,8 @@
 
 Gruntwork Account Factory employs a defense-in-depth approach to secure workflows across both GitHub and GitLab platforms. This document outlines the controls Pipelines uses to ensure that only infrastructure written in code and approved by a reviewer can be deployed to your AWS accounts.
 
+Account Factory relies on Pipelines to drive infrastructure changes via GitOps workflows, so make sure to read the [Pipelines security controls](/2.0/docs/pipelines/architecture/security-controls) for more details on how Pipelines secures workflows.
+
 ## Least privilege principle
 
 Pipelines adheres to the principle of least privilege, granting only the necessary permissions for infrastructure actions.

docs/2.0/docs/pipelines/architecture/audit-logs.md

@@ -1,20 +1,23 @@
 # Audit Logs
 
-Gruntwork Pipelines provides an audit log that records which user performed specific operations in your AWS accounts as a result of a [Pipelines Action](/2.0/docs/pipelines/architecture/actions.md).
+For certain cloud environments (for now, only AWS), Gruntwork Pipelines provides an audit log that records which user performed specific operations in your AWS accounts as a result of a [Pipelines Action](/2.0/docs/pipelines/architecture/actions.md). Pipelines does this via integration with native tooling for the cloud provider.
+
+## AWS
 
 Accessing AWS environments from a CI/CD system often involves assuming temporary credentials using OpenID Connect (OIDC). For platform-specific documentation, see:
+
 - [GitHub OIDC Configuration](https://docs.github.com/en/actions/deployment/security-hardening-your-deployments/configuring-openid-connect-in-amazon-web-services)
 - [GitLab OIDC Configuration](https://docs.gitlab.com/ee/ci/cloud_services/aws/)
 
 Shared credentials can complicate tracking who performed specific actions in AWS accounts. Gruntwork Pipelines addresses this challenge by using [AWS CloudTrail](https://aws.amazon.com/cloudtrail/) with a naming convention that includes context from the triggering Pipelines Action. This approach associates every API operation performed by Pipelines with a username and a specific pull request or branch, enabling your security team to efficiently investigate access-related issues and analyze individual user actions.
 
 ## How it works
 
-Gruntwork Pipelines creates an audit log that tracks which user performed what action in which AWS account. It does this by setting the [AWS STS](https://docs.aws.amazon.com/STS/latest/APIReference/welcome.html) session name to include the initiating username, the Pipelines name, and the merge request/pull request or branch that triggered the action. Logging is handled through [AWS CloudTrail](https://aws.amazon.com/cloudtrail/), where session names appear in the `User name` field, making it easy to identify which user performed an action. For information on locating logs, see [where you can find logs](#where-you-can-find-logs) and [querying data](#querying-data).
+Gruntwork Pipelines creates an audit log that tracks which user performed what action in which AWS account. It does this by setting the [AWS STS](https://docs.aws.amazon.com/STS/latest/APIReference/welcome.html) session name to include the initiating username, the Pipelines name, and the merge/pull request or branch that triggered the action. Logging is handled through [AWS CloudTrail](https://aws.amazon.com/cloudtrail/), where session names appear in the `User name` field, making it easy to identify which user performed an action. For information on locating logs, see [where you can find logs](#where-you-can-find-logs) and [querying data](#querying-data).
 
 ### What gets logged
 
-Logs are generated for all operations performed by Gruntwork Pipelines across every AWS account. These logs leverage [AWS STS](https://docs.aws.amazon.com/STS/latest/APIReference/welcome.html) session names to clearly label sessions with the username that requested the change and the associated merge request/pull request or branch.
+Logs are generated for all operations performed by Gruntwork Pipelines in AWS across every AWS account. These logs leverage [AWS STS](https://docs.aws.amazon.com/STS/latest/APIReference/welcome.html) session names to clearly label sessions with the username that requested the change and the associated merge/pull request or branch.
 
 Each CloudTrail event linked to API calls from Pipelines [Actions](/2.0/docs/pipelines/architecture/actions.md) includes the session name in the `userIdentity` field. For example, if the user `SomeUserInYourOrg` initiated the 123rd request in your repository, the `userIdentity` field in a corresponding CloudTrail event would provide details such as the following.
 
@@ -58,13 +61,17 @@ By combining this data with a [query service](#querying-data), you can analyze t
 Pipelines employs a naming scheme that integrates the user who triggered the Pipelines [Action](/2.0/docs/pipelines/architecture/actions.md) along with the request or branch that initiated the action. The AWS STS session name is formatted as follows:
 `<UserName>-via-GWPipelines@(PR-<RequestNumber>|<branch name>)`.
 
-#### For merge request/pull request events
+#### For merge/pull request events
+
 When Pipelines runs in response to a request event (opened, updated, or reopened), the session name includes the user who made the most recent commit on the branch and the request number. For instance:
+
 - If the user `SomeUserInYourOrg` created request number `123`, the session name would be:
   `SomeUserInYourOrg-via-GWPipelines@PR-123`.
 
 #### For merged requests
+
 When Pipelines runs after a request is merged, the session name reflects the user who performed the merge and the deploy branch name (e.g., `main`). For example:
+
 - If the user `SomeUserInYourOrg` merged a request to the branch `main`, the session name would be:
   `SomeUserInYourOrg-via-GWPipelines@main`.
 

docs/2.0/docs/pipelines/architecture/ci-workflows.md

@@ -21,6 +21,7 @@ jobs:
 include:
   - component: gitlab.com/gruntwork-io/pipelines-workflows/pipelines@3
 ```
+
 </TabItem>
 </Tabs>
 ## Workflow versioning
@@ -42,33 +43,32 @@ If you [fork the Gruntwork Workflows](https://docs.gruntwork.io/2.0/docs/pipelin
 
 The `pipelines-workflows` repository includes the following reusable workflows:
 
-- `pipelines-drift-detection.yml` - Used for [Pipelines Drift Detection](/2.0/docs/pipelines/concepts/drift-detection) in all repositories with Drift Detection installed.
-- `pipelines-root.yml` - The core Pipelines workflow for the `infrastructure-live-root` repository, providing core plan/apply functionality and account vending.
-- `pipelines-unlock.yml` - Used to manually unlock state files in all repositories.
+- `pipelines-drift-detection.yml` - (Enterprise only) Used for [Pipelines Drift Detection](/2.0/docs/pipelines/concepts/drift-detection) in all repositories with Drift Detection installed.
+- `pipelines-root.yml` - (Account Factory only) The core Pipelines workflow for the `infrastructure-live-root` repository, providing core plan/apply functionality and account vending.
+- `pipelines-unlock.yml` - (AWS only) Used to manually unlock state files in all repositories.
 - `pipelines.yml` - The core Pipelines workflow for `infrastructure-live-access-control` and delegated repositories, supporting plan/apply operations.
 
+If you are using [Gruntwork Account Factory](/2.0/docs/accountfactory/overview), the following workflows are typically present:
 
-In your repositories, the following workflows are typically present:
-
-#### infrastructure-live-root
+### infrastructure-live-root
 
 - `account-factory.yml` - A standalone workflow independent of `pipelines-workflows`.
 - `pipelines-drift-detection.yml` (Enterprise only) - Uses the Gruntwork `pipelines-drift-detection.yml` workflow.
 - `pipelines-unlock.yml` - Uses the Gruntwork `pipelines-unlock.yml` workflow.
 - `pipelines.yml` - Uses `pipelines-root.yml`.
-#### infrastructure-live-access-control
+
+### infrastructure-live-access-control
 
 - `pipelines-drift-detection.yml` (Enterprise only) - Uses the Gruntwork `pipelines-drift-detection.yml` workflow.
-- `pipelines-unlock.yml` - Uses the Gruntwork `pipelines-unlock.yml` workflow.
+- `pipelines-unlock.yml` - Uses the Gruntwork `pipelines-unlock.yml` workflow (AWS only).
 - `pipelines.yml` - Uses `pipelines.yml`.
 
-#### infrastructure-live-delegated ([Vended Delegated Repositories](/2.0/docs/accountfactory/guides/delegated-repositories))
+### infrastructure-live-delegated ([Vended Delegated Repositories](/2.0/docs/accountfactory/guides/delegated-repositories))
 
 - `pipelines-drift-detection.yml` - Uses the Gruntwork `pipelines-drift-detection.yml` workflow.
 - `pipelines-unlock.yml` - Uses the Gruntwork `pipelines-unlock.yml` workflow.
 - `pipelines.yml` - Uses `pipelines.yml`.
 
-
 </TabItem>
 <TabItem value="GitLab" label="GitLab">