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

[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) 
>
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) 
>
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 
>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: Wednesday, September 16, 2015 at 9:57 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


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) 
>
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)
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 

Re: [openstack-dev] FW: [Keystone][Folsom] Token re-use

[Kant, Arun]

 in this thread.

Let me summarize once again

1) Use case for keystone not to re-issue same token for same credentials
2) Ratelimit cons and service unavailability
3) Further information on python keyring if not going by keystone re-issue of 
the tokens.
On Wed, Jun 19, 2013 at 9:16 AM, Yee, Guang 
guang@hp.commailto:guang@hp.com wrote:
Just out of curiosity, is there really a use case where user need to request 
multiple tokens of the same scope, where the only difference are the expiration 
dates?


Guang


From: Dolph Mathews 
[mailto:dolph.math...@gmail.commailto:dolph.math...@gmail.com]
Sent: Wednesday, June 19, 2013 7:27 AM

To: OpenStack Development Mailing List
Subject: Re: [openstack-dev] FW: [Keystone][Folsom] Token re-use


On Wed, Jun 19, 2013 at 1:42 AM, Ali, Haneef 
haneef@hp.commailto:haneef@hp.com wrote:

1)  Token Caching is not always going to help. It depends on the 
application.E.g  A user  writes a cron  job to check the health of swift by 
listing a  predefined container every 1 minute.This will obviously create a 
token every minute.



2)  Also  I like to understand how rate limiting is done for v3 tokens.   
Rate limiting involves source ip + request pattern.  In V3 there are so many 
ways to get the token and the rate limiting becomes too complex


Rate limit the number of requests to POST /v2.0/tokens and POST /v3/auth/tokens

Just for unscoped token,  all the following are equivalent requests.   In case 
of scoped tokens we have even more combinations.   Rouge clients can easily 
mess with rate limiting by mixing request patterns. Also rate limiting across 
regions may not be possible.

a.UserId/Password

b.   UserName/Password/domainId

c.   UserName/Password/DomainName

Thanks
Haneef

From: Ravi Chunduru [mailto:ravi...@gmail.commailto:ravi...@gmail.com]
Sent: Tuesday, June 18, 2013 11:02 PM
To: OpenStack Development Mailing List
Subject: Re: [openstack-dev] FW: [Keystone][Folsom] Token re-use

I agree we need a way to overcome these rogue clients but by rate limiting 
genuine requests will get effected. Then one would need retries and some times 
critical operations gets failed. It beats the whole logic of being available.


About the keyrings, How do we tackle if a service is using JSON API calls and 
not python clients?

Thanks,
-Ravi.
On Tue, Jun 18, 2013 at 6:37 PM, Adam Young 
ayo...@redhat.commailto:ayo...@redhat.com wrote:
On 06/18/2013 09:13 PM, Kant, Arun wrote:
The issue with having un-managed number of tokens for same credential is that 
it can be easily exploited. Getting a token is one of initial step (gateway) to 
get access to services. A rogue client can keep creating unlimited number of 
tokens and possibly create denial of service attack on services. If there are 
somewhat limited number of tokens, then cloud provider can possibly use tokenId 
based rate-limiting approach.
Better here to rate limit, then.




Extending the expiry to some fixed interval might be okay as that can be 
considered as continuing user session similar to what is seen when a user keeps 
browsing an application while logged in.
Tokens are resources created by Keystone.  No reason to ask to create something 
new if it is not needed.

The caching needs to be done client side.  We have ongoing work using 
python-keyring to support that.

-Arun


From: Adam Young ayo...@redhat.commailto:ayo...@redhat.com
Reply-To: OpenStack Development Mailing List 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Friday, June 14, 2013 3:33 PM
To: 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Keystone][Folsom] Token re-use

On 06/13/2013 07:58 PM, Ravi Chunduru wrote:
Hi,
  We are having Folsom setup and we find that our token table increases a lot. 
I understand client can re-use the token but why doesnt keystone reuse the 
token if client asks it with same credentials..
I would like to know if there is any reason for not doing so.

Thanks in advance,
--
Ravi


___

OpenStack-dev mailing list

OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.orghttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
You can cache the token on the client side and reuse. Tokens have a an expiry, 
so if you request a new token, you extend the expiry.


___

OpenStack-dev mailing list

OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



--
Ravi

___
OpenStack-dev