On Thu, 2011-05-26 at 23:50 -0400, Scott Seago wrote:
On 05/26/2011 09:26 AM, Mark McLoughlin wrote:
> On Tue, 2011-05-24 at 15:52 +0100, Mark McLoughlin wrote:
>> = Conductor APIs =
>>
>> Conductor needs APIs to support the following:
>>
> ...
>> 3) Dump a<provider_credentials/> document encapsulating all of the
>> available provider accounts
>>
>> The latter API would be subject to authentication and access control.
> We need to think about the access control rules here.
>
> What users would be allowed to access these credentials?
>
> Users who don't have access to the credentials can't build images for
> those providers.
>
> Thoughts?
>
So yes, this one is more difficult w/ the separation. When it's all
integrated in one app, it's easy enough to say that a user has "push"
access for provider images under a provider account without direct
access to the provider credentials.
Now, however, we're getting credentials from conductor and using them
elsewhere, so without additional security measures in place, we can't
really return credentials for provider accounts unless the calling user
has explicit view access on the provider account. If this restriction
is OK for beta, then the solution is relatively straightforward:
Yep, I think we'll have to live with this restriction for the very short
term.
After the next Aeolus release, I think we'll need to add conductor APIs
which self-service users can use to build and push. These would pass
directly through to the image factory APIs. That way the self-service
user doesn't ever get access to the credentials.
Cheers,
Mark.