Re: [openstack-dev] [Barbican] Providing service user read access to all tenant's certificates

2015-09-18 Thread Vijay Venkatachalam
Typos corrected.

From: Vijay Venkatachalam
Sent: 18 September 2015 00:36
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>
Subject: RE: [openstack-dev] [Barbican] Providing service user read access to 
all tenant's certificates

Yes Dave, that is what is happening today.

But that approach looks a little untidy, because tenant admin has to do some 
infrastructure work.

It will be good from the user/tenant admin's perspective to just do 2 things

1.  Upload certificates info

2.  Create LBaaS Configuration with certificates already uploaded

Now because barbican and LBaaS does *not* work nicely with each other, every 
tenant admin has to do the following


1.  Upload certificates info

2.  Read a document or finds out there is a LBaaS service user and somehow 
gets hold of LBaaS service user's userid. Assigns read rights to that 
certificate to LBaaS service user.

3.  Creates LBaaS Configuration with certificates already uploaded

This does not fit the "As a service" model of OpenStack where tenant's just 
configure whatever they want and the infrastructure takes care of automating 
the rest.

Thanks,
Vijay V.

From: Dave McCowan (dmccowan) [mailto:dmcco...@cisco.com]
Sent: 17 September 2015 18:20
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [Barbican] Providing service user read access to 
all tenant's certificates


The tenant admin from Step 1, should also do Step 2.

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: Wednesday, September 16, 2015 at 9:57 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] [Barbican] Providing service user read access to 
all tenant's certificates


How does lbaas do step 2?
It does not have the privilege for that secret/container using the service user.
Should it use the keystone token through which user created LB config and 
assign read access for the secret/container to the LBaaS service user?

Thanks,
Vijay V.

From: Fox, Kevin M [mailto:kevin@pnnl.gov]
Sent: 16 September 2015 19:24
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [Barbican] Providing service user read access to 
all tenant's certificates

Why not have lbaas do step 2? Even better would be to help with the instance 
user spec and combined with lbaas doing step 2, you could restrict secret 
access to just the amphora that need the secret?

Thanks,
Kevin


From: Vijay Venkatachalam
Sent: Tuesday, September 15, 2015 7:06:39 PM
To: OpenStack Development Mailing List 
(openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>)
Subject: [openstack-dev] [Barbican] Providing service user read access to all 
tenant's certificates
Hi,
   Is there a way to provide read access to a certain user to all 
secrets/containers of all project/tenant's certificates?
   This user with universal "read" privilege's will be used as a 
service user by LBaaS plugin to read tenant's certificates during LB 
configuration implementation.

   Today's LBaaS users are following the below mentioned process

1.  tenant's creator/admin user uploads a certificate info as secrets and 
container

2.  User then have to create ACLs for the LBaaS service user to access the 
containers and secrets

3.  User creates LB config with the container reference

4.  LBaaS plugin using the service user will then access container 
reference provided in LB config and proceeds to implement.

Ideally we would want to avoid step 2 in the process. Instead add a step 5 
where the lbaas plugin's service user checks if the user configuring the LB has 
read access to the container reference provided.

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


Re: [openstack-dev] [Barbican] Providing service user read access to all tenant's certificates

2015-09-18 Thread Vijay Venkatachalam

I would think OpenStack as Self Service portal.
Anyway, tenant’s admin need not play cloud admin’s role.
Only the cloud admin who sets up and manages openstack infrastructure (like 
controller Nodes etc) could know about the LBaaS service user. As much as 
possible the tenant admin should not be mandated to learn about the LBaaS 
service user.

From: Nathan Reller [mailto:nathan.s.rel...@gmail.com]
Sent: 18 September 2015 18:32
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [Barbican] Providing service user read access to 
all tenant's certificates

> But that approach looks a little untidy, because tenant admin has to do some 
> infrastructure work.

