When I enabled Kubernetes Auth Method, I configured parameters which Kubernetes host is API Server Endpoint of EKS, Kubernetes CA Certificate is CA Certificate on EKS or Vault Server Pod, and Token Reviewer JWT is data.token of Secret owned by ServiceAccount of Vault Server Pod.
And when I created role, I configured parameters which Bound service account names is *, Bound service account namespaces is *, and Generated Token's Policies is a policy as follows.
I’m in over my head, but nothing jumped out as obviously missing.
Do either of this troubleshooting suggestions apply in your case?
I was also wondering about these considerations, from the second link. (Looks like this portion became the Learn tutorial on the same subject.)
Other Things Worth Noting
Errors for both service account and namespace will be manifest themselves as pods perpetually in the Init phase, never reaching ready. Errors are found within the vault-agent-init container logs, detailing the authentication error in clear English.
The token, both init and sidecar containers use to communicate with Vault, lives locally within the container at the following path: /home/vault/.token. Unsurprisingly, the token is not mounted into the primary container within the pod, making direct communications between Vault and primary container difficult.
First, I’m trying to deploy vault with vault-agent-injector to the single EKS cluster using official helm chart, so my case isn’t thought to match second link case such as using external vault cluster.
I wondered about your quote:
The token, both init and sidecar containers use to communicate with Vault, lives locally within the container at the following path: /home/vault/.token.
so that I investigated that path within the init container such as the following.
$ kubectl -n sample-app exec -it sample-app-deployment -c vault-agent-init -- cat /home/vault/.token
cat: can't open '/home/vault/.token': No such file or directory
Does this have any problems?
Next, I investigated internal DNS configurations of init container, discussed in the first link.
I thought this indicates http://vault.vault.svc:8200 might not be resolved name in the init container.
Then, although I tried to resolve name of vault server pod as http://vault.vault.svc.cluster.local:8200 by editing injector.externalVaultAddr in the helm chart, 403 error occured.
The title of this topic describes a very broad error with many possible causes, and has been repeatedly revived by different posters over the years - leading to a complex history of potentially unrelated issues.
Anyone experiencing a problem here should start their own fresh topic in the forum, and carefully describe their OWN observations and environment.