Keystone Application Credentials Controller

[berendt]

What would you like to see implemented?

It should be possible to manage application credentials with ORC.

Additional information

No response

Link to reference documentation

No response

[mandre]

Yes, that would be great.

[berendt]

I think @gndrmnn will start with this shortly on our side.

[mandre]

Woah, that was fast!

[gndrmnn]

@mandre The ApplicationCredentials API wants a UserID even for querying by it's own ID not name [1]. I even tried to cheese it with an empty string for the UserID to no avail. This breaks the default interface GetOSResourceByID and unfortunately I think that means I will need to re-implement the reconciler similar to how it is done in RouterInterface, right?

[1] https://docs.openstack.org/api-ref/identity/v3/#show-application-credential-details

[gndrmnn]

@mandre The ApplicationCredentials API wants a UserID even for querying by it's own ID not name [1]. I even tried to cheese it with an empty string for the UserID to no avail. This breaks the default interface GetOSResourceByID and unfortunately I think that means I will need to re-implement the reconciler similar to how it is done in RouterInterface, right?

[1] https://docs.openstack.org/api-ref/identity/v3/#show-application-credential-details

OK, since this is only relevant for the "GetApplicationCredential" operation, I can work around this for now by modifying the generated osClient for ApplicationCredential to first retrieve the gophercloud auth context and extract the current userID. If this yields no match, iterate over all users known in the current context. This should then also work if we run k-orc as admin user with access to more/all user tokens.

IMHO, I think this is a mistake in the design of the OpenStack API. It should not be necessary to specify the userID if we can address ApplicationCredentials by (guaranteed unique) ID. Permission checks would be possible either way. Anyway, k-orc has to somehow work around this as it depends on being able to uniquely address resources by name or ID.

[mandre]