I would think infrastructure work would be part of the admin role. They are 
doing other things such as creating LBaaS, which seems like an infrastructure 
job to me. I would think configuring LBaaS and key management are similar. It 
seems like you think they are not similar. Can you explain more?

-Nate
__
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


Re: [openstack-dev] [Barbican] Providing service user read access to all tenant's certificates

2015-09-18 Thread Kant, Arun
>From description of use case, looks like you want 'service user' to access any 
>tenant resource regardless of that user has a tenant role or not and  without 
>explicit read assignment on that resource.  This can be done via a customized 
>policy where related 'get' calls are allowed access for a specific role and 
>assign that role to 'service user'. This role check can be made restrictive by 
>looking for specific 'service' tenant or 'service' domain.

-Arun


From: Vijay Venkatachalam [mailto:vijay.venkatacha...@citrix.com]
Sent: Friday, September 18, 2015 1:16 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Barbican] Providing service user read access to 
all tenant's certificates

Typos corrected.

From: Vijay Venkatachalam
Sent: 18 September 2015 00:36
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Subject: RE: [openstack-dev] [Barbican] Providing service user read access to 
all tenant's certificates

Yes Dave, that is what is happening today.

But that approach looks a little untidy, because tenant admin has to do some 
infrastructure work.

It will be good from the user/tenant admin's perspective to just do 2 things

1.   Upload certificates info

2.   Create LBaaS Configuration with certificates already uploaded

Now because barbican and LBaaS does *not* work nicely with each other, every 
tenant admin has to do the following


1.   Upload certificates info

2.   Read a document or finds out there is a LBaaS service user and somehow 
gets hold of LBaaS service user's userid. Assigns read rights to that 
certificate to LBaaS service user.

3.   Creates LBaaS Configuration with certificates already uploaded

This does not fit the "As a service" model of OpenStack where tenant's just 
configure whatever they want and the infrastructure takes care of automating 
the rest.

Thanks,
Vijay V.

From: Dave McCowan (dmccowan) [mailto:dmcco...@cisco.com]
Sent: 17 September 2015 18:20
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [Barbican] Providing service user read access to 
all tenant's certificates


The tenant admin from Step 1, should also do Step 2.

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: Wednesday, September 16, 2015 at 9:57 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] [Barbican] Providing service user read access to 
all tenant's certificates


How does lbaas do step 2?
It does not have the privilege for that secret/container using the service user.
Should it use the keystone token through which user created LB config and 
assign read access for the secret/container to the LBaaS service user?

Thanks,
Vijay V.

From: Fox, Kevin M [mailto:kevin@pnnl.gov]
Sent: 16 September 2015 19:24
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [Barbican] Providing service user read access to 
all tenant's certificates

Why not have lbaas do step 2? Even better would be to help with the instance 
user spec and combined with lbaas doing step 2, you could restrict secret 
access to just the amphora that need the secret?

Thanks,
Kevin


From: Vijay Venkatachalam
Sent: Tuesday, September 15, 2015 7:06:39 PM
To: OpenStack Development Mailing List 
(openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>)
Subject: [openstack-dev] [Barbican] Providing service user read access to all 
tenant's certificates
Hi,
   Is there a way to provide read access to a certain user to all 
secrets/containers of all project/tenant's certificates?
   This user with universal "read" privilege's will be used as a 
service user by LBaaS plugin to read tenant's certificates during LB 
configuration implementation.

   Today's LBaaS users are following the below mentioned process

1.  tenant's creator/admin user uploads a certificate info as secrets and 
container

2.  User then have to create ACLs for the LBaaS service user to access the 
containers and secrets

3.  User creates LB config with the container reference

4.  LBaaS plugin using the service user will then access container 
reference provided in LB config and proceeds to implemen

Re: [openstack-dev] [Barbican] Providing service user read access to all tenant's certificates

2015-09-18 Thread Nathan Reller
> But that approach looks a little untidy, because tenant admin has to do
some infrastructure work.

