Use clientconfig utils for authentication

Lirt commented 3 years ago

Gophercloud provides special utils library that eases openstack authentication means. This allow us to simply authenticate against Openstack using files in clouds.yaml format, application credentials and environment variables with almost no additional logic inside of the plugin.

The authentication logic is now:

Authenticate using env. vars including application credentials
Authenticate using files in default locations together with cloud name specified as environment variable OS_CLOUD

One potentially dangerous change is that AllowReauth cannot be specified on auth options in clientconfig. We will need to restest reauthentication and failed authentication after successful authentication.

Tested workflows:

[x] Authenticate using standard environment variables.
[x] Authenticate using application credentials in environment variables.
[x] Authenticate using clouds.yaml in ~/.config/openstack/clouds.yaml.
[x] Authenticate using clouds.yaml in /etc/openstack/clouds.yaml.
[x] Authenticate using clouds.yaml in ./clouds.yaml.
[x] Authenticate to swift located outside of openstack's keystone (swiftstack).
[x] Authenticate to both swift located outside of openstack and also to cinder inside of openstack.
[x] Test reauthentication.
[x] Test authentication after previous was failed.

This PR will close https://github.com/Lirt/velero-plugin-for-openstack/issues/15 and https://github.com/Lirt/velero-plugin-for-openstack/issues/25

Signed-off-by: Ondrej Vasko ondrej.vaskoo@gmail.com

Lirt commented 3 years ago

All workflows were tested successfully.

@AlwaySummit, @francestang1117 if you have some time, you can test this release by changing velero plugin image to lirt/velero-plugin-for-openstack:auth-clientconfig-2 and restarting pod.

AlwaySummit commented 3 years ago

Thanks. I'll test it soon.

AlwaySummit commented 3 years ago

Hi @Lirt, I still got a nil pointer error and I cannot find the root cause this time. I have 'OS_CLIENT_CONFIG_FILE' and 'OS_CLOUD' properly set in deployment.yaml.

{{- else if eq $provider "openstack"}}
- name: OS_CLIENT_CONFIG_FILE
  value: /credentials/cloud
- name: OS_CLOUD
  value: cc

Here is what I put into the /credentials/cloud. I assume gophercloud can directly pick it up instead of looking for clouds.yaml.

clouds:
  cc:
    region_name: eu-de-1
    auth:
      auth_url: ***
      application_credential_id: ***
      application_credential_secret: ***

Here is what I got after deployment. Any insights?

time="2021-09-07T08:47:43Z" level=error msg="Error getting a backup store" backupstoragelocation=default controller=backupstoragelocation error="rpc error: code = Aborted desc = plugin panicked: runtime error: invalid memory address or nil pointer dereference" error.file="/go/pkg/mod/github.com/vmware-tanzu/velero@v1.4.2/pkg/plugin/framework/handle_panic.go:41" error.function=github.com/vmware-tanzu/velero/pkg/plugin/framework.handlePanic logSource="pkg/controller/backupstoragelocation_controller.go:87"
time="2021-09-07T08:47:43Z" level=info msg="No backup locations were ready to be verified" controller=backupstoragelocation logSource="pkg/controller/backupstoragelocation_controller.go:120"

AlwaySummit commented 3 years ago

I guess I found the key for this issue. In gophercloud, AuthOptions is defined as:

ao := &gophercloud.AuthOptions{
        Scope:                       scope,
        IdentityEndpoint:            cloud.AuthInfo.AuthURL,
        TokenID:                     cloud.AuthInfo.Token,
        Username:                    cloud.AuthInfo.Username,
        UserID:                      cloud.AuthInfo.UserID,
        Password:                    cloud.AuthInfo.Password,
        TenantID:                    cloud.AuthInfo.ProjectID,
        TenantName:                  cloud.AuthInfo.ProjectName,
        DomainID:                    cloud.AuthInfo.UserDomainID,
        DomainName:                  cloud.AuthInfo.UserDomainName,
        ApplicationCredentialID:     cloud.AuthInfo.ApplicationCredentialID,
        ApplicationCredentialName:   cloud.AuthInfo.ApplicationCredentialName,
        ApplicationCredentialSecret: cloud.AuthInfo.ApplicationCredentialSecret,
        AllowReauth:                 *cloud.AuthInfo.AllowReauth,
    }

*cloud.AuthInfo.AllowReauth has to be decleared in cloud.yaml so it's going to be like:

clouds:
  cc:
    auth:
      auth_url: ***
      application_credential_id: ***
      application_credential_secret: ***
      allow_reauth: true

Afterwards, everything goes well.

AlwaySummit commented 3 years ago

I suggest this situation should be clarified in README. I can pull a new request for this as well if allowed including using helm to deploy velero via a secret file.

Lirt commented 3 years ago

Hi @AlwaySummit. Can you try to repull image lirt/velero-plugin-for-openstack:auth-clientconfig-2? Maybe it's outdated.

Anyway the point is you shouldn't need to specify AllowReauth because I am setting default value there. I will try it with same config as you and fix if there is something wrong.

AlwaySummit commented 3 years ago

Hi @Lirt, have you tried it yet? It's still not working for me.

AlwaySummit commented 3 years ago

I assume the AllowReauth is retrieved from cloud which is loaded from clouds.yaml instead of opt.

Lirt commented 3 years ago

Yes, there was an issue in gophercloud.utils that I was updating to support AllowReauth. Fixed in https://github.com/Lirt/velero-plugin-for-openstack/pull/27/commits/cc6068f4b740b5ed40498dd00d042eb546eabe01.

I removed all dev images and pushed lirt/velero-plugin-for-openstack:auth-clientconfig-1. Works fine now.

AlwaySummit commented 3 years ago

It's working now. Thanks.

Lirt commented 3 years ago

Waiting for merge of https://github.com/gophercloud/utils/pull/162, then I will do last update to simplify the code and merge+release as v0.3.0.

Lirt / velero-plugin-for-openstack

Use clientconfig utils for authentication #27