For the creation or import, we would have a UserRef, so we should be able to get the UserID via the dependency. I assume the problem is with when importing by ID (https://k-orc.cloud/user-guide/#import-vs-create)? Have you checked if there's a way to also specify the UserId in that case? Something like:

apiVersion: openstack.k-orc.cloud/v1alpha1
kind: ApplicationCredential
metadata:
  name: imported-cred
spec:
  cloudCredentialsRef:
    cloudName: openstack
    secretName: openstack-clouds
  managementPolicy: unmanaged
  import:
    id: "12345678-1234-1234-1234-123456789abc"
    userID: "abcdabcd-1234-1234-1234-123456789abc"

[mandre]

We would likely need to update cmd/resource-generator/data/api.template to permit adding extra types in the <Resource>Import struct.

[gndrmnn]

For the creation or import, we would have a UserRef, so we should be able to get the UserID via the dependency.

Right, I understand since the user controller (#583) is not yet merged, I am not able to use a UserRef for the time being.

I assume the problem is with when importing by ID (https://k-orc.cloud/user-guide/#import-vs-create)? Have you checked if there's a way to also specify the UserId in that case? Something like:

Yes, it is absolutely possible to specify a UserID in the filter and make it work. The fundamental problem is, that ORC is using a single string (ID or name, usually ID) to query the current state of any given OpenStack resource in the default reconciler. The specific calls that are causing the issue are:

call 1
call 2
call 3

This is only relevant after the initial creation/import. Effectively, ORC assumes that every resource can be retrieved using a single string. This is not true for application credentials. If ORC was able to take a generic type for the resourceID, we could create a struct for application credentials containing both userID + resourceID and pass that in all locations. That would be a major refactor though, as existing controllers would need to set this generic type to string everywhere.

However, I was able to work around this by overwriting the generated adapter actuator.osClient.GetApplicationCredential which now uses the userID belonging to the token which ORC uses to communicate with OpenStack. As a fallback, all application credentials of all users are queried until the one with the correct resource ID is found. Otherwise, I return a gophercloud.ErrResourceNotFound which satisfies all actuator needs. This works in all my tests, but is far from pretty. Unfortunately, this is the reality of the OpenStack API.

@mandre I have two new questions though:

1. Would it be acceptable, if ORC requires the user to specify a secret for the ApplicationCredential? The API allows the user to leave secret empty and let OpenStack create a random secret, but then only the very first JSON response contains the secret once and we would have to come up with a way to keep the secret over more than one status generation...

2. Is there currently a way to reference the authenticated OpenStack user in E2E tests?

[mandre]

For the creation or import, we would have a UserRef, so we should be able to get the UserID via the dependency.

Right, I understand since the user controller (#583) is not yet merged, I am not able to use a UserRef for the time being.

I assume the problem is with when importing by ID (https://k-orc.cloud/user-guide/#import-vs-create)? Have you checked if there's a way to also specify the UserId in that case? Something like:

Yes, it is absolutely possible to specify a UserID in the filter and make it work. The fundamental problem is, that ORC is using a single string (ID or name, usually ID) to query the current state of any given OpenStack resource in the default reconciler. The specific calls that are causing the issue are:

call 1 call 2 call 3

This is only relevant after the initial creation/import. Effectively, ORC assumes that every resource can be retrieved using a single string. This is not true for application credentials. If ORC was able to take a generic type for the resourceID, we could create a struct for application credentials containing both userID + resourceID and pass that in all locations. That would be a major refactor though, as existing controllers would need to set this generic type to string everywhere.

However, I was able to work around this by overwriting the generated adapter actuator.osClient.GetApplicationCredential which now uses the userID belonging to the token which ORC uses to communicate with OpenStack. As a fallback, all application credentials of all users are queried until the one with the correct resource ID is found. Otherwise, I return a gophercloud.ErrResourceNotFound which satisfies all actuator needs. This works in all my tests, but is far from pretty. Unfortunately, this is the reality of the OpenStack API.

Oh, right. I see the problem now. I think your workaround is acceptable, and there's not much we can really do. Do you think we should, at first, limit the management of application credentials to the authenticated user (so that we don't have to iterate over all the users in GetApplicationCredential())? Or did you intend to have a privileged user create application credentials for others?

@mandre I have two new questions though:

1. Would it be acceptable, if ORC requires the user to specify a `secret` for the ApplicationCredential? The API allows the user to leave `secret` empty and let OpenStack create a random secret, but then only the very first JSON response contains the secret once and we would have to come up with a way to keep the secret over more than one status generation...

Of course! We can implement support step by step.
Regarding the problem with the secret missing from subsequent responses, it shouldn't be too difficult to implement on our side (if it's non-nul, save it, otherwise don't touch it). We should also not return the secret in plain text in the status, but I imagine it would be a reference to a Kubernetes secret.

2. Is there currently a way to reference the authenticated OpenStack user in E2E tests?

Not yet, we didn't have a use for it.

[gndrmnn]

Or did you intend to have a privileged user create application credentials for others?

Yeah, I think we need this for our use-case

Of course! We can implement support step by step.

👍

Not yet, we didn't have a use for it.

@mandre This is proving harder than expected, because we need the userID which is sadly not present in the clouds.yml file. For now, I have created a workaround for this by replacing the word token with the userID of the user currently authenticated via clouds.yml.
That being said, the E2E tests work now. I have trouble getting the linter happy because I use userID instead of userRef. However, since #657 is not merged yet, I can not use a KubernetesNameRef here since we don't have user resources in ORC.

Are you going to require #657 to be merged, before ApplicationsCredentials are going to be merged? In that case, I could help OP of #657 to finish the PR and rebase my branch to be using UserRef.

Either way, I would appreciate an initial review of #671 as the tests are passing now

[mandre]

Hey @gndrmnn, that's great! I'll take a look at your PR this week for early feedback. Regarding the direct user ID ref, we'll want to merge #657 first (it's close to ready, and I believe Daniel is currently working on on it), so you'd be able to reference User resources.