I would think infrastructure work would be part of the admin role. They are
doing other things such as creating LBaaS, which seems like an
infrastructure job to me. I would think configuring LBaaS and key
management are similar. It seems like you think they are not similar. Can
you explain more?

-Nate
__
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


Re: [openstack-dev] [Barbican] Providing service user read access to all tenant's certificates

2015-09-17 Thread Dave McCowan (dmccowan)

The tenant admin from Step 1, should also do Step 2.

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: Wednesday, September 16, 2015 at 9:57 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] [Barbican] Providing service user read access to 
all tenant's certificates


How does lbaas do step 2?
It does not have the privilege for that secret/container using the service user.
Should it use the keystone token through which user created LB config and 
assign read access for the secret/container to the LBaaS service user?

Thanks,
Vijay V.

From: Fox, Kevin M [mailto:kevin@pnnl.gov]
Sent: 16 September 2015 19:24
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [Barbican] Providing service user read access to 
all tenant's certificates

Why not have lbaas do step 2? Even better would be to help with the instance 
user spec and combined with lbaas doing step 2, you could restrict secret 
access to just the amphora that need the secret?

Thanks,
Kevin


From: Vijay Venkatachalam
Sent: Tuesday, September 15, 2015 7:06:39 PM
To: OpenStack Development Mailing List 
(openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>)
Subject: [openstack-dev] [Barbican] Providing service user read access to all 
tenant's certificates
Hi,
   Is there a way to provide read access to a certain user to all 
secrets/containers of all project/tenant’s certificates?
   This user with universal “read” privilege’s will be used as a 
service user by LBaaS plugin to read tenant’s certificates during LB 
configuration implementation.

   Today’s LBaaS users are following the below mentioned process

1.  tenant’s creator/admin user uploads a certificate info as secrets and 
container

2.  User then have to create ACLs for the LBaaS service user to access the 
containers and secrets

3.  User creates LB config with the container reference

4.  LBaaS plugin using the service user will then access container 
reference provided in LB config and proceeds to implement.

Ideally we would want to avoid step 2 in the process. Instead add a step 5 
where the lbaas plugin’s service user checks if the user configuring the LB has 
read access to the container reference provided.

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


Re: [openstack-dev] [Barbican] Providing service user read access to all tenant's certificates

2015-09-17 Thread Vijay Venkatachalam
Yes Dave, that is what is happening today.

But that approach looks a little untidy, because tenant admin has to do some 
infrastructure work.

It will be good from the user/tenant admin's perspective to just do 2 things

1.  Upload certificates info

2.  Create LBaaS Configuration with certificates already uploaded

Now because barbican and LBaaS does work nicely with each other, every tenant 
admin has to do like the following


1.  Upload certificates info

2.  Read a document or finds out there is a LBaaS service user and somehow 
gets hold of LBaaS service user's userid. Assigns read rights to that 
certificate to LBaaS service user.

3.  Creates LBaaS Configuration with certificates already uploaded

If feel this does not fit the "As a service" model where tenant's just care 
about what they have to.

Thanks,
Vijay V.

From: Dave McCowan (dmccowan) [mailto:dmcco...@cisco.com]
Sent: 17 September 2015 18:20
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [Barbican] Providing service user read access to 
all tenant's certificates


The tenant admin from Step 1, should also do Step 2.

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: Wednesday, September 16, 2015 at 9:57 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] [Barbican] Providing service user read access to 
all tenant's certificates


How does lbaas do step 2?
It does not have the privilege for that secret/container using the service user.
Should it use the keystone token through which user created LB config and 
assign read access for the secret/container to the LBaaS service user?

Thanks,
Vijay V.

From: Fox, Kevin M [mailto:kevin@pnnl.gov]
Sent: 16 September 2015 19:24
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [Barbican] Providing service user read access to 
all tenant's certificates

Why not have lbaas do step 2? Even better would be to help with the instance 
user spec and combined with lbaas doing step 2, you could restrict secret 
access to just the amphora that need the secret?

