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

Update OpenStack keystone integration #7304

Closed
wants to merge 1 commit into from
Closed

Conversation

dims
Copy link
Member

@dims dims commented Feb 8, 2018

  • removing the keystone password section
  • adding a subsection under "Webhook Token Authentication" that details configuration of kubectl with the openstack auth provider

NOTE: After opening the PR, please un-check and re-check the "Allow edits from maintainers" box so that maintainers can work on your patch and speed up the review process. This is a temporary workaround to address a known issue with GitHub.>

Please delete this note before submitting the pull request.

Allow edits from maintainers checkbox


This change is Reviewable

@k8s-ci-robot k8s-ci-robot added do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. size/S Denotes a PR that changes 10-29 lines, ignoring generated files. labels Feb 8, 2018
@k8sio-netlify-preview-bot
Copy link
Collaborator

k8sio-netlify-preview-bot commented Feb 8, 2018

@dims
Copy link
Member Author

dims commented Feb 8, 2018

note from @liggitt

the kubectl side should be documented now.

your webhook authenticator is one possible option for turning keystone tokens into userinfo, and could be referenced as an example, without being positioned as the one true keystone webhook token authenticator (even once it is in the openstack foundation, alternative user mappings could be achieved through alternate webhooks)

@heckj
Copy link
Contributor

heckj commented Feb 28, 2018

/assign

@ericchiang
Copy link
Contributor

@dims do you need any help here?

@dims
Copy link
Member Author

dims commented Mar 6, 2018

@ericchiang will check with @heckj and report back (or pick up the work)

@heckj
Copy link
Contributor

heckj commented Mar 7, 2018

Sorry @dims - what did I miss? How can I help? I went ahead and assigned this to me to review, but it seemed still WIP so I didn't put much attention behind it.

@dims
Copy link
Member Author

dims commented Mar 7, 2018

@heckj whoops. i remember someone volunteering for taking this over. sorry. will work on this today

@dims
Copy link
Member Author

dims commented Mar 14, 2018

