[openstack-dev] [magnum] Add support for using Keystone in k8s bay
Fox, Kevin M
Kevin.Fox at pnnl.gov
Wed May 4 17:01:53 UTC 2016
+1. Thanks for starting the discussion.
We may need a spec for it. The support in k8s currently is marked experimental (thankfully) and is insufficient. It currently only supports username/password authentication via keystone v2. There's an issue in the works to fix it in k8s:
tl:dr; To fix it, we will need keystone token authentication, which will require v3 token authentication. v3 token auth today requires a service account with an admin credential, so the magnum support will need to provision one of those accounts and copy the appropriate config/credentials to the controllers as well as set the config options.
I've talked to the keystone team and they believe that the v3 validate token api can be done without an admin credential if a new role was introduced and the policy for that api call was changed to specify the new role. This would make things more secure, but wouldn't change what magnum would need to do, just which role it would attach to the user it provisions. So I think these two activities can be done in parallel.
From: Hongbin Lu [hongbin.lu at huawei.com]
Sent: Wednesday, May 04, 2016 8:33 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [magnum] Add support for using Keystone in k8s bay
Based on requests, I propose to add support for Keystone authentication for k8s bay. A blueprint was created for that:
A goal is to enable other OpenStack services to access the APIs of k8s bays. So far, I received a use case from a under-developing Horizon k8s plugin. I believe there will be more similar use cases from other services. For the implementation, I think it is straightforward. Keystone authentication is already supported in k8s upstream . Magnum could simply add an option for users to turn it on. As an initial step, I suggest to support passing the auth option via labels (e.g. ‘–labels k8s-auth=keystone’). If Keystone is supported by other COEs in the future, we could promote this option as a baymodel attribute. Thoughts?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev