-
Notifications
You must be signed in to change notification settings - Fork 253
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.
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
Support application credentials #1146
Comments
/good-first-issue |
We currently use Application Credentials with CAPO, one can just specify the I would like to clean this up 👍 /assign |
I think the key is going to be https://pkg.go.dev/github.com/gophercloud/gophercloud#ProviderClient.GetAuthResult However, I think it gets a bit messy here because the returned interface is insufficient so we may have to switch on the underlying type. Specifically I think we want to cast it to https://pkg.go.dev/github.com/gophercloud/gophercloud@v0.24.0/openstack/identity/v3/tokens#CreateResult, and call ExtractProject(). |
We discussed this in Slack and decided on refactoring https://app.slack.com/client/T09NY5SBT/CFKJB65G9/thread/CFKJB65G9-1645786779.195309 |
I can also confirm that it's usable today, having a secret with a clouds:
name-of-cloud-here:
identity_api_version: 3
auth:
auth_url: ${auth_url}
application_credential_id: ${credential_id}
application_credential_secret: ${credential_secret}
project_id: ${project_id}
auth_type: "v3applicationcredential" |
IIRC the problem with this is that OSC doesn't think it's valid. From memory I think it complains about trying to add scope to a scoped login? So yeah, but it's a major landmine not to be able to use the same clouds.yaml locally as in your cluster. |
We currently require an explicit project_id field in the clouds.yaml. This conflicts with the usual fields for Application Credentials, as they already include a scope, and setting another conflicts with that. In this commit, we instead save the returned project_id from the initial auth api call, and pass it around to all services using the Scope struct.
/kind feature
CAPO doesn't currently support application credentials. From memory the issue relates to parsing project id from the cloud credentials. It's easily solved, as this can be obtained from the authentication response from keystone and is already exposed by Gophercloud.
Consider for inclusion in 0.6: #1145
The text was updated successfully, but these errors were encountered: