{"id":13820998,"url":"https://github.com/hashicorp/vault-action","last_synced_at":"2025-05-14T18:07:10.597Z","repository":{"id":37841174,"uuid":"209846629","full_name":"hashicorp/vault-action","owner":"hashicorp","description":"A GitHub Action that simplifies using HashiCorp Vault™ secrets as build variables.","archived":false,"fork":false,"pushed_at":"2025-05-13T15:29:41.000Z","size":2242,"stargazers_count":464,"open_issues_count":30,"forks_count":143,"subscribers_count":43,"default_branch":"main","last_synced_at":"2025-05-13T16:13:31.464Z","etag":null,"topics":["github-actions","github-actions-javascript","multiple-secrets","secrets-engine","vault","vault-action"],"latest_commit_sha":null,"homepage":"","language":"JavaScript","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"mit","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/hashicorp.png","metadata":{"files":{"readme":"README.md","changelog":"CHANGELOG.md","contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":"CODEOWNERS","security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null,"zenodo":null}},"created_at":"2019-09-20T17:33:18.000Z","updated_at":"2025-05-11T18:57:51.000Z","dependencies_parsed_at":"2024-01-03T21:26:23.009Z","dependency_job_id":"ebe11ceb-7cd6-46ca-a03f-47a33e223752","html_url":"https://github.com/hashicorp/vault-action","commit_stats":{"total_commits":235,"total_committers":36,"mean_commits":6.527777777777778,"dds":0.7489361702127659,"last_synced_commit":"1d767e395771e6ba668c266c24b01a662fca35a9"},"previous_names":[],"tags_count":48,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/hashicorp%2Fvault-action","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/hashicorp%2Fvault-action/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/hashicorp%2Fvault-action/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/hashicorp%2Fvault-action/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/hashicorp","download_url":"https://codeload.github.com/hashicorp/vault-action/tar.gz/refs/heads/main","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":254198515,"owners_count":22030966,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["github-actions","github-actions-javascript","multiple-secrets","secrets-engine","vault","vault-action"],"created_at":"2024-08-04T08:01:13.365Z","updated_at":"2025-05-14T18:07:05.587Z","avatar_url":"https://github.com/hashicorp.png","language":"JavaScript","readme":"# Vault GitHub Action\n\n---\n\n**Please note**: We take Vault's security and our users' trust very seriously. If you believe you have found a security issue in Vault or this Vault Action, _please responsibly disclose_ by contacting us at [security@hashicorp.com](mailto:security@hashicorp.com).\n\n---\n\nA helper action for easily pulling secrets from HashiCorp Vault™.\n\nNote: The Vault Github Action is a read-only action, and in general\nis not meant to modify Vault’s state.\n\n\u003c!-- TOC --\u003e\n\n- [Vault GitHub Action](#vault-github-action)\n  - [Example Usage](#example-usage)\n  - [Authentication Methods](#authentication-methods)\n    - [JWT with GitHub OIDC Tokens](#jwt-with-github-oidc-tokens)\n    - [AppRole](#approle)\n    - [Token](#token)\n    - [GitHub](#github)\n    - [JWT with OIDC Provider](#jwt-with-oidc-provider)\n    - [Kubernetes](#kubernetes)\n    - [Userpass](#userpass)\n    - [Ldap](#ldap)\n    - [Other Auth Methods](#other-auth-methods)\n    - [Custom Path](#custom-path-name)\n  - [Key Syntax](#key-syntax)\n    - [Simple Key](#simple-key)\n    - [Set Output Variable Name](#set-output-variable-name)\n    - [Multiple Secrets](#multiple-secrets)\n    - [KV secrets engine version 2](#kv-secrets-engine-version-2)\n  - [Other Secret Engines](#other-secret-engines)\n  - [Adding Extra Headers](#adding-extra-headers)\n  - [HashiCorp Cloud Platform or Vault Enterprise](#hashicorp-cloud-platform-or-vault-enterprise)\n    - [Namespace](#namespace)\n  - [Reference](#reference)\n  - [Masking - Hiding Secrets from Logs](#masking---hiding-secrets-from-logs)\n  - [Normalization](#normalization)\n  - [Contributing](#contributing)\n\n\u003c!-- /TOC --\u003e\n\n## Example Usage\n\n```yaml\njobs:\n  build:\n    # ...\n    steps:\n      # ...\n      - name: Import Secrets\n        id: import-secrets\n        uses: hashicorp/vault-action@v2\n        with:\n          url: https://vault.mycompany.com:8200\n          token: ${{ secrets.VAULT_TOKEN }}\n          caCertificate: ${{ secrets.VAULT_CA_CERT }}\n          secrets: |\n            secret/data/ci/aws accessKey | AWS_ACCESS_KEY_ID ;\n            secret/data/ci/aws secretKey | AWS_SECRET_ACCESS_KEY ;\n            secret/data/ci npm_token\n      # ...\n```\n\nRetrieved secrets are available as environment variables or outputs for subsequent steps:\n\n```yaml\n#...\n- name: Step following 'Import Secrets'\n  run: |\n    ACCESS_KEY_ID = \"${{ env.AWS_ACCESS_KEY_ID }}\"\n    SECRET_ACCESS_KEY = \"${{ steps.import-secrets.outputs.AWS_SECRET_ACCESS_KEY }}\"\n\n# ...\n```\n\nIf your project needs a format other than env vars and step outputs, you can use additional steps to transform them into the desired format.\nFor example, a common pattern is to save all the secrets in a JSON file:\n\n```yaml\n#...\n- name: Step following 'Import Secrets'\n  run: |\n    touch secrets.json\n    echo '${{ toJson(steps.import-secrets.outputs) }}' \u003e\u003e secrets.json\n\n# ...\n```\n\nWhich with our example would yield a file containing:\n\n```json\n{\n  \"ACCESS_KEY_ID\": \"MY_KEY_ID\",\n  \"SECRET_ACCESS_KEY\": \"MY_SECRET_KEY\",\n  \"NPM_TOKEN\": \"MY_NPM_TOKEN\"\n}\n```\n\nNote that all secrets are masked so programs need to read the file themselves otherwise all values will be replaced with a `***` placeholder.\n\n## Authentication Methods\n\nConsider using a [Vault authentication method](https://www.vaultproject.io/docs/auth) such as the JWT auth method with\n[GitHub OIDC tokens](https://docs.github.com/en/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect) or the AppRole auth method. You can configure which by using the `method` parameter.\n\n### JWT with GitHub OIDC Tokens\n\nYou can configure trust between a GitHub Actions workflow\nand Vault using the\n[GitHub's OIDC provider](https://docs.github.com/en/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect).\nEach GitHub Actions workflow receives an auto-generated OIDC token with claims\nto establish the identity of the workflow.\n\n**Vault Configuration**\n\n\u003cdetails\u003e\n\u003csummary\u003eClick to toggle instructions for configuring Vault.\u003c/summary\u003e\n\nSet up Vault with the [JWT auth method](https://www.vaultproject.io/api/auth/jwt#configure).\nPass the following parameters to your auth method configuration:\n\n- `oidc_discovery_url`: `https://token.actions.githubusercontent.com`\n- `bound_issuer`: `https://token.actions.githubusercontent.com`\n\nConfigure a [Vault role](https://www.vaultproject.io/api/auth/jwt#create-role) for the auth method.\n\n- `role_type`: `jwt`\n\n- `bound_audiences`: `\"https://github.com/\u003corg\u003e\"`. Update this parameter if\n  you change the `aud` claim in the GitHub OIDC token via the\n  `jwtGithubAudience` parameter in the action config.\n\n- `user_claim`: Set this to a claim name (e.g., `repository`) in the\n  [GitHub OIDC token](https://docs.github.com/en/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect#understanding-the-oidc-token).\n\n- `bound_claims` OR `bound_subject`: match on [GitHub subject claims](https://docs.github.com/en/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect#example-subject-claims).\n\n  - For wildcard (non-exact) matches, use `bound_claims`.\n\n    - `bound_claims_type`: `glob`\n\n    - `bound_claims`: JSON object. Maps one or more claim names to corresponding wildcard values.\n      ```json\n      { \"sub\": \"repo:\u003corgName\u003e/*\" }\n      ```\n\n  - For exact matches, use `bound_subject`.\n\n    - `bound_claims_type`: `string`\n\n    - `bound_subject`: Must exactly match the `sub` claim in the OIDC token.\n      ```plaintext\n      repo:\u003corgName/repoName\u003e:ref:refs/heads/branchName\n      ```\n\n\u003c/details\u003e\n\n**GitHub Actions Workflow**\n\nIn the GitHub Actions workflow, the workflow needs permissions to read contents\nand write the ID token.\n\n```yaml\njobs:\n  retrieve-secret:\n    permissions:\n      contents: read\n      id-token: write\n```\n\nIn the action, provide the name of the Vault role you created to the `role` parameter.\nYou can optionally set the `jwtGithubAudience` parameter to change the `aud`\nclaim from its default.\n\n```yaml\nwith:\n  url: https://vault.mycompany.com:8200\n  caCertificate: ${{ secrets.VAULT_CA_CERT }}\n  role: \u003cVault JWT Auth Role Name\u003e\n  method: jwt\n  jwtGithubAudience: sigstore # set the GitHub token's aud claim\n```\n\n### AppRole\n\nThe [AppRole auth method](https://www.vaultproject.io/docs/auth/approle) allows\nyour GitHub Actions workflow to authenticate to Vault with a pre-defined role.\nSet the role ID and secret ID as GitHub secrets and pass them to the\n`roleId` and `secretId` parameters.\n\n```yaml\nwith:\n  url: https://vault.mycompany.com:8200\n  caCertificate: ${{ secrets.VAULT_CA_CERT }}\n  method: approle\n  roleId: ${{ secrets.VAULT_ROLE_ID }}\n  secretId: ${{ secrets.VAULT_SECRET_ID }}\n```\n\n### Token\n\nFor the default method of authenticating to Vault,\nuse a [Vault token](https://www.vaultproject.io/docs/concepts/tokens).\nSet the Vault token as a GitHub secret and pass\nit to the `token` parameter.\n\n```yaml\nwith:\n  url: https://vault.mycompany.com:8200\n  caCertificate: ${{ secrets.VAULT_CA_CERT }}\n  token: ${{ secrets.VAULT_TOKEN }}\n```\n\n### GitHub\n\nThe [GitHub auth method](https://www.vaultproject.io/docs/auth/github)\nrequires `read:org` permissions for authentication. The auto-generated `GITHUB_TOKEN`\ncreated for projects does not have these permissions and GitHub does not allow this\ntoken's permissions to be modified. A new GitHub Token secret must be created with\n`read:org` permissions to use this authentication method.\n\nPass the GitHub token as a GitHub secret into the `githubToken` parameter.\n\n```yaml\nwith:\n  url: https://vault.mycompany.com:8200\n  caCertificate: ${{ secrets.VAULT_CA_CERT }}\n  method: github\n  githubToken: ${{ secrets.GITHUB_TOKEN }}\n```\n\n### JWT with OIDC Provider\n\nYou can configure trust between your own OIDC Provider and Vault\nwith the JWT auth method. Provide a `role` \u0026 `jwtPrivateKey` parameters,\nadditionally you can pass `jwtKeyPassword` \u0026 `jwtTtl` parameters\n\n```yaml\nwith:\n  url: https://vault.mycompany.com:8200\n  caCertificate: ${{ secrets.VAULT_CA_CERT }}\n  method: jwt\n  role: \u003cVault JWT Auth Role Name\u003e\n  jwtPrivateKey: ${{ secrets.JWT_PRIVATE_KEY }}\n  jwtKeyPassword: ${{ secrets.JWT_KEY_PASS }}\n  jwtTtl: 3600 # 1 hour, default value\n```\n\n### Kubernetes\n\nConsider the [Kubernetes auth method](https://www.vaultproject.io/docs/auth/kubernetes)\nwhen using self-hosted runners on Kubernetes. You must provide the `role` parameter\nfor the Vault role associated with the Kubernetes auth method.\nYou can optionally override the `kubernetesTokenPath` parameter for\ncustom-mounted serviceAccounts.\n\n```yaml\nwith:\n  url: https://vault.mycompany.com:8200\n  caCertificate: ${{ secrets.VAULT_CA_CERT }}\n  method: kubernetes\n  role: \u003cVault Kubernetes Auth Role Name\u003e\n  kubernetesTokenPath: /var/run/secrets/kubernetes.io/serviceaccount/token # default token path\n```\n\n### Userpass\n\nThe [Userpass auth method](https://developer.hashicorp.com/vault/docs/auth/userpass) allows\nyour GitHub Actions workflow to authenticate to Vault with a username and password.\nSet the username and password as GitHub secrets and pass them to the\n`username` and `password` parameters.\n\nThis is not the same as ldap or okta auth methods.\n\n```yaml\nwith:\n  url: https://vault.mycompany.com:8200\n  caCertificate: ${{ secrets.VAULT_CA_CERT }}\n  method: userpass\n  username: ${{ secrets.VAULT_USERNAME }}\n  password: ${{ secrets.VAULT_PASSWORD }}\n```\n\n### Ldap\n\nThe [LDAP auth method](https://developer.hashicorp.com/vault/docs/auth/ldap) allows\nyour GitHub Actions workflow to authenticate to Vault with a username and password inturn verfied with ldap servers.\nSet the username and password as GitHub secrets and pass them to the\n`username` and `password` parameters.\n\n```yaml\nwith:\n  url: https://vault.mycompany.com:8200\n  caCertificate: ${{ secrets.VAULT_CA_CERT }}\n  method: ldap\n  username: ${{ secrets.VAULT_USERNAME }}\n  password: ${{ secrets.VAULT_PASSWORD }}\n```\n\n### Other Auth Methods\n\nIf any other method is specified and you provide an `authPayload`, the action will\nattempt to `POST` to `auth/${method}/login` with the provided payload and parse out the client token.\n\n### Custom Path Name\n\nAuth methods at custom path names can be configured using the [`path`](#path) parameter\n\n```yaml\nwith:\n  url: https://vault.mycompany.com:8200\n  caCertificate: ${{ secrets.VAULT_CA_CERT }}\n  path: my-custom-path\n  method: userpass\n  username: ${{ secrets.VAULT_USERNAME }}\n  password: ${{ secrets.VAULT_PASSWORD }}\n```\n\n## Key Syntax\n\nThe `secrets` parameter is a set of multiple secret requests separated by the `;` character.\n\nEach secret request consists of the `path` and the `key` of the desired secret, and optionally the desired Env Var output name.\nNote that the selector is using [JSONata](https://docs.jsonata.org/overview.html) and certain characters in keys may need to be escaped.\n\n```raw\n{{ Secret Path }} {{ Secret Key or Selector }} | {{ Env/Output Variable Name }}\n```\n\n### Simple Key\n\nTo retrieve a key `npmToken` from path `secret/data/ci` that has value `somelongtoken` from vault you could do:\n\n```yaml\nwith:\n  secrets: secret/data/ci npmToken\n```\n\n`vault-action` will automatically normalize the given secret selector key, and set the follow as environment variables for the following steps in the current job:\n\n```bash\nNPMTOKEN=somelongtoken\n```\n\nYou can also access the secret via outputs:\n\n```yaml\nsteps:\n  # ...\n  - name: Import Secrets\n    id: secrets\n    # Import config...\n  - name: Sensitive Operation\n    run: \"my-cli --token '${{ steps.secrets.outputs.npmToken }}'\"\n```\n\n_**Note:** If you'd like to only use outputs and disable automatic environment variables, you can set the `exportEnv` option to `false`._\n\n### Set Output Variable Name\n\nHowever, if you want to set it to a specific name, say `NPM_TOKEN`, you could do this instead:\n\n```yaml\nwith:\n  secrets: secret/data/ci npmToken | NPM_TOKEN\n```\n\nWith that, `vault-action` will now use your requested name and output:\n\n```bash\nNPM_TOKEN=somelongtoken\n```\n\n```yaml\nsteps:\n  # ...\n  - name: Import Secrets\n    id: secrets\n    # Import config...\n  - name: Sensitive Operation\n    run: \"my-cli --token '${{ steps.secrets.outputs.NPM_TOKEN }}'\"\n```\n\n### Multiple Secrets\n\nThis action can take multi-line input, so say you had your AWS keys stored in a path and wanted to retrieve both of them. You can do:\n\n```yaml\nwith:\n  secrets: |\n    secret/data/ci/aws accessKey | AWS_ACCESS_KEY_ID ;\n    secret/data/ci/aws secretKey | AWS_SECRET_ACCESS_KEY\n```\n\nYou can specify a wildcard \\* for the key name to get all keys in the path. If you provide an output name with the wildcard, the name will be prepended to the key name:\n\n```yaml\nwith:\n  secrets: |\n    secret/data/ci/aws * | MYAPP_ ;\n```\n\nWhen using the `exportEnv` option all exported keys will be normalized to uppercase. For example, the key `SecretKey` would be exported as `MYAPP_SECRETKEY`.\nYou can disable uppercase normalization by specifying double asterisks `**` in the selector path:\n\n```yaml\nwith:\n    secrets: |\n        secret/data/ci/aws ** | MYAPP_ ;\n```\n\n### KV secrets engine version 2\n\nWhen accessing secrets from the KV secrets engine version 2, Vault Action\nrequires the full path to the secret. This is the same path that would be used\nin a Vault policy for the secret. You can find the full path to your secret by\nperforming a `kv get` command like the following:\n\n```bash\n$ vault kv get secret/test\n== Secret Path ==\nsecret/data/test\n\n...\n```\n\nNote that the full path is not `secret/test`, but `secret/data/test`.\n\n## PKI Certificate Requests\n\nYou can use the `pki` option to generate a certificate and private key for a given role.\n\n````yaml\nwith:\n    pki: |\n        pki/issue/rolename {\"common_name\": \"role.mydomain.com\", \"ttl\": \"1h\"} ;\n        pki/issue/otherrole {\"common_name\": \"otherrole.mydomain.com\", \"ttl\": \"1h\"} ;\n```\n\nResulting in:\n\n```bash\nROLENAME_CA=-----BEGIN CERTIFICATE-----...\nROLENAME_CERT=-----BEGIN CERTIFICATE-----...\nROLENAME_KEY=-----BEGIN RSA PRIVATE KEY-----...\nROLENAME_CA_CHAIN=-----BEGIN CERTIFICATE-----...\nOTHERROLE_CA=-----BEGIN CERTIFICATE-----...\nOTHERROLE_CERT=-----BEGIN CERTIFICATE-----...\nOTHERROLE_KEY=-----BEGIN RSA PRIVATE KEY-----...\nOTHERROLE_CA_CHAIN=-----BEGIN CERTIFICATE-----...\n````\n\n## Other Secret Engines\n\nVault Action currently supports retrieving secrets from any engine where secrets\nare retrieved via `GET` requests, except for the PKI engine as noted above.\n\nFor example, to request a secret from the `cubbyhole` secret engine:\n\n```yaml\nwith:\n  secrets: |\n    /cubbyhole/foo foo ;\n    /cubbyhole/foo zip | MY_KEY ;\n```\n\nResulting in:\n\n```bash\nFOO=bar\nMY_KEY=zap\n```\n\n```yaml\nsteps:\n  # ...\n  - name: Import Secrets\n    id: secrets\n    # Import config...\n  - name: Sensitive Operation\n    run: \"my-cli --token '${{ steps.secrets.outputs.foo }}'\"\n  - name: Another Sensitive Operation\n    run: \"my-cli --token '${{ steps.secrets.outputs.MY_KEY }}'\"\n```\n\n## Adding Extra Headers\n\nIf you ever need to add extra headers to the vault request, say if you need to authenticate with a firewall, all you need to do is set `extraHeaders`:\n\n```yaml\nwith:\n  secrets: |\n    secret/data/ci/aws accessKey | AWS_ACCESS_KEY_ID ;\n    secret/data/ci/aws secretKey | AWS_SECRET_ACCESS_KEY\n  extraHeaders: |\n    X-Secure-Id: ${{ secrets.SECURE_ID }}\n    X-Secure-Secret: ${{ secrets.SECURE_SECRET }}\n```\n\nThis will automatically add the `x-secure-id` and `x-secure-secret` headers to every request to Vault.\n\n## HashiCorp Cloud Platform or Vault Enterprise\n\nIf you are using [HCP Vault](https://cloud.hashicorp.com/products/vault)\nor Vault Enterprise, you may need additional parameters in\nyour GitHub Actions workflow.\n\n### Namespace\n\nIf you need to retrieve secrets from a specific Vault namespace, set the `namespace`\nparameter specifying the namespace. In HCP Vault, the namespace defaults to `admin`.\n\n```yaml\nsteps:\n  # ...\n  - name: Import Secrets\n    uses: hashicorp/vault-action\n    with:\n      url: https://vault-enterprise.mycompany.com:8200\n      method: token\n      token: ${{ secrets.VAULT_TOKEN }}\n      namespace: admin\n      secrets: |\n        secret/data/ci/aws accessKey | AWS_ACCESS_KEY_ID ;\n        secret/data/ci/aws secretKey | AWS_SECRET_ACCESS_KEY ;\n        secret/data/ci npm_token\n```\n\nAlternatively, you may need to authenticate to the root namespace and retrieve\na secret from a different namespace. To do this, do not set the `namespace`\nparameter. Instead set the namespace in the secret path. For example, `\u003cNAMESPACE\u003e/secret/data/app`:\n\n```yaml\nsteps:\n  # ...\n  - name: Import Secrets\n    uses: hashicorp/vault-action\n    with:\n      url: https://vault-enterprise.mycompany.com:8200\n      method: token\n      token: ${{ secrets.VAULT_TOKEN }}\n      secrets: |\n        namespace-1/secret/data/ci/aws accessKey | AWS_ACCESS_KEY_ID ;\n        namespace-1/secret/data/ci/aws secretKey | AWS_SECRET_ACCESS_KEY ;\n        namespace-1/secret/data/ci npm_token\n```\n\n## Reference\n\nHere are all the inputs available through `with`:\n\n### `url`\n\n**Type: `string`**\\\n**Required**\n\nThe URL for the Vault endpoint.\n\n### `secrets`\n\n**Type: `string`**\n\nA semicolon-separated list of secrets to retrieve. These will automatically be\nconverted to environmental variable keys. See [Key Syntax](#key-syntax) for\nmore details.\n\n### `namespace`\n\n**Type: `string`**\n\nThe Vault namespace from which to query secrets. Vault Enterprise only, unset by default.\n\n### `method`\n\n**Type: `string`**\\\n**Default: `token`**\n\nThe method to use to authenticate with Vault.\n\n### `role`\n\n**Type: `string`**\n\nVault role for the specified auth method.\n\n### `path`\n\n**Type: `string`**\n\nThe Vault path for the auth method.\n\n### `token`\n\n**Type: `string`**\n\nThe Vault token to be used to authenticate with Vault.\n\n### `roleId`\n\n**Type: `string`**\n\nThe role ID for App Role authentication.\n\n### `secretId`\n\n**Type: `string`**\n\nThe secret ID for App Role authentication.\n\n### `githubToken`\n\n**Type: `string`**\n\nThe Github Token to be used to authenticate with Vault.\n\n### `jwtPrivateKey`\n\n**Type: `string`**\n\nBase64 encoded private key to sign the JWT.\n\n### `jwtKeyPassword`\n\n**Type: `string`**\n\nPassword for key stored in `jwtPrivateKey` (if needed).\n\n### `jwtGithubAudience`\n\n**Type: `string`**\\\n**Default: `sigstore`**\n\nIdentifies the recipient (\"aud\" claim) that the JWT is intended for.\n\n### `jwtTtl`\n\n**Type: `string`**\\\n**Default: `3600`**\n\nTime in seconds, after which token expires.\n\n### `kubernetesTokenPath`\n\n**Type: `string`**\\\n**Default: `/var/run/secrets/kubernetes.io/serviceaccount/token`**\n\nThe path to the service-account secret with the jwt token for kubernetes based authentication.\n\n### `username`\n\n**Type: `string`**\n\nThe username of the user to log in to Vault as. Available to both Userpass and LDAP auth methods.\n\n### `password`\n\n**Type: `string`**\n\nThe password of the user to log in to Vault as. Available to both Userpass and LDAP auth methods.\n\n### `authPayload`\n\n**Type: `string`**\n\nThe JSON payload to be sent to Vault when using a custom authentication method.\n\n### `extraHeaders`\n\n**Type: `string`**\n\nA string of newline separated extra headers to include on every request.\n\n### `exportEnv`\n\n**Type: `string`**\\\n**Default: `true`**\n\nWhether or not to export secrets as environment variables.\n\n### `exportToken`\n\n**Type: `string`**\\\n**Default: `false`**\n\nWhether or not export Vault token as environment variables (i.e VAULT_TOKEN).\n\n### `outputToken`\n\n**Type: `string`**\\\n**Default: `false`**\n\nWhether or not to set the `vault_token` output to contain the Vault token after authentication.\n\n### `caCertificate`\n\n**Type: `string`**\n\nBase64 encoded CA certificate the server certificate was signed with. Defaults to CAs provided by Mozilla.\n\n### `clientCertificate`\n\n**Type: `string`**\n\nBase64 encoded client certificate the action uses to authenticate with Vault when mTLS is enabled.\n\n### `clientKey`\n\n**Type: `string`**\n\nBase64 encoded client key the action uses to authenticate with Vault when mTLS is enabled.\n\n### `tlsSkipVerify`\n\n**Type: `string`**\\\n**Default: `false`**\n\nWhen set to true, disables verification of server certificates when testing the action.\n\n### `ignoreNotFound`\n\n**Type: `string`**\\\n**Default: `false`**\n\nWhen set to true, prevents the action from failing when a secret does not exist.\n\n## Masking - Hiding Secrets from Logs\n\nThis action uses GitHub Action's built-in masking, so all variables will automatically be masked (aka hidden) if printed to the console or to logs.\n**This only obscures secrets from output logs.** If someone has the ability to edit your workflows, then they are able to read and therefore write secrets to somewhere else just like normal GitHub Secrets.\n\n## Normalization\n\nTo make it simpler to consume certain secrets as env vars, if no Env/Output Var Name is specified `vault-action` will replace and `.` chars with `__`, remove any other non-letter or number characters. If you're concerned about the result, it's recommended to provide an explicit Output Var Key.\n\n## Contributing\n\nIf you wish to contribute to this project, the following dependencies are recommended for local development:\n\n- [npm](https://docs.npmjs.com/downloading-and-installing-node-js-and-npm) to install dependencies, build project and run tests\n- [docker](https://docs.docker.com/get-docker/) to run the pre-configured vault containers for acceptance tests\n- [docker compose](https://docs.docker.com/compose/) to spin up the pre-configured vault containers for acceptance tests\n- [act](https://github.com/nektos/act) to run the vault-action locally\n\n### Build\n\nUse npm to install dependencies and build the project:\n\n```sh\n$ npm install \u0026\u0026 npm run build\n```\n\n### Vault test instance\n\nThe Github Action needs access to a working Vault instance to function.\nMultiple docker configurations are available via the docker-compose.yml file to run containers compatible with the various acceptance test suites.\n\n```sh\n$ docker compose up -d vault # Choose one of: vault, vault-enterprise, vault-tls depending on which tests you would like to run\n```\n\nInstead of using one of the dockerized instance, you can also use your own local or remote Vault instance by exporting these environment variables:\n\n```sh\n$ export VAULT_HOST=\u003cYOUR VAULT CLUSTER LOCATION\u003e # localhost if undefined\n$ export VAULT_PORT=\u003cYOUR VAULT PORT\u003e # 8200 if undefined\n$ export VAULT_TOKEN=\u003cYOUR VAULT TOKEN\u003e # testtoken if undefined\n```\n\n### Running unit tests\n\nUnit tests can be executed at any time with no dependencies or prior setup.\n\n```sh\n$ npm test\n```\n\n### Running acceptance tests\n\nWith a succesful build to take your local changes into account and a working Vault instance configured, you can now run acceptance tests to validate if any regressions were introduced.\n\n```sh\n$ npm run test:integration:basic # Choose one of: basic, enterprise, e2e, e2e-tls\n```\n\n### Running the action locally\n\nYou can use the [act](https://github.com/nektos/act) command to test your\nchanges locally.\n\nEdit the ./.github/workflows/local-test.yaml file and add any steps necessary\nto test your changes. You may have to additionally edit the Vault url, token\nand secret path if you are not using one of the provided containerized\ninstances. The `local-test` job will call the ./integrationTests/e2e/setup.js\nscript to bootstrap your local Vault instance with secrets.\n\nRun your feature branch locally:\n\n```sh\nact workflow_dispatch -j local-test\n```\n\nOr use the provided make target which will also spin up a Vault container:\n\n```sh\nmake local-test\n```\n","funding_links":[],"categories":["JavaScript","others"],"sub_categories":[],"project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fhashicorp%2Fvault-action","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fhashicorp%2Fvault-action","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fhashicorp%2Fvault-action/lists"}