I’ve been trying to get the drone-vaults plugin working all day and been struggling against the “x509: certificate signed by unknown authority” error. Specifically, this is the error every time the drone-vault container comes up:
time="2019-10-01T03:33:43Z" level=fatal msg="Post https://vault.our.domain.com/v1/auth/kubernetes/login: x509: certificate signed by unknown authority"
This is common when using self-signed certs, and we use self-signed certs with our Vault server. The common way around using this issue in vault is the
VAULT_CACERT env variable, which should point to the CA’s cert file. This works for the vault CLI or golang API library, but after digging through the drone-vault code, it appears drone-vault doesn’t use the vault API library.
It appears this error is coming from here: https://github.com/drone/drone-vault/blob/master/plugin/token/kubernetes/http.go#L20-L23
This is doing a straight HTTP POST request to the vault server as opposed to using Hashicorps vault API library to create a vault client. This means the
VAULT_CACERT variable will be ignored unless the drone-vault code deals with it itself (i.e. adds the CA certificate file to the trusted store of the httpClient before making the calls), which it doesn’t. This also means we can’t use
VAULT_SKIP_VERIFY to get around it by ignoring the certs in the response.
Basically, this means any Vault server using self-signed certs will be unsupported. The only way I’ve found around this is to mount the Vault CA certificate into the drone-vault container and manually add the certificate to the container’s trusted store by appending the certificate to the end of the
/etc/ssl/certs/ca-certificates.crt file before calling
/bin/drone-vault. Something like this (in Kubernetes):
spec: containers: - name: drone-vault image: drone/vault:latest command: ["sh", "-c", "cat /usr/local/share/ca-certificates/vault.crt >> /etc/ssl/certs/ca-certificates.crt && /bin/drone-vault"] ... volumeMounts: - mountPath: /usr/local/share/ca-certificates/vault.crt name: vault-tls subPath: ca.crt volumes: - name: vault-tls secret: secretName: vault-ca-cert
This is a short-term hack. I think the best way to address this would be to use the Vault API client library to authenticate with the Vault server instead of using raw HTTP requests. That way Vault ENV variables like
VAULT_SKIP_VERIFY would be honored correctly.
@bradrydzewski let me know if there’s an easy work-around for this issue that I’ve missed. Otherwise, is this something that should be tracked as a GitHub issue (I wanted to post here first)?