>> This honestly hasn’t even been *fully* tested yet, but it SHOULD work. It did not work. Please read on. >> User sets ACLs on Secrets and Container in Barbican, to allow the LBaaS user >> (right now using whatever user-id we publish in our docs) to read their data. I did perform the above step to give read access for the container and secrets to “admin”, but it did not work.
Root Cause ========== The certmanager in lbaas which connects to barbican uses the keystone session gathered from neutron_lbaas.common.keystone.get_session() Since the keystone session is marked for tenant “admin” lbaas is not able to get the tenant’s container/certificate. I have filed a bug for the same. https://bugs.launchpad.net/neutron/+bug/1497410 This is an important fix required since tenants wont be able to use SSL Offload. Will try to upload a fix for this next week. Thanks, Vijay V. From: Adam Harwell [mailto:adam.harw...@rackspace.com] Sent: 16 September 2015 00:32 To: OpenStack Development Mailing List (not for usage questions) <openstack-dev@lists.openstack.org> Subject: Re: [openstack-dev] [neutron][lbaas] Is SSL offload config possible using non "admin" tenant? There is not really good documentation for this yet… When I say Neutron-LBaaS tenant, I am maybe using the wrong word — I guess the user that is configured as the service-account in neutron.conf. The user will hit the ACL API themselves to set up the ACLs on their own secrets/containers, we won’t do it for them. So, workflow is like: * User creates Secrets in Barbican. * User creates CertificateContainer in Barbican. * User sets ACLs on Secrets and Container in Barbican, to allow the LBaaS user (right now using whatever user-id we publish in our docs) to read their data. * User creates a LoadBalancer in Neutron-LBaaS. * LBaaS hits Barbican using its standard configured service-account to retrieve the Container/Secrets from the user’s Barbican account. This honestly hasn’t even been *fully* tested yet, but it SHOULD work. The question is whether right now in devstack the admin user is allowed to read all user secrets just because it is the admin user (which I think might be the case), in which case we won’t actually know if ACLs are working as intended (but I think we assume that Barbican has tested that feature and we can just rely on it working). --Adam https://keybase.io/rm_you From: Vijay Venkatachalam <vijay.venkatacha...@citrix.com<mailto:vijay.venkatacha...@citrix.com>> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>> Date: Monday, September 14, 2015 at 9:12 PM To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>> Subject: Re: [openstack-dev] [neutron][lbaas] Is SSL offload config possible using non "admin" tenant? Is there a documentation which records step by step? What is Neutron-LBaaS tenant? Is it the tenant who is configuring the listener? *OR* is it some tenant which is created for lbaas plugin that is the having all secrets for all tenants configuring lbaas. >>You need to set up ACLs on the Barbican side for that container, to make it >>readable to the Neutron-LBaaS tenant. I checked the ACL docs http://docs.openstack.org/developer/barbican/api/quickstart/acls.html The ACL API is to allow “users”(not “Tenants”) access to secrets/containers. What is the API or CLI that the admin will use to allow access of the tenant’s secret+container to Neutron-LBaaS tenant. From: Adam Harwell [mailto:adam.harw...@rackspace.com] Sent: 15 September 2015 03:00 To: OpenStack Development Mailing List (not for usage questions) <openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>> Subject: Re: [openstack-dev] [neutron][lbaas] Is SSL offload config possible using non "admin" tenant? You need to set up ACLs on the Barbican side for that container, to make it readable to the Neutron-LBaaS tenant. For now, the tenant-id should just be documented, but we are looking into making an API call that would expose the admin tenant-id to the user so they can make an API call to discover it. Once the user has the neutron-lbaas tenant ID, they use the Barbican ACL system to add that ID as a readable user of the container and all of the secrets. Then Neutron-LBaaS hits barbican with the credentials of the admin tenant, and is granted access to the user’s container. --Adam https://keybase.io/rm_you From: Vijay Venkatachalam <vijay.venkatacha...@citrix.com<mailto:vijay.venkatacha...@citrix.com>> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>> Date: Friday, September 11, 2015 at 2:35 PM To: "OpenStack Development Mailing List (openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>)" <openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>> Subject: [openstack-dev] [neutron][lbaas] Is SSL offload config possible using non "admin" tenant? Hi, Has anyone tried configuring SSL Offload as a tenant? During listener creation there is an error thrown saying ‘could not locate/find container’. The lbaas plugin is not able to fetch the tenant’s certificate. From the code it looks like the lbaas plugin is tyring to connect to barbican with keystone details provided in neutron.conf Which is by default username = “admin” and tenant_name =”admin”. This means lbaas plugin is looking for tenant’s ceritifcate in “admin” tenant, which it will never be able to find. What is the procedure for the lbaas plugin to get hold of the tenant’s certificate? Assuming “admin” user has access to all tenant’s certificates. Should the lbaas plugin connect to barbican with username=’admin’ and tenant_name = listener’s tenant_name? Is this, the way forward ? *OR* Am I missing something? Thanks, Vijay V.
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