@dixudx i could use your help with this :) (mentioned it in kubernetes/kubernetes#60200)

- removing the keystone password section
- adding a subsection under "Webhook Token Authentication" that details
  configuration of kubectl with the openstack auth provider
@k8s-ci-robot
Copy link
Contributor

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
To fully approve this pull request, please assign additional approvers.
We suggest the following additional approver: heckj

Assign the PR to them by writing /assign @heckj in a comment when ready.

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:

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

@k8s-ci-robot k8s-ci-robot added size/M Denotes a PR that changes 30-99 lines, ignoring generated files. and removed size/S Denotes a PR that changes 10-29 lines, ignoring generated files. labels Mar 16, 2018
@dims dims changed the title [WIP] Update OpenStack keystone integration Update OpenStack keystone integration Mar 16, 2018
@k8s-ci-robot k8s-ci-robot removed the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Mar 16, 2018
@@ -486,6 +486,21 @@ An unsuccessful request would return:

HTTP status codes can be used to supply additional error context.

#### Using OpenStack Keystone authentication Webhook

There are two parts to authentication with OpenStack Keystone. On the client-side, you can use `--auth-provider=openstack` option to reuse the `OS_*` environment variables:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

s/authentication/authenticate

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suspect there's a word missing that would make this better than changing authentication to authenticate, which also reads oddly, perhaps better phrasing:

There are two parts to support authentication with OpenStack Keystone.

```
Note that you will also need to use `kubectl config set-context` and `kubectl config use-context` to activate the context. Please make sure you have `OS_DOMAIN_NAME` to use Keystone V3 API.

On the server-side, one choice is to use the webhook from:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IIRC, from v1.10, this will be the only choice, right?

So we won't have other choices for now. This should be addressed well here. WDYT?

Documentation for the webhook is at
https://github.com/dims/openstack-cloud-controller-manager/blob/master/docs/using-keystone-webhook-authenticator-and-authorizer.md

This webhook from folks in the OpenStack community is just one option. Other webhooks may be available with alternative user mappings in the future.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Still not available for now. Shall we remove this line?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Recommend dropping the line about "other webhooks may be available..." - better to focus on what is now and how to utilize it vs. what could come.

```
kubectl config set-credentials openstackuser --auth-provider=openstack
```
Note that you will also need to use `kubectl config set-context` and `kubectl config use-context` to activate the context. Please make sure you have `OS_DOMAIN_NAME` to use Keystone V3 API.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Adds an auth config file example to illustrate #60200?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good information, but its unclear on how someone would actually use these commands and in what order to authenticate to the cluster. I'd recommend showing all three commands in sequence, explaining what they do to provide the authentication, and prefixing the whole thing by asserting that the administrator specifically needs to have OS_DOMAIN_NAME set. There's an implication of other OS_* environment variables that may need to be set - I'm not sure what those may be, but if any are critical, please include them in a "to use this, you need..." sort of requirements note above the sequence of commands.

@@ -486,6 +486,21 @@ An unsuccessful request would return:

HTTP status codes can be used to supply additional error context.

#### Using OpenStack Keystone authentication Webhook

There are two parts to authentication with OpenStack Keystone. On the client-side, you can use `--auth-provider=openstack` option to reuse the `OS_*` environment variables:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suspect there's a word missing that would make this better than changing authentication to authenticate, which also reads oddly, perhaps better phrasing:

There are two parts to support authentication with OpenStack Keystone.

```
kubectl config set-credentials openstackuser --auth-provider=openstack
```
Note that you will also need to use `kubectl config set-context` and `kubectl config use-context` to activate the context. Please make sure you have `OS_DOMAIN_NAME` to use Keystone V3 API.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good information, but its unclear on how someone would actually use these commands and in what order to authenticate to the cluster. I'd recommend showing all three commands in sequence, explaining what they do to provide the authentication, and prefixing the whole thing by asserting that the administrator specifically needs to have OS_DOMAIN_NAME set. There's an implication of other OS_* environment variables that may need to be set - I'm not sure what those may be, but if any are critical, please include them in a "to use this, you need..." sort of requirements note above the sequence of commands.

kubectl config set-credentials openstackuser --auth-provider=openstack
```
Note that you will also need to use `kubectl config set-context` and `kubectl config use-context` to activate the context. Please make sure you have `OS_DOMAIN_NAME` to use Keystone V3 API.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wasn't entirely clear - are both of these (server side and client side) needed to authenticate, or is it one or the other if you want to use Keystone to Auth?

Note that you will also need to use `kubectl config set-context` and `kubectl config use-context` to activate the context. Please make sure you have `OS_DOMAIN_NAME` to use Keystone V3 API.

On the server-side, one choice is to use the webhook from:
https://github.com/dims/openstack-cloud-controller-manager/blob/master/cmd/k8s-keystone-auth/main.go
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't know that referencing the Go code will help an administrator know how to use this, but if you want to reference it, I recommend something like:

The OpenStack Cloud Controller includes an webhook authenticator.

On the server-side, one choice is to use the webhook from:
https://github.com/dims/openstack-cloud-controller-manager/blob/master/cmd/k8s-keystone-auth/main.go

Documentation for the webhook is at
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggestion:

Documentation for how to install and configure the OpenStack authentication webhook can be found at https://github.com/dims/openstack-cloud-controller-manager/blob/master/docs/using-keystone-webhook-authenticator-and-authorizer.md.

to make that an active link

Documentation for the webhook is at
https://github.com/dims/openstack-cloud-controller-manager/blob/master/docs/using-keystone-webhook-authenticator-and-authorizer.md

This webhook from folks in the OpenStack community is just one option. Other webhooks may be available with alternative user mappings in the future.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Recommend dropping the line about "other webhooks may be available..." - better to focus on what is now and how to utilize it vs. what could come.

@dims
Copy link
Member Author

dims commented Apr 24, 2018

will revisit this in a bit. we are adding a bunch more in the new git repo (cloud-provider-openstack)

@dims dims closed this Apr 24, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. size/M Denotes a PR that changes 30-99 lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants