Vault-secrets-operator

Vault
1

Hello everyone!

I was trying out the fledgeling vault-secrets-operator beta just now and got it working nicely in a kind container. However, when i moved along with my poc i ran into authentication issues towards my external vault, or internal but external to the k8s-cluster. It seems that the kubernetes auth method (which is the only one available at the moment) assumes that the vault instances are running in a cluster by binding the role to an actual serviceAccount.

Is there any way to come around that and tell the vault-server that it should bind to some other account than the default serviceAccount for the kubernetes auth method? Very helpful for assistance on this, i really like the new operator and want to have it working. Moving the vault-instance inside the k8s cluster is not an option in this case.

2

I have not yet worked with vault-secrets-operator, but I would guess the way it is expected to work, is that you would enable an instance of the Kubernetes auth method in your external Vault, configured to check tokens against the Kubernetes cluster you are deploying applications in.

You would create relevant Kubernetes auth roles and policies in the Vault, and then specify the appropriate values to link to what you have created in the spec.mount and spec.kubernetes.role fields of the VaultAuth resource: Vault Secrets Operator | Vault | HashiCorp Developer

3

When i configure vault i follow this guide and end up giving it a reference to the serviceAccount to be used. From what i can see this is the default serviceaccount in a cluster which my external vault cannot reach because it isn’t in the cluster.

vault write auth/kubernetes/role/role1 \
    bound_service_account_names=default \
    bound_service_account_namespaces=app \
    policies=dev \
    audience=vault \
    ttl=24h

I create VaultAuth and VaultController resources through the helm-chart in the same guide, but i target the external vault. The only difference is that the process is running on another host, but the steps repeated are the same.

4

Well, yes? The guide guides you in the case you are running Vault in the same cluster, so in my previous reply, I suggested the kinds of things you’d need to do differently to what the guide says to account for using an external Vault.

5

Hi @O5ten -
We just released RC1 of the operator a day ago, it includes the addition of AWS, AppRole and JWT auth methods as well!
For an external Vault connection you should just need to follow the standard vault k8s auth method docs: Kubernetes - Auth Methods | Vault | HashiCorp Developer and be sure that you provide a routable IP of the K8s API server in your VSO cluster for the k8s host field.

There is some example terraform code in the VSO repository that might be of help (although it uses a local Vault connection, you’d just need to set the IP+JWT accordingly): https://github.com/hashicorp/vault-secrets-operator/tree/main/test/integration/vaultauthmethods/terraform

6

I’ll be happy to give it a go! Thanks so far. :slight_smile:

7

Hi, how do you resolved the service account for the JWT token in the auth config for an external vault cluster?

[RESOLVED :partying_face:]
I saw that:

  • the default service account (vault-secrets-operator-controller-manager) for vault-secrets-operator is created and used by the deployment
  • (redhat ocp) a secret token is automatically created by the helm chart and named vault-secrets-operator-controller-manager-token-XXXXX but it is not bound in the SA manifest. You need to edit the secrets section and add it under the dockercfg-XXXXX token.
  • (k8s) you need to create manually the secret token and bind it to the SA
  • export SA_JWT_TOKEN, SA_CA_CRT, K8S_HOST and ISSUER with the following command:
    • export SA_JWT_TOKEN=$(kubectl get secret vault-secrets-operator-controller-manager-token-XXXXX -o jsonpath="{.data.token}" | base64 --d)
    • export SA_CA_CRT=$(kubectl get secret vault-secrets-operator-controller-manager-token-XXXXX -o jsonpath="{.data['ca\.crt']}" | base64 --d)
    • export ISSUER="$(kubectl get --raw /.well-known/openid-configuration | jq -r .issuer)"
    • export KUBE_HOST="$(kubectl config view --raw --minify --flatten -o jsonpath='{.clusters[].cluster.server}')"
  • validate the auth config on Vault with

    vault write auth/kubernetes/config
    token_reviewer_jwt=“$TOKEN_REVIEWER_JWT”
    kubernetes_host=“$KUBE_HOST”
    kubernetes_ca_cert=“$KUBE_CA_CERT”
    issuer=“$ISSUER”

2 Likes