Vault plugin for GoCD fails to retrieve secret - hashicorp-vault

I am running GoCD installed via Helm in my kubernetes cluster. I've installed the Vault plugin (https://github.com/gocd/gocd-vault-secret-plugin), and have configured it successfully in the "Secrets Management" tab under Admin. My configuration looks like:
id: vault
Vault URL: https://myvaultserver.com
Vault Path: /my/path/to/secrets
Auth Method: Token
Token: MY_AUTH_TOKEN
Rules:
Allow All *
However when I assign a secret {{SECRET:[vault][password]}} to an environment variable my jobs fail after agent registration with this error:
com.thoughtworks.go.plugin.access.exceptions.SecretResolutionFailureException: Expected plugin to resolve secret param(s) `password` using secret config `vault` but plugin failed to resolve secret param(s) `password`. Please make sure that secret(s) with the same name exists in your secret management tool.
I can retrieve this just fine with vault CLI:
=========== Data ===========
Key Value
--- -----
password My_Password
What am I missing?

Related

ERROR: (gcloud.builds.submit) INVALID_ARGUMENT: could not parse service account URL

I want to use a custom Service Account to build my docker container with Cloud Build. Using gcloud iam service-accounts list and gcloud config list I have confirmed that the service account is in the project environment and I used gcloud services list --enabled to check that cloudbuild.googleapis.com is enabled. I get the error: ERROR: (gcloud.builds.submit) INVALID_ARGUMENT: could not parse service account URL. I tried all of the available service accounts and I tried with and without the prefix path. What is the correct URL or config after steps to get the service account working?
steps:
- name: 'gcr.io/cloud-builders/docker'
args: ['build', '-t', 'gcr.io/my-project-id/my-app']
images: ['gcr.io/my-project-id/my-app']
serviceAccount: 'projects/my-project-id/serviceAccount/my-sa#my-project-id.iam.gserviceaccount.com'
options:
logging: CLOUD_LOGGING_ONLY
The build config for serviceAccount references this page and there's an example that shows the structure:
projects/{project-id}/serviceAccounts/{service-account-email}
So, it follows Google's API convention of a plural noun (i.e. serviceAccounts) followed by the unique identifier.
Another way to confirm this is via APIs Explorer for Cloud Build.
The service's Build resource defines serviceAccount too.

InfluxDB2 on Kubernetes not using existing admin password/token secret

I'm installing InfluxDB2 on a Kubernetes cluster (AWS EKS) and in the helm chart I specify an existing secret name "influxdb-auth" for admin user credentials. When I try to login to the web admin interface, it does not accept the password or token from that secret. If I don't specify an existing secret, it automatically creates a secret "influxdb2-auth" and I can retrieve and use the password successfully, but it will not use the existing secret. Also when I specify the existing secret "influxdb-auth" it does not create a secret "influxdb2-auth" so I can't retrieve the password it has generated. I have tried naming the existing secret "influxdb2-auth" but that also did not work. Any ideas on what the problem might be?
Section from values.yaml:
## Create default user through docker entrypoint
## Defaults indicated below
##
adminUser:
organization: "test"
bucket: "default"
user: "admin"
retention_policy: "0s"
## Leave empty to generate a random password and token.
## Or fill any of these values to use fixed values.
password: ""
token: ""
## The password and token are obtained from an existing secret. The expected
## keys are `admin-password` and `admin-token`.
## If set, the password and token values above are ignored.
existingSecret: influxdb-auth
To anyone here coming here from the future. Make sure you run:
echo $(kubectl get secret influxdb-influxdb2-auth -o "jsonpath={.data['admin-password']}" --namespace monitoring | base64 --decode)
after first installation. First time influxdb2 starts it will setup task, subsequent helm install/upgrade seem to save new password in the secret which isn't on the file system.
I had to delete content of PVC for influxdb and rerun installation.

Jenkinsx Nexus pod is going into "CrashLoopBackOff" state with "Login to nexus failed with the default password and the provided password secret file"

I am trying to create a pipeline in Jenkinsx with Openshift cluster. The pipeline is successfully created but the springboot application build fails with "Nexus 401 authentication error".
So restarted all the pods under jx namespace. All the pods came up and running except the nexus pod.
The nexus pod is going into "CrashLoopBackOff" error with the following error:
"ERROR: Login to nexus failed. Tried both the default password and the provided password secret file"
I have observed that there is a nexus secret with the user and password details. I am unable to login to nexus dashboard using those credentials.
Credentials:
username: admin
password: hUw3nNQ!0eD,uuBS9qm9
I also suspect that the issue might be because of the exclamation in the password.
Please let me know if there is anyway to update the secrets to login to nexus.

How to retrieve secret data from vault API using AppRole?

My HashiCorp vault instance is runnning properly on CentOS7. I enabled AppRole authentication, created a policy and a role, enabled secret engine and created a secret for a client application.
I can retrieve the secret data using root CLI but I can't figure out how to get secret data from HTTP API with my application role using curl. I tried a few endpoint combinations without success. Retrieving the client token works, but I can't get secret data itself.
I wonder if the API endpoint is correct or if there is another setting in play.
Authentication method
vault auth enable approle
Policy
# File: my_app /etc/vault/my_app.hcl
path "kv/data/foo/*" {
capabilities = ["read", "list"]
}
# Command line
vault policy write my_app /etc/vault/my_app.hcl
Role
vault write auth/approle/role/my_app policies="my_app"
Secret creation
vault kv put kv/data/foo/user#domain.tld password=1234
API call token request
curl --request POST --data '{"role_id": "xxxxxxxxxxxxxxxxx", "secret_id": "xxxxxxxxxxxxxxxxxxxx"}' http://127.0.0.1:8200/v1/auth/approle/login | jq
Result: Token is properly retrieved
API call for secret data request
export VAULT_CLIENT_TOKEN=XXXXXXX
curl --header "X-Vault-Token: $VAULT_CLIENT_TOKEN" --request GET "http://127.0.0.1:8200/v1/kv/data/foo/user#domain.tld"
Result : No secret data retrieved
Output:
{"errors":[]}
CLI call for secret data
vault kv get -field=password kv/data/foo/user#domain.tld
Output:
1234
Global settings
vault secrets list
Path Type Accessor Description
---- ---- -------- -----------
cubbyhole/ cubbyhole cubbyhole_xxxxxxxx per-token private secret storage
identity/ identity identity_xxxxxxxx identity store
kv/ kv kv_xxxxxxxx n/a
sys/ system system_xxxxxxxx system endpoints used for control, policy and debugging

Hashicorp Vault cli return 403 when trying to use kv

I set up vault backed by a consul cluster. I secured it with https and am trying to use the cli on a separate machine to get and set secrets in the kv engine. I am using version 1.0.2 of both the CLI and Vault server.
I have logged in with the root token so I should have access to everything. I have also set my VAULT_ADDR appropriately.
Here is my request:
vault kv put secret/my-secret my-value=yea
Here is the response:
Error making API request.
URL: GET https://{my-vault-address}/v1/sys/internal/ui/mounts/secret/my-secret
Code: 403. Errors:
* preflight capability check returned 403, please ensure client's policies grant access to path "secret/my-secret/"
I don't understand what is happening here. I am able to set and read secrets in the kv engine no problem from the vault ui. What am I missing?
This was a result of me not reading documentation.
The request was failing because there was no secret engine mounted at that path.
You can check your secret engine paths by running vault secrets list -detailed
This showed that my kv secret engine was mapped to path kv not secret as I was trying.
Therefore running vault kv put kv/my-secret my-value=yea worked as expected.
You can enable secret engine for specific path
vault secrets enable -path=kv kv
https://www.vaultproject.io/intro/getting-started/secrets-engines
You need to update secret/my-secret to whichever path you mounted when you enable the kv secret engine.
For example, if you enable the secret engine like this:
vault secrets enable -version=2 kv-v2
You should mount to kv-v2 instead of secret
vault kv put kv-v2/my-secret my-value=yea