Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Injected config tries to use IRSA token instead of the k8s service account token #544

Open
ghost opened this issue Nov 1, 2023 · 0 comments
Open

Injected config tries to use IRSA token instead of the k8s service account token #544

ghost opened this issue Nov 1, 2023 · 0 comments
Labels
bug Something isn't working

Comments

@ghost
Copy link

ghost commented Nov 1, 2023 •
edited by ghost
Loading

Describe the bug
When the Vault Agent sidecar is injected into a pod that is also injected with IRSA, the token_path uses the IRSA token instead of the actual Kubernetes service account token even when configured to use the Kubernetes auth method. This prevents the Vault Agent sidecar from being able to authenticate to Vault.

To Reproduce
Steps to reproduce the behavior:

  1. Deploy pod annotated for vault-agent injection that is configured to use a service account that has an IRSA annotation.
  2. Vault Agent logs will show failed authentication requests
  3. Inspecting the containers VAULT_CONFIG env variable will show that token_path is configured to use /var/run/secrets/eks.amazonaws.com/serviceaccount instead of var/run/secrets/kubernetes.io/serviceaccount.

Expected behavior
Vault agent is able to authenticate to Vault using the Kubernetes auth method without having to specify vault.hashicorp.com/auth-config-token-path to ensure the wrong token is not used.

Environment

  • Kubernetes version:
    • EKS 1.24
  • vault-k8s version:
    • 1.3.1

Additional context
We discovered this problem after configuring the Vault Injector to use an external address.

The need to use vault.hashicorp.com/auth-config-token-path as a workaround is mentioned in #456 (comment), however I believe this should not have to be necessary.
@ghost ghost added the bug Something isn't working label Nov 1, 2023
@ghost ghost changed the title Injected config tries to use IRSA token instead of the k8s service account token. Injected config tries to use IRSA token instead of the k8s service account token Nov 1, 2023
@ghost ghost mentioned this issue Nov 1, 2023
Open
uchanchlani pushed a commit to uchanchlani/vault-k8s that referenced this issue Jan 17, 2024
Auth config block must support common custom arguments in environment…
224c1ee 
… variables and flags

Also fixes using AWS IRSA token by mistake if both included in the pod's volume hashicorp#544
This maybe a better fix then the proposed hashicorp#545 pull request as this is likely more future-proof
 to other third party k8s provider launching their own Service Account Token injection, assuming
 the third party k8s provider will follow the unsaid convention of injecting the token in the
 <third.party.url>/serviceaccount/token path
@uchanchlani uchanchlani mentioned this issue Jan 17, 2024
Open
uchanchlani pushed a commit to uchanchlani/vault-k8s that referenced this issue Jan 17, 2024
Auth config block supports common arguments from env and flags hashic…
804f57a 
…orp#577

Also fixes using AWS IRSA token by mistake if both included in the pod's volume hashicorp#544
This maybe a better fix then the proposed hashicorp#545 pull request as this is likely more future-proof
 to other third party k8s provider launching their own Service Account Token injection, assuming
 the third party k8s provider will follow the unsaid convention of injecting the token in the
 <third.party.url>/serviceaccount/token path
uchanchlani added a commit to uchanchlani/vault-k8s that referenced this issue Jan 17, 2024
@uchanchlani
Auth config block supports common arguments from env and flags hashic…
654386a 
…orp#577

Also fixes using AWS IRSA token by mistake if both included in the pod's volume hashicorp#544
This maybe a better fix then the proposed hashicorp#545 pull request as this is likely more future-proof
 to other third party k8s provider launching their own Service Account Token injection, assuming
 the third party k8s provider will follow the unsaid convention of injecting the token in the
 <third.party.url>/serviceaccount/token path
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug Something isn't working
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
0 participants