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.

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

Closed
mdbooth opened this issue Feb 23, 2022 · 6 comments · Fixed by #1189
Closed

Support application credentials #1146

mdbooth opened this issue Feb 23, 2022 · 6 comments · Fixed by #1189
Assignees
Labels
good first issue Denotes an issue ready for a new contributor, according to the "help wanted" guidelines. kind/feature Categorizes issue or PR as related to a new feature.
Milestone

Comments

@mdbooth
Copy link
Contributor

mdbooth commented Feb 23, 2022

/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

@k8s-ci-robot k8s-ci-robot added the kind/feature Categorizes issue or PR as related to a new feature. label Feb 23, 2022
@mdbooth mdbooth added the good first issue Denotes an issue ready for a new contributor, according to the "help wanted" guidelines. label Feb 23, 2022
@mdbooth
Copy link
Contributor Author

mdbooth commented Feb 23, 2022

/good-first-issue

@apricote
Copy link
Member

We currently use Application Credentials with CAPO, one can just specify the project_id together with the application credentials and CAPO figures out the right thing to do, but the clouds.yaml can not be used by the OpenStack CLI like this.

I would like to clean this up 👍

/assign

@mdbooth
Copy link
Contributor Author

mdbooth commented Feb 23, 2022

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().

/cc @pierreprinetti @EmilienM

@apricote
Copy link
Member

We discussed this in Slack and decided on refactoring provider.NewClient to explicitly return the ProjectID and pass it around to the clients that need it.

https://app.slack.com/client/T09NY5SBT/CFKJB65G9/thread/CFKJB65G9-1645786779.195309

@MPV
Copy link

MPV commented Mar 22, 2022

I can also confirm that it's usable today, having a secret with a clouds.yaml that looks for example like this:

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"

@mdbooth
Copy link
Contributor Author

mdbooth commented Mar 22, 2022

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.

pierreprinetti pushed a commit to shiftstack/cluster-api-provider-openstack that referenced this issue Apr 22, 2024
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
good first issue Denotes an issue ready for a new contributor, according to the "help wanted" guidelines. kind/feature Categorizes issue or PR as related to a new feature.
Projects
No open projects
Status: Done
Development

Successfully merging a pull request may close this issue.

4 participants