On K3s, the Argo login offers "login via Vault" as an option. This resolves to vault.kubefirst.dev, which points to 127.0.0.1. The OIDC .well-known URL cannot resolve this because the 127.0.0.1 want is the host machine, not the container (returning the error Failed to query provider "https://vault.kubefirst.dev/v1/identity/oidc/provider/kubefirst": Get "https://vault.kubefirst.dev/v1/identity/oidc/provider/kubefirst/.well-known/openid-configuration": dial tcp 127.0.0.1:443: connect: connection refused).
Whilst this isn't a major problem as the user is able to login with a username and password, it is definitely a rough edge. Suggestions for this are:
remove the login via Vault button
configure an /etc/hosts file on the container so that vault.kubefirst.dev points to the correct pod IP
Code of Conduct
[X] I agree to follow this project's Code of Conduct
Which version of kubefirst are you using?
2.4.10
Which cloud provider?
k3d (local)
Which DNS?
None specific
Which installation type?
CLI
Which distributed Git provider?
None specific
Did you use a fork of
gitops-template
?No
Which Operating System?
Linux
What is the issue?
On K3s, the Argo login offers "login via Vault" as an option. This resolves to vault.kubefirst.dev, which points to
127.0.0.1
. The OIDC.well-known
URL cannot resolve this because the127.0.0.1
want is the host machine, not the container (returning the errorFailed to query provider "https://vault.kubefirst.dev/v1/identity/oidc/provider/kubefirst": Get "https://vault.kubefirst.dev/v1/identity/oidc/provider/kubefirst/.well-known/openid-configuration": dial tcp 127.0.0.1:443: connect: connection refused
).Whilst this isn't a major problem as the user is able to login with a username and password, it is definitely a rough edge. Suggestions for this are:
login via Vault
button/etc/hosts
file on the container so thatvault.kubefirst.dev
points to the correct pod IPCode of Conduct