Thanks,
Kevin


From: Vijay Venkatachalam
Sent: Tuesday, September 15, 2015 7:06:39 PM
To: OpenStack Development Mailing List 
(openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>)
Subject: [openstack-dev] [Barbican] Providing service user read access to all 
tenant's certificates
Hi,
   Is there a way to provide read access to a certain user to all 
secrets/containers of all project/tenant's certificates?
   This user with universal "read" privilege's will be used as a 
service user by LBaaS plugin to read tenant's certificates during LB 
configuration implementation.

   Today's LBaaS users are following the below mentioned process

1.  tenant's creator/admin user uploads a certificate info as secrets and 
container

2.  User then have to create ACLs for the LBaaS service user to access the 
containers and secrets

3.  User creates LB config with the container reference

4.  LBaaS plugin using the service user will then access container 
reference provided in LB config and proceeds to implement.

Ideally we would want to avoid step 2 in the process. Instead add a step 5 
where the lbaas plugin's service user checks if the user configuring the LB has 
read access to the container reference provided.

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


Re: [openstack-dev] [Barbican] Providing service user read access to all tenant's certificates

2015-09-16 Thread Dave McCowan (dmccowan)
A user with the role "observer" in a project will have read access to all 
secrets and containers for that project, using the default settings in the 
policy.json file.

--Dave McCowan

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: Tuesday, September 15, 2015 at 10:06 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] [Barbican] Providing service user read access to all 
tenant's certificates

Hi,
   Is there a way to provide read access to a certain user to all 
secrets/containers of all project/tenant’s certificates?
   This user with universal “read” privilege’s will be used as a 
service user by LBaaS plugin to read tenant’s certificates during LB 
configuration implementation.

   Today’s LBaaS users are following the below mentioned process

1.  tenant’s creator/admin user uploads a certificate info as secrets and 
container

2.  User then have to create ACLs for the LBaaS service user to access the 
containers and secrets

3.  User creates LB config with the container reference

4.  LBaaS plugin using the service user will then access container 
reference provided in LB config and proceeds to implement.

Ideally we would want to avoid step 2 in the process. Instead add a step 5 
where the lbaas plugin’s service user checks if the user configuring the LB has 
read access to the container reference provided.

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


Re: [openstack-dev] [Barbican] Providing service user read access to all tenant's certificates

2015-09-16 Thread Fox, Kevin M
Why not have lbaas do step 2? Even better would be to help with the instance 
user spec and combined with lbaas doing step 2, you could restrict secret 
access to just the amphora that need the secret?

Thanks,
Kevin


From: Vijay Venkatachalam
Sent: Tuesday, September 15, 2015 7:06:39 PM
To: OpenStack Development Mailing List (openstack-dev@lists.openstack.org)
Subject: [openstack-dev] [Barbican] Providing service user read access to all 
tenant's certificates

Hi,
   Is there a way to provide read access to a certain user to all 
secrets/containers of all project/tenant’s certificates?
   This user with universal “read” privilege’s will be used as a 
service user by LBaaS plugin to read tenant’s certificates during LB 
configuration implementation.

   Today’s LBaaS users are following the below mentioned process

1.  tenant’s creator/admin user uploads a certificate info as secrets and 
container

2.  User then have to create ACLs for the LBaaS service user to access the 
containers and secrets

3.  User creates LB config with the container reference

4.  LBaaS plugin using the service user will then access container 
reference provided in LB config and proceeds to implement.

Ideally we would want to avoid step 2 in the process. Instead add a step 5 
where the lbaas plugin’s service user checks if the user configuring the LB has 
read access to the container reference provided.

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


Re: [openstack-dev] [Barbican] Providing service user read access to all tenant's certificates

2015-09-16 Thread Vijay Venkatachalam

How does lbaas do step 2?
It does not have the privilege for that secret/container using the service user.
Should it use the keystone token through which user created LB config and 
assign read access for the secret/container to the LBaaS service user?

