Hashicorp Vault integration

I am currently in the process of retrieving secrets from Hashicorp Vault using the step templates found in this blog post Using HashiCorp Vault with Octopus - Octopus Deploy
After discussing with my team, the JWT method seemed the best use for us, since we already use the same secret engine to pull from GitLab.

However, in the JWT Login step (Using HashiCorp Vault with Octopus - Octopus Deploy) a JWT role is mentioned. While configuring this role in Vault, one of 3 link must be provided (‘jwt_validation_pubkeys’, ‘jwks_url’ or 'oidc_discovery_url)

Does Octopus have any native integration with any of these, or would we need to configure something on our side beforehand.

As an FYI, we are currently using jwks for our GitLab integration.

Good afternoon @victorion993,

Thank you for contacting Octopus Support and great question on JWT roles for using HashiCorp Vault with Octopus.

One of our Solutions engineers looked into that blog post and mentioned the post doesn’t include details of how to configure Vault for JWT, as it’s complex and very specific to individual environments so unfortunately we could not include all the different setups required to get that side of things working.

He did note you mentioned:

one of 3 link must be provided: (‘jwt_validation_pubkeys’, ‘jwks_url’ or 'oidc_discovery_url)

He said when he wrote the step templates, he chose the jwt_validation_pubkeys option and configured Vault with a public key that would be used to decrypt/validate the JWT provided by the Octopus step template (the step uses a private key that corresponds to what the public key vault is configured with - this is fairly standard in public/private key cryptography).

For your query about native integration, unfortunately Octopus does not have native integration with those links. But you are able to configure Vault and the step using jwt_validation_pubkeys option as I alluded to above.

In the future with the release of OIDC functionality, it may be possible to authenticate using that, but that would need additional support/changes to the step template I imagine.

Hopefully that helps, reach out if you have any further questions and hopefully you can get this working using the jwt_validation_pubkeys option.

Kind Regards,

Hello Clare,

I managed in the end to configure JWT and am now working on setting up the generation step (Hashicorp Vault - Generate JWT). Thank you for the reply though, i feel it will be useful for this step now.

I had however a question about the AppRole auth method. In the step “Hashicorp Vault - AppRole Get Wrapped Secret ID” there is a variable Auth Token, that points to following link (Token - Auth Methods | Vault | HashiCorp Developer). Is this token something we would need to set-up from a service account and use it like that, or is it referencing another token.

Also, i am having a few issues with the field names retrieval. I have a secret in kv/data/test-secret with 3 field names, (name, password, user). When i try and retrieve them with no field name specified, it creates the list. However, when trying to retrieve only one single field, for instance name, i get the output of the step “Created 0 output variables”
Is there something i am missing?

Hey @victorion993,

Thank you for reaching out again and great news you managed to get a little further in the setup. I spoke to the engineer who created the step template again and I will post up what he mentioned in our conversation surrounding this:

Is this token something we would need to set-up from a service account and use it like that, or is it referencing another token.

The token for this step template is used to effectively get another secretid (password) - its a bit like a one time password. As the step template implies in the post here, the step has a parameter called “Auth token”.

This token is used to authenticate to retrieve a wrapped SecretID, it should be of limited scope and should only be allowed to retrieve wrapped SecretIDs. Consider creating a long-lived Vault token as this presents only a minor risk.

So it is kind of both e.g. referencing another token (as you are passing a value into the parameter of the step) but you need to supply the token value. And as above, its recommended to create a token that is long-lived that can be used.

Our engineer did say he was curious as to why you are looking at that step, the idea behind the JWT login is that you can use the JWT token to login, and not need the auth role.

Here is his example JWT setup - you generate a JWT, Login, and then retrieve secrets:

As for the issue you mentioned:

Also, i am having a few issues with the field names retrieval. I have a secret in kv/data/test-secret with 3 field names, (name, password, user).

The engineer said you would need to provide some more details (such as a screenshot of your step), he does not have an example setup with the step to retrieve specific fields.

If you did not want to post a screenshot of your step in here, you can send that in to our secure file site here, if you could also get us a process JSON of your project we can possibly try and workout what the issue is from that, please look at the JSON and ensure there is nothing sensitive in there such as passwords or usernames you do not want us to see.

Let me know if you upload the files and we can take a look at them for you.

Kind Regards,


I uploaded the JSON and a snippet of the process step itself. I noticed that in the example given, the v2 step was used and i am currently using v1. For some reason, the v2 step gives me a “permissions denied” error regardless of how i try to set it up.

Hey @victorion993,

Our solutions engineer said V1 and V2 are for different secrets engines so you would need to know which one you are using and use the correct version for that.

There is a key/value store versioned 1 and 2, the user should use the correct one for the vault they are trying to connect to e.g. if they have a vault which is key/value v1 - use v1 of the retrieval step template

Our engineer used V2 as he likes to use the latest version, v2 of the k/v vault provides versioning of secrets.

I have never played with Hashicorp vaults and Octopus only integrates with it so we are unable to dig into this for you on the Hashicorp side but I did find the articles below which may help explain the differences between the two versions:

Hopefully that helps, I am sorry I cannot dig into the Hashicorp side for you but you would need to know what values to put in our step template in order to get this working so it depends how you have your Vault setup as to what values you need to put into the Octopus template.

Does that help at all?

Kind Regards,

Hey hey,

It does help, yes. I will check on our side and make sure i am using the appropriate step template.
Let me know if the other issue is again on my side or if i have misunderstood the way the fields names works

Hey @victorion993,

Great news those articles may help, our solutions engineer has confirmed the same step template does work with a V1 key so hopefully you should be able to get this to work. The values he put in are below, ignore the way that template is laid out, he was using a Run a Script step as that’s where he edits the community step templates and then copies them over.

He did say if you are still really struggling he can arrange to hop on a quick call to go through this with you but he is not available for the rest of the day so we would need to co-ordinate a time.

Let me know if you still cannot get this to work with the information we have so far and if not we can arrange a quick call with the solutions engineer. Let me know when you are free this week and I will see if he is free around the same times.

Kind Regards,

Hey Clare,

Sorry for the late reply. I saw an update available for the v2 secrets retrieval step and after being able to specify the namespace, everything is working well.
The only issue i am facing now is configuring the AppRole and Generating JWT. For the AppRole, the solutions you provided should suffice, they seemed clear and will need to discuss with our Vault team to see their opinions as well.
The Generate JWT step is causing some issue though. I am unsure how to setup the claims, since we are using Azure AD integration and i followed these steps Vault JWT authentication with OIDC Discovery – HashiCorp Help Center in order to generate manually a signed JWT token.
Would the engineer be available sometime this week? Maybe we can hop in a call and try to solve it this way

Hey @victorion993,

I took your response back to our engineer and he did say:

Azure AD integration isn’t applicable to the Generate JWT step, it only works with a Private key, not OIDC discovery, so that’s probably why they are encountering an issue.

He also mentioned it doesn’t have an associated AppRole either, so there are no parameters for AppRole in the generate JWT step.

I took a look at the Generate JWT step on the description it does mention:

The step is based on the existing JWT - Generate JSON Web Token step template.
However, it differs as it offers less flexibility in choosing the fields to use in the generated JWT and is opinionated towards support for Vault entities and groups.
The resulting JWT will be stored as a sensitive output variable called JWT.
A private key needs to be provided that will sign the combined JWT header and payload.
Currently, the following three signing algorithms are supported:

  1. RS256 - RSASSA-PKCS1-v1_5 using SHA-256
  2. RS384 - RSASSA-PKCS1-v1_5 using SHA-384
  3. RS512 - RSASSA-PKCS1-v1_5 using SHA-512

The default is RS256.

The engineers step looks like this:

In Vault he has this setup:

  1. Enable JWT on path:
vault auth enable -path "jwt_octopus" jwt
  1. Add Public Key to config
ssh-keygen -m PEM -t rsa -b 2048 -f rsa
openssl rsa -in rsa -pubout -outform PEM -out rsa.pub.pem

vault write "auth/jwt_octopus/config" jwt_validation_pubkeys="$(cat rsa.pub.pem)"

# Confirm logic
vault read auth/jwt_octopus/config
  1. Create role
read -r -d '' payload_json << EOM
  "role_type": "jwt",
  "user_claim": "sub",
  "groups_claim": "groups",
  "bound_audiences": "https://your.vault.address:8200/",
  "policies": [],
  "ttl": 1800,
  "max_ttl": 7200,
  "cidrs": []

# Write the role config

curl \
--header "X-Vault-Token: s.YOUR-TOKEN" \
--request POST \
--data "$payload_json" \
  1. Create entity (Instructions)
vault write identity/entity name="my.octopus.url/solutions/retrieve-hashicorp-vault-secrets" policies="octosecrets"


  • my.octopus.url - is my octopus url
  • solutions - is the project group name
  • retrieve-hashicorp-vault-secrets is the project name
  • octosecrets is the policy in vault which determines what access any JWT from this config gets
  1. You’ll receive a response of the ID from the entity created in 4 e.g.
Key        Value
---        -----
aliases    <nil>
id         51a91a7e-c44d-b9b3-de28-b6da2983a5b5
name       my.octopus.url/solutions/retrieve-hashicorp-vault-secrets

Make a note of the ID

  1. List out the accessor value for jwt_octopus/
vault auth list -format=json | jq -r '.["jwt_octopus/"].accessor' > accessor.txt

For example:

  1. Then create the entity alias
vault write identity/entity-alias name="my.octopus.url/solutions/retrieve-hashicorp-vault-secrets" \
        canonical_id=51a91a7e-c44d-b9b3-de28-b6da2983a5b5 \

In order for the JWT to generate and authenticate correctly with the way our engineer set it up, you have to make sure the:

  • octopus url
  • project group
  • project name

are all set as the identity - otherwise, vault will reject it.

I am posting it like this in case anyone else wants to set this up and they can use this as a rough guide.
The engineer did say that any other kind of setup (ie Azure AD integration) we are unable to help with as that step template was only designed to work with private keys not any other method so you may need to contact Hashicorp support if you want to get this working with Azure AD integration and you may need to create your own script to get this working in Octopus as the step template was not designed for any use other than for private keys.

Hopefully that does help but yes you would need to set it up this way for it to work with our step template unfortunately.

The engineer is able to hop on a call but only if you have set it up the way he has and its still not working, since our step template does not support Azure AD integration only Private keys we are unable to troubleshoot this on a call unfortunately.

Let me know if you are able to set it up the way our engineer has and does that work for you.
Kind Regards,

The engineer also posted this to me as he thought it might be helpful, this is the screenshot for the JWT login step (the main thing is the auth login path e.g. /auth/jwt_octopus )

Kind Regards,

Hello Clare

Thank you and the engineer for all the help. Everything worked beautifully and now I am in the process of configuring the app role setup as well. You two were extremely helpful!

Have a great weekend ahead of you and thanks again!

1 Like

Hey @victorion993,

What fantastic news! Thank you so much for letting us know you managed to get this working, I will let our engineer know as he will be really happy he helped!

Reach out over at support@octopus.com or on our forums if you need any future assistance as we are always happy to help!

Kind Regards and Happy Deployments,

1 Like

This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.