add agent-enable-quit annotation

[tvoran]

New annotation to enable the /agent/v1/quit endpoint on an injected agent. This option defaults to false, and will be set if true on the existing cache listener, or a new localhost listener with a basic cache stanza configured since that's required for an agent listener.

The agent-cache-listener-port annotation can be used to change the port.

Example Job:

apiVersion: batch/v1
kind: Job
metadata:
  name: quit

spec:
  template:
    metadata:
      annotations:
        vault.hashicorp.com/agent-inject: "true"
        vault.hashicorp.com/role: "internal-app"
        vault.hashicorp.com/agent-inject-secret-database-config.txt: "internal/data/database/config"
        vault.hashicorp.com/agent-inject-template-database-config.txt: |
          {{- with secret "internal/data/database/config" -}}
          postgresql://{{ .Data.data.username }}:{{ .Data.data.password }}@postgres:5432/wizard
          {{- end -}}
        vault.hashicorp.com/agent-enable-quit: "true"
    spec:
      serviceAccountName: internal-app
      containers:
      - name: nginx
        image: nginx
        command: ["/bin/bash", "-c"]
        args:
          - |
            sleep 10
            curl -X POST http://localhost:8200/agent/v1/quit

      restartPolicy: Never
  backoffLimit: 4

[tomhjp]

In the vast majority of cases, there will only be 1 listener, but should we maybe set it on all listeners? Just choosing the first one seems surprising, and for users who want to finesse which listeners it is and isn't on, I think it's ok to not give them a dedicated annotation for that but let them fully define their own config.

[tvoran]

I don't think the injector can currently create a config with more than one listener, can it? I think the only way to inject an agent that has multiple listener is to specify the full config in a configmap, and in that case this code wouldn't be triggered.

But I can add a loop since it does look a little jarring to only reference listener[0] here.

[tomhjp]

Oh I forgot about that - makes sense.

[tomhjp]

Do we need to do anything if it's false, given it defaults to false?

[tvoran]

Good question, and I went back and forth on this quite a bit. It would certainly be simpler to only set the enable_quit config if the annotation has been set to true, and maybe that's the best to do for now.

Currently EnableQuit is setup as a pointer so the config is set only if the annotation was specified (true or false), but since it defaults to false in the agent, just omitting the config setting here should be sufficient. And it's probably very unlikely that we'd ever default to enabling the quit endpoint on the vault agent side.

[tomhjp]

Yeah I think that seems like a safe bet for now 👍

[tvoran]

Updated in b316106 to only set the config if EnableQuit is true.

[tomhjp]

LGTM 👍