docs: Adding note for self-hosted GitLab instance

Author: yhakbar

docs/2.0/docs/pipelines/installation/addingexistinggitlabrepo.mdx

@@ -3,17 +3,32 @@
 import Tabs from '@theme/Tabs';
 import TabItem from '@theme/TabItem';
 import PersistentCheckbox from '/src/components/PersistentCheckbox';
+import CustomizableValue from '/src/components/CustomizableValue';
 
 This guide provides comprehensive instructions for integrating [Gruntwork Pipelines](https://gruntwork.io/products/pipelines/) into an existing GitLab project with Infrastructure as Code (IaC). This is designed for Gruntwork customers who want to add Pipelines to their current infrastructure projects for streamlined CI/CD management.
 
 To configure Gruntwork Pipelines in an existing GitLab project, complete the following steps (which are explained in detail below):
 
-1. **Plan your Pipelines setup** by identifying all environments and cloud accounts/subscriptions you need to manage.
-2. **Bootstrap core infrastructure** in accounts/subscriptions that don't already have the required OIDC and state management resources.
-3. **Configure SCM access** using [machine users](/2.0/docs/pipelines/installation/viamachineusers) with appropriate Personal Access Tokens (PATs).
-4. **Create `.gruntwork` HCL configurations** to tell Pipelines how to authenticate and organize your environments.
-5. **Create `.gitlab-ci.yml`** to configure your GitLab CI/CD pipeline.
-6. **Commit and push** your changes to activate Pipelines.
+1. **(If using a self-hosted GitLab instance) Ensure OIDC configuration and JWKS are publicly accessible.**
+2. **Plan your Pipelines setup** by identifying all environments and cloud accounts/subscriptions you need to manage.
+3. **Bootstrap core infrastructure** in accounts/subscriptions that don't already have the required OIDC and state management resources.
+4. **Configure SCM access** using [machine users](/2.0/docs/pipelines/installation/viamachineusers) with appropriate Personal Access Tokens (PATs).
+5. **Create `.gruntwork` HCL configurations** to tell Pipelines how to authenticate and organize your environments.
+6. **Create `.gitlab-ci.yml`** to configure your GitLab CI/CD pipeline.
+7. **Commit and push** your changes to activate Pipelines.
+
+## Ensure OIDC configuration and JWKS are publicly accessible
+
+This step only applies if you are using a self-hosted GitLab instance that is not accessible from the public internet. If you are using GitLab.com or a self-hosted instance that is publicly accessible, you can skip this step.
+
+1. [Follow GitLab's instructions](https://docs.gitlab.com/ci/cloud_services/aws/#configure-a-non-public-gitlab-instance) for hosting your OIDC configuration and JWKS in a public location (e.g. S3 Bucket). This is necessary for both Gruntwork and the AWS OIDC provider to access the GitLab OIDC configuration and JWKS when authenticating JWT's generated by your custom instance.
+2. Note the <CustomizableValue id="ISSUER_URL" /> (stored as `ci_id_tokens_issuer_url` in your `gitlab.rb` file per GitLab's instructions) generated above for reuse in the next steps.
+
+:::note Progress Checklist
+
+<PersistentCheckbox id="configure-oidc-jwks" label="(If using a self-hosted GitLab instance) Configure OIDC and JWKS to be publicly accessible." />
+
+:::
 
 ## Prerequisites
 
@@ -268,6 +283,23 @@ boilerplate \
   --non-interactive
 ```
 
+If you're using a self-hosted GitLab instance, you'll want to make sure the issuer is set correctly when calling Boilerplate.
+
+```bash
+boilerplate \
+  --template-url 'github.com/gruntwork-io/terragrunt-scale-catalog//templates/boilerplate/aws/gitlab/account?ref=v1.0.0' \
+  --output-folder . \
+  --var 'AccountName=dev' \
+  --var 'GitLabGroupName=acme' \
+  --var 'GitLabRepoName=infrastructure-live' \
+  --var 'GitLabInstanceURL=https://gitlab.com' \
+  --var 'AWSAccountID=123456789012' \
+  --var 'AWSRegion=us-east-1' \
+  --var 'StateBucketName=my-state-bucket' \
+  --var 'Issuer=$$ISSUER_URL$$' \
+  --non-interactive
+```
+
 You can also choose to store these values in a YAML file and pass it to Boilerplate using the `--var-file` flag.
 
 ```yaml title="vars.yml"

docs/2.0/docs/pipelines/installation/addinggitlabrepo.mdx

@@ -3,14 +3,29 @@
 import Tabs from '@theme/Tabs';
 import TabItem from '@theme/TabItem';
 import PersistentCheckbox from '/src/components/PersistentCheckbox';
+import CustomizableValue from '/src/components/CustomizableValue';
 
 To configure Gruntwork Pipelines in a new GitLab project, complete the following steps (which are explained in detail below):
 
-1. Create an `infrastructure-live` project.
-2. Configure machine user tokens for GitLab access, or ensure that the appropriate machine user tokens are set up as project or organization secrets.
-3. Create `.gruntwork` HCL configurations to tell Pipelines how to authenticate in your environments.
-4. Create `.gitlab-ci.yml` to tell your GitLab CI/CD pipeline how to run your pipelines.
-5. Commit and push your changes to your project.
+1. (If using a self-hosted GitLab instance) Ensure OIDC configuration and JWKS are publicly accessible.
+2. Create an `infrastructure-live` project.
+3. Configure machine user tokens for GitLab access, or ensure that the appropriate machine user tokens are set up as project or organization secrets.
+4. Create `.gruntwork` HCL configurations to tell Pipelines how to authenticate in your environments.
+5. Create `.gitlab-ci.yml` to tell your GitLab CI/CD pipeline how to run your pipelines.
+6. Commit and push your changes to your project.
+
+## Ensure OIDC configuration and JWKS are publicly accessible
+
+This step only applies if you are using a self-hosted GitLab instance that is not accessible from the public internet. If you are using GitLab.com or a self-hosted instance that is publicly accessible, you can skip this step.
+
+1. [Follow GitLab's instructions](https://docs.gitlab.com/ci/cloud_services/aws/#configure-a-non-public-gitlab-instance) for hosting your OIDC configuration and JWKS in a public location (e.g. S3 Bucket). This is necessary for both Gruntwork and the AWS OIDC provider to access the GitLab OIDC configuration and JWKS when authenticating JWT's generated by your custom instance.
+2. Note the <CustomizableValue id="ISSUER_URL" /> (stored as `ci_id_tokens_issuer_url` in your `gitlab.rb` file per GitLab's instructions) generated above for reuse in the next steps.
+
+:::note Progress Checklist
+
+<PersistentCheckbox id="configure-oidc-jwks" label="(If using a self-hosted GitLab instance) Configure OIDC and JWKS to be publicly accessible." />
+
+:::
 
 ## Creating the infrastructure-live project
 
@@ -167,6 +182,23 @@ boilerplate \
   --non-interactive
 ```
 
+If you're using a self-hosted GitLab instance, you'll want to make sure the issuer is set correctly when calling Boilerplate.
+
+```bash
+boilerplate \
+  --template-url 'github.com/gruntwork-io/terragrunt-scale-catalog//templates/boilerplate/aws/gitlab/infrastructure-live?ref=v1.0.0' \
+  --output-folder . \
+  --var 'AccountName=dev' \
+  --var 'GitLabGroupName=acme' \
+  --var 'GitLabRepoName=infrastructure-live' \
+  --var 'GitLabInstanceURL=https://gitlab.com' \
+  --var 'AWSAccountID=123456789012' \
+  --var 'AWSRegion=us-east-1' \
+  --var 'StateBucketName=my-state-bucket' \
+  --var 'Issuer=$$ISSUER_URL$$' \
+  --non-interactive
+```
+
 :::
 
 :::note Progress Checklist