Vault agent ignored listener unless cache stanza is specified

[aram535]

Describe the bug
This is either a documentation update request or functionality change. The only place that there is even a hint that the cache is in the caching documentation, where a small note that in a backwards way makes the use of the block necessary.

My suggestion is to remove the requirement that the cache is defined before the agent binds to an ip+port. Having a listener block defined by the user in the config is enough of an intent that that agent should bind. This is already a requirement since the cache requires at least one listener.

The less intrusive change would be that when starting the agent and no cache is present, a WARN message should pop when a listener is defined in the configuration.

To Reproduce
Steps to reproduce the behavior:
Start agent without a cache stanza, but with a listener stanza and see that it gives no warning/error that it will not be binding to a socket or IP.

Expected behavior
Cache stanza should not be required for the agent to bind and act as a proxy without caching. Or cache is badly named as it's obviously not caching secrets but tokens as well.

Environment:

• Vault Server Version (retrieve with vault status): 1.9.3, 1.8.7, 1.7.3
• Vault CLI Version (retrieve with vault version): 1.5.5, 1.8.7, 1.9.3, 1.9.5
• Server Operating System/Architecture: RHEL

Vault agent configuration file(s):

vault { 
  address = "https://vault-server:8200" 
}

auto_auth {
  method "approle" { 
    mount_path = "auth/approle" 
    config = {
      role = "approle-test-auth"
      role_id_file_path = "/opt/vault-agent/role-id"
      secret_id_file_path = "/opt/vault-agent/secret-id"
    }
  }
  sink "file" {
    config = {
      path = "/opt/vault-agent/token"
    }
  }
}

#cache { 
#  use_auth_auth_token = true 
#}

listener "tcp" {
  address = "127.0.0.1:8100"
  tls_disable = true
}

[ncabatoff]

Right now the proxy and the cache are pretty tightly tied together. We should make this clear in the documentation as you suggest, since it's impractical at least in the short term for us to support proxying without caching.

[aram535]

That makes sense -- I do question the removal of the 'bug' though. To me that is either bad design or a bug -- either way it should be addressed with more than just documentation.

While we're talking caches -- any ETA on the extension of caching functionality to KV V2? The auth and token renewal is nice but if the agent could be used for latency reduction that would be fantastic. It would reduce a lot of pressure from the cluster too as some bad acting apps that constantly read the same secrets don't need to travel all the way there and cause audit entries.

[ncabatoff]

To me that is either bad design or a bug -- either way it should be addressed with more than just documentation.

Call it bad design then, it's definitely an intentional limitation. To me bug implies an unintended defect, rather than a feature we haven't yet implemented. I agree its absence is very unfortunate, and I do hope it gets addressed sooner rather than later.

While we're talking caches -- any ETA on the extension of caching functionality to KV V2?

It is another often requested feature but I don't know when it will happen, sorry.

[VioletHynes]

Hi there! Going to close this issue as we've just implemented this as part of #18137 - this will be available in the next major release.

In short, you'll be able to use a listener stanza (and the API Proxy) irrespective of if a cache block is specified. The docs have also been clarified significantly.

Thanks for raising this issue!