Optional support for unsecure keystone API URL #22695
Comments
|
I don't think we should enable username/password checking over http. |
|
I agree that we are loosing a security layer here, but you can't guarantee you got the password from client over https, so it might be intercepted at this point anyways. More general, I think the proper way to authenticate to Kubernetes with the Keystone plugin using tokens since they will
So I don't want to check username/password directly. I'm just starting out with the Keystone plugin, so I want to point this out in general, if token auth is supported, the better. Couldn't try it in praxis for now since I can't get the auth URL running. |
|
Assigning to @etune to add a priority label. |
ghost
assigned 
erictune
added
the
priority/awaiting-more-evidence
|
Setting the priority low until we have a sense of how many users have this restriction (keystone only reachable over http). |
|
I ran into this same issue with trying to deploy kubernetes with devstack in the same vm and wanted to test integration and do some development. I think there are a significant number of developers in this same boat. http is secure enough since it doesn't leave the developers vm and it isn't intended for production. The use case is the same as: |
|
I'd vastly prefer allowing specifying the CA for the keystone server over allowing http auth calls carrying usernames and passwords |
|
I don't disagree. :) But, I also think Kubernetes shouldn't handle the usernames/passwords at all. In http mode, sending a token is much less risky then a username/password since they expire relatively quickly. See this issue for details: |
|
I agree tokens would be preferable, but I wouldn't expect credentials of any kind sent over http to remote servers |
|
Agreed. No one in their right mind should be passing creds or bearer tokens over http over a network. I'm just interested in being able to easily deploy a k8s in DevStack with a simple plugin, where that k8s is hooked into the deployed keystone so that we can start developing things in OpenStack that depend on k8s. This gives developers a smooth/easy experience to then focus on doing the development stuff and not have to mess with setting up a CA/k8s, which will prevent some of them from contributing to k8s/OpenStack. The idea is simple for developers, secure for operators. Totally separate use cases. |
It should be as simple as telling k8s to trust the keystone cert as a CA (assuming the self-signed cert generated by keystone is correctly marked as a CA, which it should be, since it is signing for itself).
I've seen too many production installations running with http or untrusted TLS settings to believe that only developers will use this option if it's made available. |
|
I didn't think Devstack could easily deploy with SSL enabled, but it looks like you can: So http support might not be as important as I thought. It could be relegated to a documentation issue for deploying Devstack in this mode when deploying with Kubernetes. We'd still need a way to specify the root CA though for Keystone. |
|
So, I played around with this a little. For my current non devstack based system, I've deployed kubernetes as a cluster running on my laptop deployed as a set of pods via /etc/kubernetes/manifests. Only kubelet is native and all the rest of the services are containers direct from google. Its working well, but since I have 3 api server containers, and get the containers direct from google, I'd have to jump through a bunch of hoops to add the keystone ssl ca cert to each of the containers. I still think an option to specify the ssl cert for keystone would be useful rather then having to merge it into the system's chain of trust. |
That's how I'd want to handle this as well |
Automatic merge from submit-queue specify custom ca file to verify the keystone server <!-- Thanks for sending a pull request! Here are some tips for you: 1. If this is your first time, read our contributor guidelines https://github.com/kubernetes/kubernetes/blob/master/CONTRIBUTING.md and developer guide https://github.com/kubernetes/kubernetes/blob/master/docs/devel/development.md 2. If you want *faster* PR reviews, read how: https://github.com/kubernetes/kubernetes/blob/master/docs/devel/faster_reviews.md 3. Follow the instructions for writing a release note: https://github.com/kubernetes/kubernetes/blob/master/docs/devel/pull-requests.md#release-notes --> **What this PR does / why we need it**: Sometimes the keystone server's certificate is self-signed, mainly used for internal development, testing and etc. For this kind of ca, we need a way to verify the keystone server. Otherwise, below error will occur. > x509: certificate signed by unknown authority This patch provide a way to pass in a ca file to verify the keystone server when starting `kube-apiserver`. **Which issue this PR fixes** : fixes #22695, #24984 **Special notes for your reviewer**: **Release note**: <!-- Steps to write your release note: 1. Use the release-note-* labels to set the release note state (if you have access) 2. Enter your extended release note in the below block; leaving it blank means using the PR title as the release note. If no release note is required, just write `NONE`. --> ``` release-note ```
Hi,
I tried to integrate the keystone auth plugin (which would be perfect for my needs) into the cluster I'm currently setting up. However, I can't get the connection working since our keystone installation is currently only reachable over http
As far as I can see in plugin/pkg/auth/authenticator/request/keystone/keystone.go, there is no option to deactivate this check. I think this should be an optional parameter on startup, similar to
--experimental-keystone-urldefaulting to the check being activated.The text was updated successfully, but these errors were encountered: