Add arbitrary headers as ENV (like vault -header)

[ambis]

Is your feature request related to a problem? Please describe.

We got vault -header flag from #8754

We also have: https://registry.terraform.io/providers/hashicorp/vault/latest/docs#headers

But what we are missing is an ENV for this. I run scripts (and Terraform) that use Vault both locally and in CI. Locally I can talk directly to Vault behind Cloudflare Access without spesifying any extra headers, but in CI I need to specify service account token as a header.

Describe the solution you'd like
It would be super nice to be able to define VAULT_HEADERS="foo=bar bar=baz" in CI/CD variables. This way I would not need to touch my scripts in any way.

I think this would be equivalent to VAULT_CLIENT_CERT and VAULT_CLIENT_KEY, which I used previously with Cloudflare provided mTLS to protect my Vault.

The ONLY thing is, since -header and TF provider's header {} can be spesified multiple times, and ENV's cannot be, is a whitespace the correct separator for headers in the env? I can see this being quite the problem.

[ambis]

I think here is a precedent for VAULT_HEADER (not HEADERS):

https://www.vaultproject.io/docs/commands#vault_mfa

If a MFA method expects multiple credential values, or if there are multiple MFA methods specified on a path, then the CLI flag -mfa should be used.

"If you need to provide more than one header, please use the vault cli -header flag multiple times."

[ambis]

Of course I forgot that CF Access takes TWO headers to function:

CF-Access-Client-ID:
CF-Access-Client-Secret:

So it would have to be VAULT_HEADERS="CF-Access-Client-ID=my-client-id CF-Access-Client-Secret=my-client-secret" if this was to serve it's purpose.

[ambis]

Nevermind this, reply above is what would be needed (now that I got the service tokens actually working).

IGNORE THE REST:
Personal journey of discovery going on in here :D

https://developers.cloudflare.com/cloudflare-one/tutorials/cli/#using-the-token-as-an-environment-variable

VAULT_HEADER would be enough in the case of CF Access:

# In CI, one would use the client id and secret id to fetch the JWT token, and not use cloudflared
export TOKEN=$(cloudflared access token -app=http://example.com)
VAULT_HEADER="cf-access-token=$TOKEN" 
vault ...
# or
terraform plan

While fetching the token could not be done in CI/CD variables, one could do it in the CI job outside of the script/terraform being run.

[ambis]

While I still don't think this feature would be a bad idea, I no longer have need for it!

I'll try to explain my solution for Gitlab CI access via cloudflared:

Vault host's cloudflared config.yaml

ingress:
  # This is for regular users with browser etc, login via IdP
  - hostname: vault.example.com
    service: http://127.0.0.1:8081
  # This service is a socks proxy, used by cloudflared in CI and locally in CLI
  # See: https://developers.cloudflare.com/cloudflare-one/tutorials/kubectl/
  - hostname: vault-proxy.example.com
    service: tcp://127.0.0.1:8081
    originRequest:
      proxyType: socks

Gitlab CI/CD env variables:

• TUNNEL_SERVICE_TOKEN_ID (value created in the zero trust dashboard)
• TUNNEL_SERVICE_TOKEN_SECRET (value created in the zero trust dashboard)

GitLab CI Job:

script:
  # Create a background job of cloudflared websocket tunnel
  - nohup cloudflared access tcp --hostname https://vault-proxy.example.com --url 127.0.0.1:1234 &
  # Export proxy info for Vault only
  - export VAULT_HTTP_PROXY=socks5://127.0.0.1:1234
  # http because traffic goes directly to the origin server through the socks proxy tunnel
  - export VAULT_ADDR=http://vault.example.com
  # Now vault works, terraform vault provider works...
  - vault status

[bullno1]

Seconded this.

The problem is not so much that it is not possible to add headers.
The problem is that the -header flags and all other http flags have to go into very specific positions.
If they were more flexible, that would not be a problem.

For example one could do:

alias my_vault="vault -header custom-header=value -token $(token-store)"
my_vault some-command -other-flag=other-value

It's not show stopping but it's inconvenient to add $MY_FLAGS to every vault command while you are trying to troubleshoot.

Is there any specific reason why the command parsing is like that?

Would it be possible to submit a change to the way flags are parsed?

Come to think of it, I think I can just write a quick wrapper to reorder the flags.

[kalote]

Hey,

For me, I can successfully use the vault -header to add the Cloudflare Zero Trust tokens, and it works fine from local environment.
But, when I try to add the same credentials as headers in my vault-secrets-operator vaultConnection, it doesn't work and I get 403 from CloudFlare.

Do you know if the headers are correctly used by the vault-secrets-operator?

My helm chart looks like this (just the important part is below):

operator:
  enabled: true
  controller:
    replicas: 1
  defaultVaultConnection:
    enabled: true
    address: "https://vault.example.com"
    skipTLSVerify: false
    headers:
      CF-Access-Client-Id: "1f..."
      CF-Access-Client-Secret: "58..."
  defaultAuthMethod:
    enabled: false

EDIT: Issue has been opened in VSO github hashicorp/vault-secrets-operator#622

[quinten1333]

Hi all,

Awesome that this is possible!

I noticed that this code isn't pushed to the 1.17.5 version tags which currently is the latest.
When will this feature be released?

[VioletHynes]

This should be released in 1.18.0, which should release soon. We generally don't backport features/improvements to older versions except in exceptional cases (only bug fixes/security fixes).

[quinten1333]

Hi Violet,

Okay, then I'll wait for 1.18.0. Thanks for the fast reply!

Edit for future readers: V1.18.0 has been released.