OpenStack Keystone Authorization#25624
Conversation
|
Can one of the admins verify that this patch is reasonable to test? If so, please reply "ok to test". This message may repeat a few times in short succession due to jenkinsci/ghprb-plugin#292. Sorry. Otherwise, if this message is too spammy, please complain to ixdy. |
2 similar comments
|
Can one of the admins verify that this patch is reasonable to test? If so, please reply "ok to test". This message may repeat a few times in short succession due to jenkinsci/ghprb-plugin#292. Sorry. Otherwise, if this message is too spammy, please complain to ixdy. |
|
Can one of the admins verify that this patch is reasonable to test? If so, please reply "ok to test". This message may repeat a few times in short succession due to jenkinsci/ghprb-plugin#292. Sorry. Otherwise, if this message is too spammy, please complain to ixdy. |
|
Hello @kfox1111- Perhaps we don't need keystone authentication at all since keystone now supports OpenID Connect and we are planning on getting OIDC integration into v1.3: #25270 For the authorization side of things you may want to see the work that Eric is doing to upstream the Authorization types and API originally in OpenShift: #24900 |
|
@philips Thanks for the links. oauth in OpenStack is not well used and is being considered for deprecation: The authentication code is done in the same way its done in all other OpenStack services so it works well in an OpenStack environment. I'll read through the authorization thread that you posted. its pretty long though, so might take me a while to get through. Thanks. |
|
Can someone help me with formatting release notes? I totally don't understand how they work apparently. :/ |
|
@kfox1111 That is OAUTH 1.0 they are deprecating. My understanding is that Keystone also does OAUTH 2.0/OpenID Connect. |
|
If they support it, I have'nt found a way to use it. Do you have any documentation on it? This authz and related authn patch makes Kubernetes authenticate just like any other Service of OpenStack. This uses code should be commonly available to all OpenStack clouds and commonly tested so is unlikely to have issues from code that isn't used much. I'm worried that it will be quite difficult to use the oauth stuff for both the user and the operator since it is not what they are use to dealing with. |
|
I was able to find this: But its about using an external idp to authenticate into Keystone, not supporting services where keystone is the idp. I think its going the wrong direction for this use case. |
There was a problem hiding this comment.
Not sure what this extra check is buying us. I would just check the namespaced keystone projectID/roles data directly.
There was a problem hiding this comment.
Hmm... Your right. It was an attempt to let service users through but not users authenticated via the keystone plugin. But the authz stuff doesn't work that way... I'll remove it.
There was a problem hiding this comment.
Actually, I was looking and it does one thing. It logs if the authentication user isn't a keystone token to help you debug why authorization might not be working as you might expect. So I think its useful to leave it in?
There was a problem hiding this comment.
I'd rather make the authorizer check the actual info it cares about, and document that it should typically be used In conjunction with the keystone token authenticator
There was a problem hiding this comment.
Ok. I'll fix this in the next version.
|
We are 4 days from a code freeze for the next release. I won't be able to review this before then. Will definitely consider for next release (1.4). |
|
@erictune bummer. but I understand. thanks for considering it early in 1.4. Its something the OpenStack folks really need. |
|
@erictune actually, an idea... This code is already marked as experimental. Just like the existing keystone password code. Since it is marked as such, can it still make it in? It would allow developers in the OpenStack community to continue to make progress with integrating with k8s in this experimental mode. This might flesh out issues, like those that were discovered with the keystone password module sooner, and possibly make for a better experience when the feature is made unexperimental, hopefully in 1.4? Its mostly just additive so shouldn't break anything outside of keystone token support? |
There was a problem hiding this comment.
s/experimental/experimantal/
There was a problem hiding this comment.
woops. good catch. Fixed in next version.
|
I'll take this for 1.3 under these condition:
|
|
Is there a write-up here of what the short, medium term goals actually are for this work. It seems like those goals are being discovered as we go along and I'm thinking we could do better if the k8s community knows more about keystone and how it can be used; just getting a general gist for the thread it appears that information may actually be valuable (and IMHO keystone could actually provide a path to a solution that avoids k8s creating its own equivalent, which would be dumb/waste-of-time/resources). |
|
@harlowja Yeah. A lot of the discussion has happened in pr's/issues all over the place. I tried to distil a lot of it into one post here: Does k8s have a formalized spec kind of thing where we should place this and other relevant bits to the discussion so it can be more easily found? |
|
Can one of the admins verify that this patch is reasonable to test? If so, please reply "ok to test". This message may repeat a few times in short succession due to jenkinsci/ghprb-plugin#292. Sorry. Otherwise, if this message is too spammy, please complain to ixdy. |
|
How do I complain to to ixdy; cause damn... should be a feature to shutup bots. |
|
Please file an issue in the kubernetes/contrib repo if you have a suggestion for different behavior of the bot. I'd suggest @ mentioning at least one person to make sure somebody sees it. |
|
Will do, it'd be real nice if there was a way to put 'bot generated' messages in a different tab or something, cause PR comments are already a mess as is so more mess == bad IMHO. |
|
Can one of the admins verify that this patch is reasonable to test? If so, please reply "ok to test". This message may repeat a few times in short succession due to jenkinsci/ghprb-plugin#292. Sorry. Otherwise, if this message is too spammy, please complain to ixdy. |
| if err != nil { | ||
| return nil, err | ||
| if len(config.KeystoneConfig) > 0 { | ||
| if config.KeystoneAuthMode == "token" { |
There was a problem hiding this comment.
Is it not possible to use both password and token mode at the same time in a single apiserver?
There was a problem hiding this comment.
We tried it once and it failed. It would be nice if it could though.
|
@kfox1111 |
|
@erictune: yeah, I was meaning hooking the Keystone Project/Role stuff enough into the Kubernetes RBAC system such that users could write RBAC rules that lets particular Keystone Roles on Keystone Projects do certain actions. For example: I may want to write a Kubernetes RBAC rule that lets a user with a "Monitoring" Keystone Role on Keystone Project "foo" access to list all pods on Namespace "foo", but do nothing else. |
|
Does keystone assign any meaning to roles, outside of the user/groups/projects they are bound to? Or is it up to each service that uses role-based auth to define its own interpretation of those roles? |
|
Its up to each service to determine what can and can not be accessed based on the keystone roles on projects. Each OpenStack service usually uses a policy.json file to map keystone roles to their own api. For example, here's nova's (http://docs.openstack.org/juno/config-reference/content/section_nova-policy.json.html) I think Kubernetes RBAC system is much more flexible then the policy.json system, but is the same kind of thing. So it would be great to be able to reuse it. |
|
This is still being worked on. I hope to get back to it this weekend if time permits. |
|
Can one of the admins verify that this patch is reasonable to test? If so, please reply "ok to test". This message may repeat a few times in short succession due to jenkinsci/ghprb-plugin#292. Sorry. Otherwise, if this message is too spammy, please complain to ixdy. |
1 similar comment
|
Can one of the admins verify that this patch is reasonable to test? If so, please reply "ok to test". This message may repeat a few times in short succession due to jenkinsci/ghprb-plugin#292. Sorry. Otherwise, if this message is too spammy, please complain to ixdy. |
|
Can one of the admins verify that this patch is reasonable to test? If so, please reply "ok to test". This message will repeat several times in short succession due to jenkinsci/ghprb-plugin#292. Sorry. |
|
So, honestly I've kind of lost track of where we are with this. The webhook thing seems to have never materialized. Is this patch set the way we want to go? If so, I can work on finishing up the remaining concerns with it. |
|
I'm in favor of exploring with the k8s folks (sig-auth?) before we figure this one out, seem ok? |
|
Agreed, we can talk during the sig meeting or schedule a dedicated meeting if we run out of time |
|
Looks like this is on the agenda for tomorrow. Agenda is here: On Fri, Sep 2, 2016 at 8:26 PM, Jordan Liggitt notifications@github.com
|
| @@ -82,6 +82,10 @@ kube-apiserver | |||
| --etcd-servers=[]: List of etcd servers to connect with (http://ip:port), comma separated. | |||
| --etcd-servers-overrides=[]: Per-resource etcd servers overrides, comma separated. The individual override format: group/resource#servers, where servers are http://ip:port, semicolon separated. | |||
| --event-ttl=1h0m0s: Amount of time to retain events. Default 1 hour. | |||
There was a problem hiding this comment.
I think, --experimental-authorization-keystone-role and --experimental-authorization-keystone-single-projectid, these two args can also be included in the Keystone config file. As these args are all passed to kube-apiserver when bootstrapping kubernetes env, all the configurations are fixed unless restarting kube-apiserver.
|
This PR hasn't been active in 90 days. Closing this PR. Please reopen if you would like to work towards merging this change, if/when the PR is ready for the next round of review. You can add 'keep-open' label to prevent this from happening again, or add a comment to keep it open another 90 days |
|
@kfox1111 I would be interested in the Multitenant version, mapping project to namespaces. Have you worked on it? |
|
I have not. @dims is more active on the subject these days. |
|
@attardi @kfox1111 - The last word is we should use a web hook, there's code in https://github.com/dims/k8s-keystone-auth we can collaborate there or move it to another common github org or gerrit in openstack |
OpenStack Keystone is mostly a system to provide a central place to manage Authorization for a Mutitenant Cloud. You typically use one Keystone to manage all of you Projects at your organization, of which usually all need to be isolated from each other. Very few clouds don't have a need for isolation.
This is an initial implementation that supports restricting Keystone access to k8s to a single OpenStack Project. This aligns with the OpenStack Magnum use case. Each project launches their own k8s cluster using Magnum, and then wants to login to it using their existing credentials, but block access to other projects. This PR enables that use case.
In future PR's, I hope to implement full Multitenancy so that additionally, one k8s cluster could be used for the entire OpenStack Cloud, and Projects are isolated from each other though some mechanism (perhaps mapping keystone project = namespaces?)
This change is