Use consistent format for placeholders in Open ID section

content/actions/security-for-github-actions/security-hardening-your-deployments/about-security-hardening-with-openid-connect.md

@@ -182,7 +182,7 @@ The subject claim includes the environment name when the job references an envir
 
 You can configure a subject that filters for a specific [environment](/actions/deployment/targeting-different-environments/managing-environments-for-deployment) name. In this example, the workflow run must have originated from a job that has an environment named `Production`, in a repository named `octo-repo` that is owned by the `octo-org` organization:
 
-* Syntax: `repo:<orgName/repoName>:environment:<environmentName>`
+* Syntax: `repo:ORG-NAME/REPO-NAME:environment:ENVIRONMENT-NAME`
 * Example: `repo:octo-org/octo-repo:environment:Production`
 
 #### Filtering for `pull_request` events
@@ -191,7 +191,7 @@ The subject claim includes the `pull_request` string when the workflow is trigge
 
 You can configure a subject that filters for the [`pull_request`](/actions/using-workflows/events-that-trigger-workflows#pull_request) event. In this example, the workflow run must have been triggered by a `pull_request` event in a repository named `octo-repo` that is owned by the `octo-org` organization:
 
-* Syntax: `repo:<orgName/repoName>:pull_request`
+* Syntax: `repo:ORG-NAME/REPO-NAME:pull_request`
 * Example: `repo:octo-org/octo-repo:pull_request`
 
 #### Filtering for a specific branch
@@ -200,7 +200,7 @@ The subject claim includes the branch name of the workflow, but only if the job
 
 You can configure a subject that filters for a specific branch name. In this example, the workflow run must have originated from a branch named `demo-branch`, in a repository named `octo-repo` that is owned by the `octo-org` organization:
 
-* Syntax:  `repo:<orgName/repoName>:ref:refs/heads/branchName`
+* Syntax:  `repo:ORG-NAME/REPO-NAME:ref:refs/heads/BRANCH-NAME`
 * Example: `repo:octo-org/octo-repo:ref:refs/heads/demo-branch`
 
 #### Filtering for a specific tag
@@ -209,7 +209,7 @@ The subject claim includes the tag name of the workflow, but only if the job doe
 
 You can create a subject that filters for specific tag. In this example, the workflow run must have originated with a tag named `demo-tag`, in a repository named `octo-repo` that is owned by the `octo-org` organization:
 
-* Syntax: `repo:<orgName/repoName>:ref:refs/tags/<tagName>`
+* Syntax: `repo:ORG-NAME/REPO-NAME:ref:refs/tags/TAG-NAME`
 * Example: `repo:octo-org/octo-repo:ref:refs/tags/demo-tag`
 
 ### Configuring the subject in your cloud provider
@@ -304,7 +304,7 @@ Customizing the claims results in a new format for the entire `sub` claim, which
 
 {% note %}
 
-**Note**: The `sub` claim uses the shortened form `repo` (for example, `repo:<orgName/repoName>`) instead of `repository` to reference the repository.
+**Note**: The `sub` claim uses the shortened form `repo` (for example, `repo:ORG-NAME/REPO-NAME`) instead of `repository` to reference the repository.
 
 {% endnote %}
 
@@ -368,7 +368,7 @@ The following example template combines the requirement of a specific reusable w
 
 {% data reusables.actions.use-request-body-api %}
 
-This example also demonstrates how to use `"context"` to define your conditions. This is the part that follows the repository in the [default `sub` format](/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect#example-subject-claims). For example, when the job references an environment, the context contains: `environment:<environmentName>`.
+This example also demonstrates how to use `"context"` to define your conditions. This is the part that follows the repository in the [default `sub` format](/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect#example-subject-claims). For example, when the job references an environment, the context contains: `environment:ENVIRONMENT-NAME`.
 
 ```json
 {
@@ -382,7 +382,7 @@ This example also demonstrates how to use `"context"` to define your conditions.
 
 In your cloud provider's OIDC configuration, configure the `sub` condition to require that claims must include specific values for `repo`, `context`, and `job_workflow_ref`.
 
-This customization template requires that the `sub` uses the following format: `repo:<orgName/repoName>:environment:<environmentName>:job_workflow_ref:<reusableWorkflowPath>`.
+This customization template requires that the `sub` uses the following format: `repo:ORG-NAME/REPO-NAME:environment:ENVIRONMENT-NAME:job_workflow_ref:REUSABLE-WORKFLOW-PATH`.
 For example: `"sub": "repo:octo-org/octo-repo:environment:prod:job_workflow_ref:octo-org/octo-automation/.github/workflows/oidc.yml@refs/heads/main"`
 
 #### Example: Granting access to a specific repository

content/actions/security-for-github-actions/security-hardening-your-deployments/configuring-openid-connect-in-amazon-web-services.md

@@ -72,7 +72,7 @@ Edit the trust policy, adding the `sub` field to the validation conditions. For
 }
 ```
 
-If you use a workflow with an environment, the `sub` field must reference the environment name: `repo:OWNER/REPOSITORY:environment:NAME`. For more information, see "[AUTOTITLE](/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect#understanding-the-oidc-token)."
+If you use a workflow with an environment, the `sub` field must reference the environment name: `repo:ORG-NAME/REPO-NAME:environment:ENVIRONMENT-NAME`. For more information, see "[AUTOTITLE](/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect#understanding-the-oidc-token)."
 
 {% data reusables.actions.oidc-deployment-protection-rules %}
 
@@ -124,9 +124,9 @@ To update your workflows for OIDC, you will need to make two changes to your YAM
 
 The `aws-actions/configure-aws-credentials` action receives a JWT from the {% data variables.product.prodname_dotcom %} OIDC provider, and then requests an access token from AWS. For more information, see the AWS [documentation](https://github.com/aws-actions/configure-aws-credentials).
 
-* `<example-bucket-name>`: Add the name of your S3 bucket here.
-* `<role-to-assume>`: Replace the example with your AWS role.
-* `<example-aws-region>`: Add the name of your AWS region here.
+* `BUCKET-NAME`: Add the name of your S3 bucket here.
+* `AWS-REGION`: Add the name of your AWS region here.
+* `ROLE-TO-ASSUME`: Replace this with your AWS role. For example, `arn:aws:iam::1234567890:role/example-role`
 
 ```yaml copy
 # Sample workflow to access AWS resources when workflow is tied to branch
@@ -135,8 +135,8 @@ name: AWS example workflow
 on:
   push
 env:
-  BUCKET_NAME : "<example-bucket-name>"
-  AWS_REGION : "<example-aws-region>"
+  BUCKET_NAME : "BUCKET-NAME"
+  AWS_REGION : "AWS-REGION"
 # permission can be added at job level or workflow level
 permissions:
   id-token: write   # This is required for requesting the JWT
@@ -150,7 +150,7 @@ jobs:
       - name: configure aws credentials
         uses: aws-actions/configure-aws-credentials@v3
         with:
-          role-to-assume: arn:aws:iam::1234567890:role/example-role
+          role-to-assume: ROLE-TO-ASSUME
           role-session-name: samplerolesession
           aws-region: {% raw %}${{ env.AWS_REGION }}{% endraw %}
       # Upload a file to AWS s3

content/actions/security-for-github-actions/security-hardening-your-deployments/configuring-openid-connect-in-google-cloud-platform.md

@@ -59,9 +59,8 @@ The `google-github-actions/auth` action receives a JWT from the {% data variable
 
 This example has a job called `Get_OIDC_ID_token` that uses actions to request a list of services from GCP.
 
-* `<example-workload-identity-provider>`: Replace this with the path to your identity provider in GCP. For example, `projects/<example-project-id>/locations/global/workloadIdentityPools/<name-of-pool>/providers/<name-of-provider>`
-* `<example-service-account>`: Replace this with the name of your service account in GCP.
-* `<project-id>`: Replace this with the ID of your GCP project.
+* `WORKLOAD-IDENTITY-PROVIDER`: Replace this with the path to your identity provider in GCP. For example, `projects/example-project-id/locations/global/workloadIdentityPools/name-of-pool/providers/name-of-provider`
+* `SERVICE-ACCOUNT`: Replace this with the name of your service account in GCP.
 
 This action exchanges a {% data variables.product.prodname_dotcom %} OIDC token for a Google Cloud access token, using [Workload Identity Federation](https://cloud.google.com/iam/docs/workload-identity-federation).
 
@@ -86,8 +85,8 @@ jobs:
       uses: 'google-github-actions/auth@v0.3.1'
       with:
           create_credentials_file: 'true'
-          workload_identity_provider: '<example-workload-identity-provider>'
-          service_account: '<example-service-account>'
+          workload_identity_provider: 'WORKLOAD-IDENTITY-PROVIDER'
+          service_account: 'SERVICE-ACCOUNT'
     - id: 'gcloud'
       name: 'gcloud'
       run: |-

content/actions/security-for-github-actions/security-hardening-your-deployments/configuring-openid-connect-in-hashicorp-vault.md

@@ -124,10 +124,10 @@ The `hashicorp/vault-action` action receives a JWT from the {% data variables.pr
 
 This example demonstrates how to create a job that requests a secret from HashiCorp Vault.
 
-* `<Vault URL>`: Replace this with the URL of your HashiCorp Vault.
-* `<Vault Namespace>`: Replace this with the Namespace you've set in HashiCorp Vault. For example: `admin`.
-* `<Role name>`: Replace this with the role you've set in the HashiCorp Vault trust relationship.
-* `<Secret-Path>`: Replace this with the path to the secret you're retrieving from HashiCorp Vault. For example: `secret/data/production/ci npmToken`.
+* `VAULT-URL`: Replace this with the URL of your HashiCorp Vault.
+* `VAULT-NAMESPACE`: Replace this with the Namespace you've set in HashiCorp Vault. For example: `admin`.
+* `ROLE-NAME`: Replace this with the role you've set in the HashiCorp Vault trust relationship.
+* `SECRET-PATH`: Replace this with the path to the secret you're retrieving from HashiCorp Vault. For example: `secret/data/production/ci npmToken`.
 
 ```yaml copy
 jobs:
@@ -141,10 +141,10 @@ jobs:
         uses: hashicorp/vault-action@v2.4.0
           with:
             method: jwt
-            url: <Vault URL>
-            namespace: <Vault Namespace - HCP Vault and Vault Enterprise only>
-            role: <Role name>
-            secrets: <Secret-Path>
+            url: VAULT-URL
+            namespace: VAULT-NAMESPACE # HCP Vault and Vault Enterprise only
+            role: ROLE-NAME
+            secrets: SECRET-PATH
 
       - name: Use secret from Vault
         run: |
@@ -156,7 +156,7 @@ jobs:
 **Note**:
 
 * If your Vault server is not accessible from the public network, consider using a self-hosted runner with other available Vault [auth methods](https://www.vaultproject.io/docs/auth). For more information, see "[AUTOTITLE](/actions/hosting-your-own-runners/managing-self-hosted-runners/about-self-hosted-runners)."
-* `<Vault Namespace>` must be set for a Vault Enterprise (including HCP Vault) deployment. For more information, see [Vault namespace](https://www.vaultproject.io/docs/enterprise/namespaces).
+* `VAULT-NAMESPACE` must be set for a Vault Enterprise (including HCP Vault) deployment. For more information, see [Vault namespace](https://www.vaultproject.io/docs/enterprise/namespaces).
 
 {% endnote %}
 
@@ -180,9 +180,9 @@ jobs:
           with:
             exportToken: true
             method: jwt
-            url: <Vault URL>
-            role: <Role name>
-            secrets: <Secret-Path>
+            url: VAULT-URL
+            role: ROLE-NAME
+            secrets: SECRET-PATH
 
       - name: Use secret from Vault
         run: |
@@ -193,7 +193,7 @@ jobs:
         if: always()
         run: |
           curl -X POST -sv -H "X-Vault-Token: {% raw %}${{ env.VAULT_TOKEN }}{% endraw %}" \
-            <Vault URL>/v1/auth/token/revoke-self
+            VAULT-URL/v1/auth/token/revoke-self
 ```
 
 ## Further reading