Error on Token Injection

[sidewinder12s]

Describe the bug
It appears that when the injector is set to inject the Vault Token into the running pod, it throws a somewhat confusing error. I don't think it actually impacts functionality as I appear to still have the token.

To Reproduce
Steps to reproduce the behavior:

1. Deploy a sample app with the token injection behavior

Application deployment:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: sidecar-test
  namespace: default
  labels:
    app: sidecar-test
spec:
  selector:
    matchLabels:
      app: sidecar-test
  replicas: 1
  template:
    metadata:
      annotations:
        vault.hashicorp.com/agent-inject: "true"
        vault.hashicorp.com/role: "default"
        vault.hashicorp.com/agent-inject-token: "true" # Inject the Token at /vault/secrets/token
      labels:
        app: sidecar-test
    spec:
      serviceAccountName: default
      containers:
        - name: sidecar-test
          image: jweissig/app:0.0.1
          env:
            - name: "VAULT_TOKEN" # Expose the Vault Token in the container on the common environment variable
              value: "$(cat /vault/secrets/token)"

==> Vault agent started! Log data will stream in below:

==> Vault agent configuration:

                     Cgo: disabled
               Log Level: info
                 Version: Vault v1.5.4
             Version Sha: 1a730771ec70149293efe91e1d283b10d255c6d1

2020-11-17T00:47:46.752Z [INFO]  sink.file: creating file sink
2020-11-17T00:47:46.752Z [INFO]  sink.file: file sink configured: path=/home/vault/.vault-token mode=-rw-r-----
2020-11-17T00:47:46.753Z [INFO]  template.server: starting template server
2020/11/17 00:47:46.753295 [INFO] (runner) creating new runner (dry: false, once: false)
2020/11/17 00:47:46.753820 [INFO] (runner) creating watcher
2020-11-17T00:47:46.814Z [INFO]  sink.server: starting sink server
2020-11-17T00:47:46.814Z [INFO]  auth.handler: starting auth handler
2020-11-17T00:47:46.814Z [INFO]  auth.handler: authenticating
2020-11-17T00:47:51.855Z [INFO]  auth.handler: authentication successful, sending token to sinks
2020-11-17T00:47:51.855Z [INFO]  auth.handler: starting renewal process
2020-11-17T00:47:51.855Z [INFO]  sink.file: token written: path=/home/vault/.vault-token
2020-11-17T00:47:51.855Z [INFO]  sink.server: sink server stopped
2020-11-17T00:47:51.855Z [INFO]  sinks finished, exiting
2020-11-17T00:47:51.855Z [INFO]  template.server: template server received new token
2020/11/17 00:47:51.855787 [INFO] (runner) stopping
2020/11/17 00:47:51.855820 [INFO] (runner) creating new runner (dry: false, once: false)
2020/11/17 00:47:51.855997 [INFO] (runner) creating watcher
2020/11/17 00:47:51.856045 [INFO] (runner) starting
2020/11/17 00:47:51.864045 [WARN] vault.read(auth/token/lookup-self): failed to check if auth/token/lookup-self is KVv2, assume not: Error making API request.

URL: GET http://vault.vault.svc:8200/v1/sys/internal/ui/mounts/auth/token/lookup-self
Code: 403. Errors:

* preflight capability check returned 403, please ensure client's policies grant access to path "auth/token/lookup-self/"
2020-11-17T00:47:51.870Z [INFO]  auth.handler: renewed auth token
2020/11/17 00:47:51.969717 [INFO] (runner) rendered "(dynamic)" => "/vault/secrets/token"
2020/11/17 00:47:51.969773 [INFO] (runner) stopping
2020-11-17T00:47:51.969Z [INFO]  template.server: template server stopped
2020/11/17 00:47:51.969851 [INFO] (runner) received finish

Expected behavior
It should just inject the token without errors. I am also fairly certain I do not have the default token policy disabled for this role which should provide permissions to the auth/token/lookup-self endpoint. I do successfully have the token in my environment however.

Environment

• Kubernetes version: 1.18
  • Distribution or cloud vendor (OpenShift, EKS, GKE, AKS, etc.): EKS
  • Other configuration options or runtime services (istio, etc.):
• vault-k8s version: 0.6.0
• vault version: 1.5.4

Additional context
Wasn't really sure why it was trying to read the UI endpoint vs just reading auth/token/lookup-self

[Carles-Figuerola]

While this seems to be a warning rather than an error, as the secret seems to be injected properly, I am also getting the same error. I added this policy to try to make it go away to no avail:

path "auth/token/lookup-self/" {
  capabilities = ["list"]
}

[tvoran]

This should be fixed with #250; closing for now.