Add support for openstack application credentials

[piequi]

What type of PR is this?
/kind feature

What this PR does / why we need it:
Add support for OpenStack application credentials to authenticate against Keystone API (instead of using username and password)

Which issue(s) this PR fixes:

Fixes #6533

Special notes for your reviewer:

Does this PR introduce a user-facing change?:

NONE

[k8s-ci-robot]

Thanks for your pull request. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

📝 Please follow instructions at https://git.k8s.io/community/CLA.md#the-contributor-license-agreement to sign the CLA.

It may take a couple minutes for the CLA signature to be fully registered; after that, please reply here with a new comment and we'll verify. Thanks.

---

• If you've already signed a CLA, it's possible we don't have your GitHub username or you're using a different email address. Check your existing CLA data and verify that your email is set on your git commits.
• If you signed the CLA as a corporation, please sign in with your organization's credentials at https://identity.linuxfoundation.org/projects/cncf to be authorized.
• If you have done the above and are still having issues with the CLA being reported as unsigned, please log a ticket with the Linux Foundation Helpdesk: https://support.linuxfoundation.org/
• Should you encounter any issues with the Linux Foundation Helpdesk, send a message to the backup e-mail support address at: login-issues@jira.linuxfoundation.org

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

[k8s-ci-robot]

Welcome @piequi!

It looks like this is your first PR to kubernetes-sigs/kubespray 🎉. Please refer to our pull request process documentation to help your PR have a smooth ride to approval.

You will be prompted by a bot to use commands during the review process. Do not be afraid to follow the prompts! It is okay to experiment. Here is the bot commands documentation.

You can also check if kubernetes-sigs/kubespray has its own contribution guidelines.

You may want to refer to our testing guide if you run into trouble with your tests not passing.

If you are having difficulty getting your pull request seen, please follow the recommended escalation practices. Also, for tips and tricks in the contribution process you may want to read the Kubernetes contributor cheat sheet. We want to make sure your contribution gets all the attention it needs!

Thank you, and welcome to Kubernetes. 😃

[k8s-ci-robot]

Hi @piequi. Thanks for your PR.

I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[piequi]

oops ! CLA is now signed

[floryut]

/ok-to-test

[piequi]

I signed it

[oomichi]

/check-cla

[piequi]

/check-cla

[phpHavok]

I tried out this branch, and I think it'd be better to read the default values from the environment, just like the other variables. In other words, add to roles/kubernetes-apps/external_cloud_controller/openstack/defaults/main.yml:

external_openstack_application_credential_name: "{{ lookup('env','OS_APPLICATION_CREDENTIAL_NAME') }}"
external_openstack_application_credential_id: "{{ lookup('env','OS_APPLICATION_CREDENTIAL_ID') }}"
external_openstack_application_credential_secret: "{{ lookup('env','OS_APPLICATION_CREDENTIAL_SECRET') }}"

Diff: application-credentials.diff.txt
Edit: OpenStack Horizon lets you download a specialized OpenRC file when you create an application credential that already has these variables set (with the exception of the credential name, which seems optional), so this would be the most straightforward for users I think (rather than manually editing the group_vars).

[phpHavok]

Another issue I found when trying to build. The tenant-id and domain-id are not required when using application credentials. So the credential checker should have a case to check for that.

See: https://github.com/kubernetes/cloud-provider-openstack/blob/master/docs/using-openstack-cloud-controller-manager.md

[piequi]

... I think it'd be better to read the default values from the environment, ...
...
Edit: OpenStack Horizon lets you download a specialized OpenRC file when you create an application credential that already has these variables set, so this would be the most straightforward for users I think (rather than manually editing the group_vars).

I'm not totally sure that application credentials are commonly set in user environment variables (compared to username and password). Specifying application credentials in the Ansible environment (in openstack.yml) that will be used along with all other settings by the playbook, is more explicit.

Another issue I found when trying to build. The tenant-id and domain-id are not required when using application credentials. So the credential checker should have a case to check for that.

See: https://github.com/kubernetes/cloud-provider-openstack/blob/master/docs/using-openstack-cloud-controller-manager.md

You are right. I'll update the check regarding tenant-id and domain-id.

Thanks

[Miouge1]

I haven't used app credentials yet, @alijahnas and @bl0m1 any feedback on this?

[Miouge1]

/approve

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: Miouge1, piequi

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [Miouge1]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[rptaylor]

I was a bit confused at first by the checks in openstack-credential-check.yml ; the logic is a bit hard to understand because of the way the fail task is used. The 'when' conditions combine the variables that need to be checked, and the circumstances in which they need to be checked, all in the same list.

What about using assert instead, with when conditions? That way there is a clear separation between what is being checked, and the condition when that check needs to be done. It would be more readable and understandable and should be easier to write too, like e.g. 'assert that password or secret is defined when ID is defined'

[piequi]

@rptaylor replacing fail tasks by assert has nothing to do with application credentials.

If you think this is relevant, feel free to contribute.

[rptaylor]

@piequi It has to do with the way the new application credential functionality is implemented; I am just suggesting it would be a cleaner way.

[huxcrux]

LGTM.

I cannot se any reasons not to accept this. looks to be compatible with occm 👍

[Miouge1]

/lgtm