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:
Since these API calls into conductor are essentially an XML
representation of the "index" UI actions for provider_types, providers,
and provider_accounts, respectively, we _already_ have this built into
our permissions model. For whatever user that's making the call (i.e.
whatever Conductor user's credentials that were passed into the CLI), we
filter the full list of provider_types, providers, or provider_accounts
(w/ credentials) based on what objects the user has "view" permission
on. For provider accounts, in particular (the one of greatest concern,
since that's got credentials associated), a user won't have view access
to the provider account unless he is allowed to see the credentials --
ordinary self-service/end users will have no direct rights on a provider
account, even if it's one that their instances are deployed in, since
provider account availability is determined from the "environment"
mappings rather than direct user permissions.
So, in this case the effect is that if a user doesn't have explicit
'view' access on a provider, he can't push there -- however if the user
_does_ have this access, then the user can retrieve the credentials to
the provider account via a direct API call and use them whenever/wherever.
If we want to support a more generous image building facility -- i.e.
grant a user permission to upload images to a provider _without_ also
giving this user permission to retrieve the login credentials to the ec2
account, etc, then we'll have to do something more elaborate. This gets
into another issue that we've discussed briefly regarding API
authentication. Are there cases where we want to authenticate api calls
by the calling application rather than the credentials of the user
submitting it. For example, in the context of condor, should condor be
able to make conductor API calls _as Condor_ rather than as a given
login user -- to be authenticated by some sort of cert rather than via a
user's login/password (which Condor won't have).
I'm not sure how we'd handle this in the CLI case, but we'd need some
way for the builder user to provide login credentials to say "I can
build and push things" and for image factory to somehow obtain the
provider account credentials _without_ the possibility of the CLI user
obtaining them directly. Perhaps the CLI should pass the provider
account ID to Factory and have Image Factory request the credentials
from Conductor?
/me returns to his regularly scheduled PTO...
Scott
Cheers,
Mark.
_______________________________________________
aeolus-devel mailing list
aeolus-devel(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/aeolus-devel