It would be very nice to actually use scoped tokens though. Then you could use the project's roles to map up to tenants in openshift and not have to manage memberships in multiple systems.
Thanks, Kevin ________________________________ From: Jordan Liggitt [[email protected]] Sent: Thursday, April 14, 2016 10:37 AM To: Fox, Kevin M Cc: Scott Seago; Chmouel Boudjnah; OpenShift List Dev Subject: Re: keystonepasswd auth We don't use the token to make any other API calls, just to verify the user's auth credentials. On Thu, Apr 14, 2016 at 1:36 PM, Fox, Kevin M <[email protected]<mailto:[email protected]>> wrote: Ah. There are scoped and unscoped tokens in keystone. Unscoped ones are project-less but can do almost nothing. Project scoped ones usually used. Most resources in openstack is bound to the project and not the user, so hence the need for scoped tokens. Thanks, Kevin ________________________________ From: Jordan Liggitt [[email protected]<mailto:[email protected]>] Sent: Thursday, April 14, 2016 9:53 AM To: Fox, Kevin M; Scott Seago Cc: Chmouel Boudjnah; OpenShift List Dev Subject: Re: keystonepasswd auth I'm not seeing where tenant name is defaulted to the user name. The keystone auth request is a password authentication with the user name and domain name, which uniquely identifies the user (users belong to domains, not tenants/projects) On Thu, Apr 14, 2016 at 12:20 PM, Fox, Kevin M <[email protected]<mailto:[email protected]>> wrote: keystone v3 renamed tenant to project. Otherwise, should be the same. Thanks, Kevin ________________________________ From: [email protected]<mailto:[email protected]> [[email protected]<mailto:[email protected]>] on behalf of Jordan Liggitt [[email protected]<mailto:[email protected]>] Sent: Thursday, April 14, 2016 9:16 AM To: Chmouel Boudjnah Cc: OpenShift List Dev Subject: Re: keystonepasswd auth The OpenShift Keystone IDP integration only supports the v3 Keystone API. I don't see any discussion of tenants in the doc for that API (http://developer.openstack.org/api-ref-identity-v3.html) On Thu, Apr 14, 2016 at 12:06 PM, Chmouel Boudjnah <[email protected]<mailto:[email protected]>> wrote: Hello, I was looking at trying the keystone password authentication. While there is some missing directive in the documentation : https://github.com/openshift/openshift-docs/pull/1902 things are working and i could properly auth my openshift user with my keystone username/password. The only caveat is that in OpenStack we usually need to specify a tenant_name/id for the user to auth with, by default if I understand correctly gophercloud would try to match the provider from the argument provided : https://github.com/rackspace/gophercloud/blob/e83aa011e019917c7bd951444d61c42431b4d21d/auth_options.go#L10-L11 which in this case if no tenant_name are specified would do a tenant_name==user_name like done by default on Rackspace Cloud (gophercloud is written by rackspace) So now the question is how can we improve this and be able to specify a tenant_name in there? Since most of deployed OpenStack clouds would have multiple users scoped to different tenants We could do some hackery things like having a delimiter like colon : to be able to split those as tenant_name and user_name which is something we did on swiftclient sometime ago but that's not very openstackish and was more of hack that need to be supported forever (i implemented that :(( ) We could add a switch like --keystone-tenant-name or something but i guess that would pollute the login if we want to add more stuff. Maybe using the openstack environment which is a standard way in OpenStack for the clients to use would be an option : https://github.com/rackspace/gophercloud/blob/e83aa011e019917c7bd951444d61c42431b4d21d/openstack/auth_env.go#L24 which would be transparent for the user since they would have only to download their openrc from openstack dashboard (horizon) and just issue a oc login to connect (which could be only a fallback to the current method) What do you think? Cheers, Chmouel _______________________________________________ dev mailing list [email protected]<mailto:[email protected]> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
_______________________________________________ dev mailing list [email protected] http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
