From d8622297e47431efd7ad9a575ba246addb1b6050 Mon Sep 17 00:00:00 2001 From: itecompro <16090309+itecompro@users.noreply.github.com> Date: Sat, 31 Aug 2024 08:02:59 +0000 Subject: [PATCH] Use consistent naming for placeholders in Open ID section --- ...-security-hardening-with-openid-connect.md | 14 +++++----- ...g-openid-connect-in-amazon-web-services.md | 14 +++++----- ...openid-connect-in-google-cloud-platform.md | 9 +++---- ...uring-openid-connect-in-hashicorp-vault.md | 26 +++++++++---------- 4 files changed, 31 insertions(+), 32 deletions(-) diff --git a/content/actions/security-for-github-actions/security-hardening-your-deployments/about-security-hardening-with-openid-connect.md b/content/actions/security-for-github-actions/security-hardening-your-deployments/about-security-hardening-with-openid-connect.md index 68c4d0c44de8..07e11574f9ba 100644 --- a/content/actions/security-for-github-actions/security-hardening-your-deployments/about-security-hardening-with-openid-connect.md +++ b/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::environment:` +* 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::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::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::ref:refs/tags/` +* 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:`) 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:`. +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::environment::job_workflow_ref:`. +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 diff --git a/content/actions/security-for-github-actions/security-hardening-your-deployments/configuring-openid-connect-in-amazon-web-services.md b/content/actions/security-for-github-actions/security-hardening-your-deployments/configuring-openid-connect-in-amazon-web-services.md index 709508ca9f7a..23d6756363de 100644 --- a/content/actions/security-for-github-actions/security-hardening-your-deployments/configuring-openid-connect-in-amazon-web-services.md +++ b/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). -* ``: Add the name of your S3 bucket here. -* ``: Replace the example with your AWS role. -* ``: 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 : "" - 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 diff --git a/content/actions/security-for-github-actions/security-hardening-your-deployments/configuring-openid-connect-in-google-cloud-platform.md b/content/actions/security-for-github-actions/security-hardening-your-deployments/configuring-openid-connect-in-google-cloud-platform.md index c5511612f935..1e51b56164b6 100644 --- a/content/actions/security-for-github-actions/security-hardening-your-deployments/configuring-openid-connect-in-google-cloud-platform.md +++ b/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. -* ``: Replace this with the path to your identity provider in GCP. For example, `projects//locations/global/workloadIdentityPools//providers/` -* ``: Replace this with the name of your service account in GCP. -* ``: 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: '' - service_account: '' + workload_identity_provider: 'WORKLOAD-IDENTITY-PROVIDER' + service_account: 'SERVICE-ACCOUNT' - id: 'gcloud' name: 'gcloud' run: |- diff --git a/content/actions/security-for-github-actions/security-hardening-your-deployments/configuring-openid-connect-in-hashicorp-vault.md b/content/actions/security-for-github-actions/security-hardening-your-deployments/configuring-openid-connect-in-hashicorp-vault.md index 8fd07e492fe0..8fd65d5e51d6 100644 --- a/content/actions/security-for-github-actions/security-hardening-your-deployments/configuring-openid-connect-in-hashicorp-vault.md +++ b/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. -* ``: Replace this with the URL of your HashiCorp Vault. -* ``: Replace this with the Namespace you've set in HashiCorp Vault. For example: `admin`. -* ``: Replace this with the role you've set in the HashiCorp Vault trust relationship. -* ``: 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: - namespace: - role: - secrets: + 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)." -* `` 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: - role: - secrets: + 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 %}" \ - /v1/auth/token/revoke-self + VAULT-URL/v1/auth/token/revoke-self ``` ## Further reading