#vault (2021-09)
Discussions related to Hashicorp Vault
2021-09-01
Q on Approles: When I create an approle, it gets a role-id and a secret-id. I understand that role-id is supposed to be static and can be generated once. Is the secret-id supposed to be generated multiple times ie. every time the service (ie. jenkins or terraform) needs it? Or is a human admin supposed to generate the secret every once in awhile?
The secret also can be long-lived / used multiple times. It can be rotated if you like
Tx. so should the service itself (ie. jenkins) ever need to retrieve its own role-id/secret-id?
# Allow Read and List to the prd approle so it can get the role-id / generate secret-id
path "auth/approle/role/app-myapp-prd-jenkins-readonly/*" {
capabilities = ["create", "read", "update", "list"]
}
My understanding is that that wouldn’t make a ton of sense to do. Like what credentials would jenkins use to read the approle path from Vault? If it already has vault auth, why does it need an approle? And if it doesn’t have auth yet, how could it read out the approle creds?
The “first secret problem” is hard. At my company we run our CI pipelines on AWS and use AWS IAM auth to Vault. But in a previous version of our CI, we use CircleCI Secrets to pass the Approle creds as the “first secret” to our CI. I’m not sure if Jenkins has an equivalent
I still have a very foggy idea of why we’re using secret-id then.. if it doesnt get dynamically short-live generated, isn’t it no different than a static username/password? role-id = username secret-id = password
I believe (from the admins) our environment (being provisioned with terraform) uses IP-whitelists. So long as the jenkins agent is in the right IP-pool, then vault will allow it to login.
resource "vault_approle_auth_backend_role" "app-myapp-npd-jenkins-readonly" {
backend = "approle"
role_name = "app-myapp-npd-jenkins-readonly"
token_period = 1800 // 30 Minutes
secret_id_num_uses = 0
token_policies = [
vault_policy.app-myapp-npd-jenkins-readonly.name
]
token_bound_cidrs = local.shared_services_jenkins_bound_cidr_list
}
It kind of is just a username/password, yeah. Kind of like in AWS how there are ACCESS_KEYs and SECRET_ACCESS_KEYs.
Funnily enough, hashicorp has just released a blog post yesterday trying to explain why use an AppRole: https://www.hashicorp.com/blog/how-and-why-to-use-approle-correctly-in-hashicorp-vault
yeah, having that “Trusted Entity” in their diagram to fetch/unwrap/send the secret key to your app is the tricky part. If you have that already, it’s great, but it’s not exactly solving the first-secret problem if it requires having access to an already authenticated service.
At the end of the day though, you sort of always need that trusted service. If you have Nomad / K8s as your trusted service, you’re trusting their auth, and in my case I use AWS IAM auth, where I trust AWS’s STS service. If you use CircleCI secrets, you’re trusting CircleCI’s vault cluster and however they have your jobs authenticate to it.
2021-09-02
Jenkins Q: I can login from my desktop to an approle using role-id & secret-id, but when I plug those same things into a jenkins credential and try it inside a pipeline, I’m getting an Access denied:
def secrets = [
[path: 'app-myapp-kv/dev/db/app_account', secretValues: [
[envVar: 'db_app_password', vaultKey: 'password']
]]
]
def configuration = [vaultUrl: '<https://vault.intranet.com>',
vaultCredentialId: 'app-myapp-npd-jenkins-readonly',
engineVersion: 2]
pipeline {
stages {
stage('Hello') {
steps {
withVault([configuration: configuration, vaultSecrets: secrets]) {
// anything
}
… the withVault block fails with an access denied:
[Pipeline] withVault
Retrieving secret: app-myapp-kv/dev/db/app_account
Access denied to Vault Secrets at 'app-myapp-kv/dev/db/app_account'
anybody seen this before? Google comes up blank.
one bug I found: I have a KV v2 engine, and my policy needs to have /data in my path:
path "app-myapp-kv/data/dev/*" {
capabilities = ["read", "list"]
}
I fixed it but am still getting Access Denied.
Retrieving secret: app-myapp-kv/data/dev/db/app_user
Access denied to Vault Secrets at 'app-myapp-kv/data/dev/db/app_user'
closing the loop: i believe it ended up being that very issue.. resolution: in policy , use /data/
path "app-myapp-kv/data/dev/*" {
capabilities = ["read", "list"]
}