Thanks,
Vijay V.

From: Fox, Kevin M [mailto:kevin@pnnl.gov]
Sent: 16 September 2015 19:24
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [Barbican] Providing service user read access to 
all tenant's certificates

Why not have lbaas do step 2? Even better would be to help with the instance 
user spec and combined with lbaas doing step 2, you could restrict secret 
access to just the amphora that need the secret?

Thanks,
Kevin


From: Vijay Venkatachalam
Sent: Tuesday, September 15, 2015 7:06:39 PM
To: OpenStack Development Mailing List 
(openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>)
Subject: [openstack-dev] [Barbican] Providing service user read access to all 
tenant's certificates
Hi,
   Is there a way to provide read access to a certain user to all 
secrets/containers of all project/tenant's certificates?
   This user with universal "read" privilege's will be used as a 
service user by LBaaS plugin to read tenant's certificates during LB 
configuration implementation.

   Today's LBaaS users are following the below mentioned process

1.  tenant's creator/admin user uploads a certificate info as secrets and 
container

2.  User then have to create ACLs for the LBaaS service user to access the 
containers and secrets

3.  User creates LB config with the container reference

4.  LBaaS plugin using the service user will then access container 
reference provided in LB config and proceeds to implement.

Ideally we would want to avoid step 2 in the process. Instead add a step 5 
where the lbaas plugin's service user checks if the user configuring the LB has 
read access to the container reference provided.

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


Re: [openstack-dev] [Barbican] Providing service user read access to all tenant's certificates

2015-09-16 Thread Vijay Venkatachalam

The user here is the LBaaS service user which needs read access. This service 
user does play any role in the config creator's project. The service user might 
be playing a different role is in a common project.
For ex. "admin" user with "admin" role in "admin" project is the service user 
in devstack for LBaaS.

--Vijay



From: Dave McCowan (dmccowan) [mailto:dmcco...@cisco.com]
Sent: 16 September 2015 18:36
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [Barbican] Providing service user read access to 
all tenant's certificates

A user with the role "observer" in a project will have read access to all 
secrets and containers for that project, using the default settings in the 
policy.json file.

--Dave McCowan

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: Tuesday, September 15, 2015 at 10:06 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] [Barbican] Providing service user read access to all 
tenant's certificates

Hi,
   Is there a way to provide read access to a certain user to all 
secrets/containers of all project/tenant's certificates?
   This user with universal "read" privilege's will be used as a 
service user by LBaaS plugin to read tenant's certificates during LB 
configuration implementation.

   Today's LBaaS users are following the below mentioned process

1.  tenant's creator/admin user uploads a certificate info as secrets and 
container

2.  User then have to create ACLs for the LBaaS service user to access the 
containers and secrets

3.  User creates LB config with the container reference

4.  LBaaS plugin using the service user will then access container 
reference provided in LB config and proceeds to implement.

Ideally we would want to avoid step 2 in the process. Instead add a step 5 
where the lbaas plugin's service user checks if the user configuring the LB has 
read access to the container reference provided.

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


[openstack-dev] [Barbican] Providing service user read access to all tenant's certificates

2015-09-15 Thread Vijay Venkatachalam
Hi,
   Is there a way to provide read access to a certain user to all 
secrets/containers of all project/tenant's certificates?
   This user with universal "read" privilege's will be used as a 
service user by LBaaS plugin to read tenant's certificates during LB 
configuration implementation.

   Today's LBaaS users are following the below mentioned process

1.  tenant's creator/admin user uploads a certificate info as secrets and 
container

2.  User then have to create ACLs for the LBaaS service user to access the 
containers and secrets

3.  User creates LB config with the container reference

4.  LBaaS plugin using the service user will then access container 
reference provided in LB config and proceeds to implement.

Ideally we would want to avoid step 2 in the process. Instead add a step 5 
where the lbaas plugin's service user checks if the user configuring the LB has 
read access to the container reference provided.

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