[openstack-dev] Keystone Certificate Distribution

Adam Young ayoung at redhat.com
Wed Apr 24 16:03:45 UTC 2013


On 04/24/2013 08:27 AM, Dolph Mathews wrote:
> Given that credentials are owned by users, and there may be more than 
> one "admin" user, I'm not sure that's ideal.
The plan was always to have some way to scoped down the signing cert.  
It seems like the two potential scopes is either the "keystone" user or 
the keystone endpoint.  It seems like the User object is more consistent 
with the rest of the cert management.  We can specify who the default 
signing user is either in a config file change or via some new API.  I'm 
trying to do this within the previous design approach, though, and I am 
not certain that any new API is really desirable.  We had discussed 
using the Credentials API for this in the past.  Agreeds that we 
shouldn't just say "admin" although that might be a viable default.

An alternative is to require a "signing user" field into the PKI token 
format.  That was an extension I was planning for anyway, but had not 
yet specified.  It still leaves undefinied how to enforce that a given 
user certificate is authorized to sign tokens.

We need to ship the  CA cert alongside the signing cert as well.

The more I think about it, the more I am concerned with using the 
credential API as is.  I think that the certificates we are talking 
about here need to be very carefully controlled.  We don't want someone 
uploading their own certificate and redirecting the PKI sigining to 
their own machines certificate.  I think that the signing certificates 
need to be stored in the filesystem, and the Keystone Posix user (or 
Apache HTTPD user) should only have read access to these.





>
>
> -Dolph
>
>
> On Tue, Apr 23, 2013 at 11:04 PM, Adam Young <ayoung at redhat.com 
> <mailto:ayoung at redhat.com>> wrote:
>
>     On 04/23/2013 10:29 PM, Dolph Mathews wrote:
>>     It's not a core API feature, because as Jonathan pointed out, the
>>     resources don't make sense in a UUID configuration. If it ends up
>>     in v3, it should be done as an extension and they should raise a
>>     404 when the token_format is UUID (or in Havana, a standalone
>>     middleware that you install when opting for the PKI token_factory
>>     plugin).
>
>     I'd like to leave it as V2 only.  For V3, we should make use of
>     the credential API. The CA cert and the signing certs should both
>     be owned by the keystone admin user, so the question is how should
>     the auth_token middleware figure that out?
>
>
>>
>>
>>     -Dolph
>>
>>
>>     On Tue, Apr 23, 2013 at 8:13 PM, Adam Young <ayoung at redhat.com
>>     <mailto:ayoung at redhat.com>> wrote:
>>
>>         On 04/23/2013 06:22 PM, Yee, Guang wrote:
>>>
>>>         I think that’s debatable. But please file a bug so we can
>>>         keep track of it.
>>>
>>>         Thanks,
>>>
>>>         Guang
>>>
>>>         *From:*Brownell, Jonathan C (Corvallis)
>>>         *Sent:* Tuesday, April 23, 2013 3:10 PM
>>>         *To:* Yee, Guang; Miller, Mark M (EB SW Cloud - R&D -
>>>         Corvallis); Adam Young; Dolph Mathews
>>>         *Subject:* RE: Keystone Certificate Distribution
>>>
>>>         I was also surprised to see that the /v2.0/certificates/*
>>>         content is available even when the token_format = UUID.
>>>
>>>         Jonathan
>>>
>>>         *From:*Yee, Guang
>>>         *Sent:* Tuesday, April 23, 2013 2:24 PM
>>>         *To:* Miller, Mark M (EB SW Cloud - R&D - Corvallis); Adam
>>>         Young; Dolph Mathews
>>>         *Cc:* Brownell, Jonathan C (Corvallis)
>>>         *Subject:* RE: Keystone Certificate Distribution
>>>
>>>         Adam, Dolph,
>>>
>>>         Looks like the certificate distribution APIs are not in the
>>>         V3 API set.
>>>
>>>         /certificates/ca
>>>
>>>         /certificates/signing
>>>
>>>         You guys recall why we didn’t include them. In any case,
>>>         given that PKI token is now the default, we should include
>>>         them in 3.1. What say you?
>>>
>>>         Guang
>>>
>>         No, it is not a bug.  The content of that file might not be
>>         needed, but there is no reason to hide it.
>>
>>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130424/3e588300/attachment.html>


More information about the OpenStack-dev mailing list