{"id":14008412,"url":"https://github.com/jenkinsci/hashicorp-vault-plugin","last_synced_at":"2025-04-08T11:14:51.793Z","repository":{"id":37276514,"uuid":"64247276","full_name":"jenkinsci/hashicorp-vault-plugin","owner":"jenkinsci","description":"Jenkins plugin to populate environment variables from secrets stored in HashiCorp's Vault.","archived":false,"fork":false,"pushed_at":"2024-10-17T16:04:20.000Z","size":2104,"stargazers_count":216,"open_issues_count":113,"forks_count":146,"subscribers_count":16,"default_branch":"master","last_synced_at":"2025-04-01T10:09:44.297Z","etag":null,"topics":["hashicorp-vault","jenkins","jenkins-plugin","secret-management","secrets","vault"],"latest_commit_sha":null,"homepage":"https://plugins.jenkins.io/hashicorp-vault-plugin/","language":"Java","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/jenkinsci.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2016-07-26T19:07:44.000Z","updated_at":"2025-02-11T21:38:47.000Z","dependencies_parsed_at":"2024-12-01T22:03:05.033Z","dependency_job_id":"3d148fdc-e6eb-47f8-b978-2bc6bc266112","html_url":"https://github.com/jenkinsci/hashicorp-vault-plugin","commit_stats":null,"previous_names":[],"tags_count":44,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/jenkinsci%2Fhashicorp-vault-plugin","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/jenkinsci%2Fhashicorp-vault-plugin/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/jenkinsci%2Fhashicorp-vault-plugin/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/jenkinsci%2Fhashicorp-vault-plugin/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/jenkinsci","download_url":"https://codeload.github.com/jenkinsci/hashicorp-vault-plugin/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":247829512,"owners_count":21002997,"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":["hashicorp-vault","jenkins","jenkins-plugin","secret-management","secrets","vault"],"created_at":"2024-08-10T11:01:39.139Z","updated_at":"2025-04-08T11:14:51.771Z","avatar_url":"https://github.com/jenkinsci.png","language":"Java","funding_links":[],"categories":["Java"],"sub_categories":[],"readme":"# Jenkins Vault Plugin\n\n[![Build Status](https://ci.jenkins.io/buildStatus/icon?job=Plugins/hashicorp-vault-plugin/master)](https://ci.jenkins.io/job/Plugins/job/hashicorp-vault-plugin/job/master/)\n[![Jenkins Plugin](https://img.shields.io/jenkins/plugin/v/hashicorp-vault-plugin.svg)](https://plugins.jenkins.io/hashicorp-vault-plugin)\n[![GitHub release](https://img.shields.io/github/release/jenkinsci/hashicorp-vault-plugin.svg?label=release)](https://github.com/jenkinsci/hashicorp-vault-plugin/releases/latest)\n[![Jenkins Plugin Installs](https://img.shields.io/jenkins/plugin/i/hashicorp-vault-plugin.svg?color=blue)](https://plugins.jenkins.io/hashicorp-vault-plugin)\n\nThis plugin adds a build wrapper to set environment variables from a HashiCorp [Vault](https://www.vaultproject.io/) secret. Secrets are generally masked in the build log, so you can't accidentally print them.  \nIt also has the ability to inject Vault credentials into a build pipeline or freestyle job for fine-grained vault interactions.\n\n## Vault Authentication Backends\nThis plugin allows authenticating against Vault using the AppRole authentication backend. Hashicorp recommends using AppRole for Servers / automated workflows (like Jenkins) and using Tokens (default mechanism, Github Token, ...) for every developer's machine.\n  Furthermore, this plugin allows using a Github personal access token, or a Vault Token - either configured directly in Jenkins or read from an arbitrary file on the Jenkins controller.\n\n### How does AppRole work?\nIn short: you register an approle auth backend using a self-chosen name (e.g. Jenkins). This approle is identified by a `role-id` and secured with a `secret_id`. If you have both of those values you can ask Vault for a token that can be used to access vault.\nWhen registering the approle backend you can set a couple of different parameters:\n* How long should the `secret_id` live (can be indefinite)\n* how often can one use a token that is obtained via this backend\n* which IP addresses can obtain a token using `role-id` and `secret-id`?\n* many more\n\nThis is just a short introduction, please refer to [Hashicorp itself](https://www.vaultproject.io/docs/auth/approle.html) to get detailed information.\n\n### Isolating policies for different jobs\nIt may be desirable to have jobs or folders with separate Vault policies allocated. This may be done\nwith the optional `policies` configuration option combined with authentication such as the AppRole\ncredential. The process is the following:\n* The Jenkins job attempts to retrieve a secret from Vault\n* The AppRole authentication is used to retrieve a new token (if the old one has not expired yet)\n* The Vault plugin then uses the `policies` configuration value with job info to come up with a list of policies\n* If this list is not empty, the AppRole token is used to retrieve a new token that only has the specified policies applied\n* This token is then used for all Vault plugin operations in the job\n\nThe policies list may be templatized with values that can come from each job in order to customize\npolicies per job or folder. See the `policies` configuration help for more information on available\ntokens to use in the configuration. The `Limit Token Policies` option must also be enabled on the\nauth credential. Please note that the AppRole (or other authentication method) should have all policies\nconfigured as `token_policies` and not `identity_policies`, as job-specific tokens inherit all\n`identity_policies` automatically.  \n\n### What about other backends?\nHashicorp explicitly recommends the AppRole Backend for machine-to-machine authentication. Token based auth is mainly supported for backward compatibility.\nOther backends that might make sense are the AWS EC2 backend, the Azure backend, and the Kubernetes backend. But we do not support these yet. Feel free to contribute!\n\nImplementing additional authentication backends is actually quite easy:\n\nSimply provide a class extending `AbstractVaultTokenCredential` that contains a `Descriptor` extending `BaseStandardCredentialsDescriptor`.\nThe `Descriptor` needs to be annotated with `@Extension`. Your credential needs to know how to authenticate with Vault and provide an authenticated Vault session.\nSee [VaultAppRoleCredential.java](https://github.com/jenkinsci/hashicorp-vault-plugin/blob/master/src/main/java/com/datapipe/jenkins/vault/credentials/VaultAppRoleCredential.java) for an example.\n\n\n## Plugin Usage\n### Configuration\nYou can configure the plugin on three different levels:\n* Global: in your global config\n* [Folder](https://wiki.jenkins-ci.org/display/JENKINS/CloudBees+Folders+Plugin)-Level: on the folder your job is running in\n* Job-Level: either on your freestyle project job or directly in the Jenkinsfile\n\nThe lower the level the higher its priority, meaning: if you configure a URL in your global settings, but override it in your particular job, this URL will be used for communicating with Vault.\nIn your configuration (may it be global, folder or job) you see the following screen:\n![Global Configuration](docs/images/configuration_screen.png)\n\nThe credential you provide determines what authentication backend will be used.\nCurrently, there are five different Credential Types you can use:\n\n#### Vault App Role Credential\n\n![App Role Credential](docs/images/approle_credential.png)\n\nYou enter your `role-id` and `secret-id` there. The description helps to find your credential later, the id is not mandatory (a UUID is generated by default), but it helps to set it if you want to use your credential inside the Jenkinsfile.\n\nThe `path` field is the approle authentication path. This is, by default, \"approle\" and this will also be used if no path is specified here.\n\n#### Migrate current Jenkins Vault configuration to support a new version of plugin.\nAfter update a plugin from version `2.2.0` you can note - builds failed with an exception `java.lang.NullPointerException`. These steps will help you fix it:\n1. If you using AppRole auth method - you need to update Jenkins `Credential` store (in UI) for all kinds `Vault App Role Credential` and set `Path` field for your correct path or just leave the default `approle` and save. \n2. Go to `Configure` of failed job and change Vault Engine in `Advanced Settings` and choose your version on KV Engine 1 or 2 from a select menu `K/V Engine Version` for ALL `Vault Secrets` and save.\n\n#### Vault Github Credential\n\n![Github Credentia](docs/images/github_credential.png)\n\nYou enter your github personal access token to authenticate to vault.\n\n#### Vault GCP Credential\n\n![GCP Credential](docs/images/gcp_credential.png)\n\nYou enter your Vault GCP auth `role` name and `audience`. The JWT will be automatically retrieved from GCE metdata. This requires that Jenkins master is running on a GCE instance.\n\n#### Vault Kubernetes Credential\n\n![Kubernetes Credential](docs/images/kubernetes_credential.png)\n\nYou enter your Vault Kubernetes auth `role`. The JWT will be automatically retrieved from the\nmounted secret volume (`/var/run/secrets/kubernetes.io/serviceaccount/token`). This assumes,\nthat the jenkins is running in Kubernetes Pod with a Service Account attached.\n\n#### Vault AWS IAM Credential\n\n![AWS IAM Credential](docs/images/aws_iam_credential.png)\n\nAuthenticate to Vault using the aws auth method with the\n[IAM](https://www.vaultproject.io/docs/auth/aws#iam-auth-method)\nworkflow. The AWS credentials will be automatically retrieved from one\nof [several standard\nlocations](https://docs.aws.amazon.com/AWSJavaSDK/latest/javadoc/com/amazonaws/auth/DefaultAWSCredentialsProviderChain.html).\nThe typical use case would be Jenkins master running on an AWS EC2\ninstance with the credentials acquired from the [instance\nmetadata](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html#instance-metadata-security-credentials).\nOptionally enter your AWS IAM auth `role` name and Vault AWS auth\n`mount` path. If the `role` is not provided, Vault will determine it\nfrom the principal in the IAM identity. If the `mount` path is not\nprovided, it defaults to `aws`.\n\n#### Vault Token Credential\n\n![Token Credential](docs/images/token_credential.png)\n\nDirectly specify a token to be used when authenticating with vault.\n\n#### Vault Token File Credential\n\n![Token File Credential](docs/images/tokenfile_credential.png)\n\nBasically the same as the Vault Token Credential, just that the token is read from a file on your Jenkins Machine.\nYou can use this in combination with a script that periodically refreshes your token.\n\n### Usage in FreeStyle Jobs\nIf you still use free style jobs (hint: you should consider migrating to [Jenkinsfile](https://jenkins.io/doc/book/pipeline/)), you can configure both configuration and the secrets you need on the job level.\n\n![Job Configuration](docs/images/job_screen.png)\n\nThe secrets are available as environment variables then.\n\n### Usage via Jenkinsfile\nLet the code speak for itself:\n```groovy\nnode {\n    // define the secrets and the env variables\n    // engine version can be defined on secret, job, folder or global.\n    // the default is engine version 2 unless otherwise specified globally.\n    def secrets = [\n        [path: 'secret/testing', engineVersion: 1, secretValues: [\n            [envVar: 'testing', vaultKey: 'value_one'],\n            [envVar: 'testing_again', vaultKey: 'value_two']]],\n        [path: 'secret/another_test', engineVersion: 2, secretValues: [\n            [vaultKey: 'another_test']]]\n    ]\n\n    // optional configuration, if you do not provide this the next higher configuration\n    // (e.g. folder or global) will be used\n    def configuration = [vaultUrl: 'http://my-very-other-vault-url.com',\n                         vaultCredentialId: 'my-vault-cred-id',\n                         engineVersion: 1]\n    // inside this block your credentials will be available as env variables\n    withVault([configuration: configuration, vaultSecrets: secrets]) {\n        sh 'echo $testing'\n        sh 'echo $testing_again'\n        sh 'echo $another_test'\n    }\n}\n```\nIn the future we might migrate to a [BuildStep](http://javadoc.jenkins-ci.org/hudson/tasks/BuildStep.html) instead of a BuildWrapper.\n\n#### Use of dynamic credentials\n\nYou may also want to use dynamically allocated credentials:\n```groovy\nimport hudson.util.Secret\nimport com.cloudbees.plugins.credentials.CredentialsScope\nimport com.datapipe.jenkins.vault.credentials.VaultTokenCredential\n\nVaultTokenCredential customCredential = new VaultTokenCredential(\n    CredentialsScope.GLOBAL,\n    'custom-credential',\n    'My Custom Credential',\n    Secret.fromString('This is my token. There are many like it, but this one is mine. My token is my best friend.')\n)\n\nnode {\n...\n    def configuration = [vaultUrl: 'http://my-very-other-vault-url.com',\n                         vaultCredential: customCredential]\n...\n```\n\nSetting a `vaultCredential` will override any previously defined `vaultCredentialId`.\n\nWorks with any `VaultCredential`: `VaultTokenCredential`, `VaultAppRoleCredential`, etc.\n\n## Inject Vault Credentials into your Job\n### Pipeline Usage\n![withCredentials Block](docs/images/pipeline_withCredentials.png)\n\nSpecify the variables for the vault address and token.  Vault Address and Credentials are both required.  \n`addrVariable` and `tokenVariable` are optional.  They will be set to `VAULT_ADDR` and `VAULT_TOKEN` respectively if omitted.\n\n```groovy\nnode {\n    withCredentials([[$class: 'VaultTokenCredentialBinding', credentialsId: 'vaulttoken', vaultAddr: 'https://localhost:8200']]) {\n        // values will be masked\n        sh 'echo TOKEN=$VAULT_TOKEN'\n        sh 'echo ADDR=$VAULT_ADDR'\n    }\n}\n```\n\n### FreeStyle Job\n![freeStyle Credential Binding](docs/images/freestyle_injectCreds.png)\n\n## Configuration as Code\nThere is an easier way to setup the global Vault configuration on your Jenkins server.  \nNo need for messing around in the UI.  \n\nJenkins Configuration as Code often shorten to [JCasC] or simplify [Configuration as Code plugin]\nallows you to configure Jenkins via a yaml file. If you are a first time user, you can learn more about [JCasC] :point_left:\n\nHashicorp Plugin also adds an extension to [JCasC] by providing a Secret Source for [Configuration as Code plugin] to read secrets from, which you can [read about here](#hashicorp-vault-plugin-as-a-secret-source-for-jcasc)\n\n### Prerequisite: \n\nInstall `Configuration as Code` Plugin on your Jenkins instance.\n\nRefer to [Installing a new plugin in Jenkins](https://jenkins.io/doc/book/managing/plugins/#installing-a-plugin).\n\n#### Add configuration YAML:\n\nThere are multiple ways to load JCasC yaml file to configure Jenkins:\n\n* JCasC by default searches for a file with the name `jenkins.yaml` in `$JENKINS_ROOT`.\n\n* The JCasC looks for an environment variable `CASC_JENKINS_CONFIG` which contains the path for the configuration `yaml` file.\n\n    * A path to a folder containing a set of config files e.g. `/var/jenkins_home/casc_configs`.\n\n    * A full path to a single file e.g. `/var/jenkins_home/casc_configs/jenkins.yaml`.\n\n    * A URL pointing to a file served on the web e.g. `https://\u003cyour-domain\u003e/jenkins.yaml`.\n\n* You can also set the configuration yaml path in the UI. Go to `\u003cyour-jenkins-domain\u003e/configuration-as-code`. Enter path or URL to `jenkins.yaml` and select `Apply New Configuration`.\n\nTo configure your Vault in Jenkins add the following to `jenkins.yaml`:\n\n```yaml\nunclassified:\n  hashicorpVault:\n    configuration:\n      vaultCredentialId: \"vaultToken\"\n      vaultUrl: \"https://vault.company.io\"\n\ncredentials:\n  system:\n    domainCredentials:\n      - credentials:\n          - vaultTokenCredential:\n              description: \"Uber Token\"\n              id: \"vaultToken\"\n              scope: GLOBAL\n              token: \"${MY_SECRET_TOKEN}\"\n```\n\nSee [handling secrets section](https://github.com/jenkinsci/configuration-as-code-plugin/blob/master/docs/features/secrets.adoc) in JCasC documentation for better security.\n\nYou can also configure `VaultGithubTokenCredential`, `VaultGCPCredential`, `VaultAppRoleCredential` or `VaultAwsIamCredential`.\n\nIf you are unsure about how to do it from `yaml`. You can still use the UI to configure credentials.  \nAfter you configured Credentials and the Global Vault configuration.  \nyou can use the export feature build into JCasC by visiting `\u003cyour-jenkins-domain\u003e/configuration-as-code/viewExport` \n\n### HashiCorp Vault Plugin as a Secret Source for JCasC\n\nWe can provide these initial secrets for JCasC.\nThe secret source for JCasC is configured via environment variables as way to get access to vault at startup and when configuring Jenkins instance.\n\n[For Security and compatibility considerations please read more here](https://github.com/jenkinsci/configuration-as-code-plugin#security-and-compatibility-considerations)\n\n- The environment variable `CASC_VAULT_PW` must be present, if token is not used and appRole/Secret is not used. (Vault password.)\n- The environment variable `CASC_VAULT_USER` must be present, if token is not used and appRole/Secret is not used. (Vault username.)\n- The environment variable `CASC_VAULT_APPROLE` must be present, if token is not used and U/P not used. (Vault AppRole ID.)\n- The environment variable `CASC_VAULT_APPROLE_SECRET` must be present, if token is not used and U/P not used. (Vault AppRole Secret ID.)\n- The environment variable `CASC_VAULT_KUBERNETES_ROLE` must be present, if you want to use Kubernetes Service Account. (Vault Kubernetes Role.)\n- The environment variable `CASC_VAULT_AWS_IAM_ROLE` must be present, if you want to use AWS IAM authentiation. (Vault AWS IAM Role.)\n- The environment variable `CASC_VAULT_AWS_IAM_SERVER_ID` must be present when using AWS IAM authentication and the Vault auth method requires a value for the `X-Vault-AWS-IAM-Server-ID` header. (Vault AWS IAM Server ID.)\n- The environment variable `CASC_VAULT_TOKEN` must be present, if U/P is not used. (Vault token.)\n- The environment variable `CASC_VAULT_PATHS` must be present. (Comma separated vault key paths. For example, `secret/jenkins,secret/admin`.)\n- The environment variable `CASC_VAULT_URL` must be present. (Vault url, including port number.)\n- The environment variable `CASC_VAULT_AGENT_ADDR` is optional. It takes precedence over `CASC_VAULT_URL` and is used for connecting to a Vault Agent. [See this section](#vault-agent)\n- The environment variable `CASC_VAULT_MOUNT` is optional. (Vault auth mount. For example, `ldap` or another username \u0026 password authentication type, defaults to `userpass`.)\n- The environment variable `CASC_VAULT_NAMESPACE` is optional. If used, sets the Vault namespace for Enterprise Vaults.\n- The environment variable `CASC_VAULT_PREFIX_PATH` is optional. If used, allows to use complex prefix paths (for example with KV secrets available at `my/long/data/prefix/kv/secret1` set this to `my/long/data/prefix/kv`).\n- The environment variable `CASC_VAULT_FILE` is optional, provides a way for the other variables to be read from a file instead of environment variables.\n- The environment variable `CASC_VAULT_ENGINE_VERSION` is optional. If unset, your vault path is assumed to be using kv version 2. If your vault path uses engine version 1, set this variable to `1`.\n- The issued token should have read access to vault path `auth/token/lookup-self` in order to determine its expiration time. JCasC will re-issue a token if its expiration is reached (except for `CASC_VAULT_TOKEN`).\n\nIf the environment variables `CASC_VAULT_URL` and `CASC_VAULT_PATHS` are present, JCasC will try to gather initial secrets from Vault. However for it to work properly there is a need for authentication by either the combination of `CASC_VAULT_USER` and `CASC_VAULT_PW`, a `CASC_VAULT_TOKEN`, the combination of `CASC_VAULT_APPROLE` and `CASC_VAULT_APPROLE_SECRET`, a `CASC_VAULT_KUBERNETES_ROLE`, or a `CASC_VAULT_AWS_IAM_ROLE`. The authenticated user must have at least read access.\n\nYou can also provide a `CASC_VAULT_FILE` environment variable where you load the secrets from a file.\n\nFile should be in a Java Properties format\n\n```properties\nCASC_VAULT_PW=PASSWORD\nCASC_VAULT_USER=USER\nCASC_VAULT_TOKEN=TOKEN\nCASC_VAULT_PATHS=secret/jenkins/master,secret/admin\nCASC_VAULT_URL=https://vault.dot.com\nCASC_VAULT_MOUNT=ldap\n```\n\nA good use for `CASC_VAULT_FILE` would be together with docker secrets.\n\n```yaml\nversion: \"3.6\"\n\nservices:\n  jenkins:\n    environment:\n      CASC_VAULT_FILE: /run/secrets/jcasc_vault\n    restart: always\n    build: .\n    image: jenkins.master:v1.0\n    ports:\n      - 8080:8080\n      - 50000:50000\n    volumes:\n      - jenkins-home:/var/jenkins_home\n    secrets:\n      - jcasc_vault\n\nvolumes:\n  jenkins-home:\n\nsecrets:\n  jcasc_vault:\n    file: ./secrets/jcasc_vault\n```\n#### Example: HashiCorp Vault Plugin as a Secret Source for JCasC\nAssume Vault has a secret at path `secret/jenkins/passwords` with keys `secretKey1` and `secretKey2`.  Set the value for environment variable `CASC_VAULT_PATHS` to `secret/jenkins/passwords`.\nThe Hashicorp Vault Plugin provides two ways of accessing the secrets: using just the key within the secret and using the full path to the secret key.  The full path option allows for you to reference multiple secrets with overlapping keys.\n```yaml\ncredentials:\n  system:\n    domainCredentials:\n      - credentials:\n          - string:\n              description: \"Secret using only secret key name\"\n              id: \"secretUsingKey\"\n              scope: GLOBAL\n              token: \"${secretKey1}\"\n          - string:\n              description: \"Secret using full path\"\n              id: \"secretUsingKey\"\n              scope: GLOBAL\n              token: \"${secret/jenkins/passwords/secretKey1}\"\n```\n\n### Vault Agent\n\n[For the use-case of Vault Agent read here](https://www.vaultproject.io/docs/agent/)\n\nWhen `CASC_VAULT_AGENT_ADDR` is specified, you only need to specify `CASC_VAULT_PATHS` and optionally `CASC_VAULT_ENGINE_VERSION`  \nSince Vault Agent must be configured to handle auto authentication.\n\nHere is an example of how to configure your Vault Agent with an app role.\n[Vault Agent supports multiple auto-auth methods](https://www.vaultproject.io/docs/agent/autoauth/methods/index.html)\n\n```hcl\npid_file = \"/tmp/agent_pidfile\"\nauto_auth {\n    method {\n        type = \"approle\"\n        config = {\n            role_id_file_path = \"/home/vault/role_id\"\n            secret_id_file_path = \"/home/vault/secret_id\"\n        }\n    }\n    sink {\n        type = \"file\"\n        config = {\n            path = \"/tmp/file-foo\"\n        }\n    }\n}\ncache {\n    use_auto_auth_token = true\n}\nlistener \"tcp\" {\n    address = \"0.0.0.0:8200\"\n    tls_disable = true\n}\n```\n\nIdeally your Vault Agent should be running on the same Machine or running as a Container networked together.  \nYou ought to block any connection to Vault Agent for anything that is not considered localhost.\n\nFor setup with Jenkins and Vault Agent running on the same host you can achieve this by using\n```hcl\nlistener \"tcp\" {\n    address = \"127.0.0.1:8200\"\n    tls_disable = true\n}\n```\n\nFor Containers you would need to use listener address of `0.0.0.0:8200`.  \nYou should ___never expose___ the Vault Agent port. You ___OUGHT___ to network Vault Agent container and Jenkins container together.\n\n```hcl\nlistener \"tcp\" {\n    address = \"0.0.0.0:8200\"\n    tls_disable = true\n}\n```\n\n[global_configuration]: docs/images/global_configuration.png\n[job_configuration]: docs/images/job_configuration.png\n[JCasC]: https://github.com/casz/configuration-as-code-plugin\n[Configuration as Code plugin]: https://github.com/casz/configuration-as-code-plugin\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fjenkinsci%2Fhashicorp-vault-plugin","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fjenkinsci%2Fhashicorp-vault-plugin","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fjenkinsci%2Fhashicorp-vault-plugin/lists"}