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:
RS256 - RSASSA-PKCS1-v1_5 using SHA-256RS384 - RSASSA-PKCS1-v1_5 using SHA-384RS512 - RSASSA-PKCS1-v1_5 using SHA-512
The default is RS256.
The engineers step looks like this:
In Vault he has this setup:
- Enable JWT on path:
vault auth enable -path "jwt_octopus" jwt
- 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
- 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": []
}
EOM
# Write the role config
curl \
--header "X-Vault-Token: s.YOUR-TOKEN" \
--request POST \
--data "$payload_json" \
https://your.vault.address:8200/v1/auth/jwt_octopus/role/octopus
- Create entity (Instructions)
vault write identity/entity name="my.octopus.url/solutions/retrieve-hashicorp-vault-secrets" policies="octosecrets"
where:
my.octopus.url - is my octopus urlsolutions - is the project group nameretrieve-hashicorp-vault-secrets is the project nameoctosecrets is the policy in vault which determines what access any JWT from this config gets
- 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
- List out the accessor value for
jwt_octopus/
vault auth list -format=json | jq -r '.["jwt_octopus/"].accessor' > accessor.txt
For example:
auth_jwt_73492eb5
- 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 \
mount_accessor=auth_jwt_73492eb5
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,
Clare
