Closed archgrove closed 6 years ago
Additional notes: Using the env
command to set CREDHUB_CLIENT
and CREDHUB_SECRET
works fine. However, the user doesn't seem to work.
After discussing this with Adam over slack, it appears that the user we are configuring here isn't being respected by the cli for some reason. We set a client as well which does work.
I'll put a bug in our backlog to change the info command to give CREDHUB_CLIENT
and CREDHUB_SECRET
instead of username and password. For anyone who encounters this issue in the meantime you can run eval "$(concourse-up info <name> --region <region> --env)"
to export the necessary env vars. Then the credhub cli will work,
We've opened an issue on the credhub-cli repo regarding this issue: https://github.com/cloudfoundry-incubator/credhub-cli/issues/43
We recently upgraded our setup using
concourse-up
deploy. This resulted in the credhub CLI being unable to login to the credhub server any more (it fails with "The provided credentials are incorrect. Please validate your input and retry your request."). Assuming it was an upgrade glitch, we deployed an entirely newconcourse-up
d instance in a different AWS region; alas, even this virgin Concourse will not allowcredhub
logins.Digging a little deeper, we can see the
credhub-cli
user in UAA; indeed, we can login using the credentials if we hit the UAA port using a browser. Changing the password withuaac
does nothing; moreover, the user doesn't appear to be locked, or inactive. It seems to be part of the credhub groups.Debugging the UAA login within the credhub code, all I can see is UAA returning 401 to the (seemingly sensible) request to login to the
credhub_cli
client.Any advice would be most welcome.