wrt authentication...
I think users should authenticate against libcloud, using a pluggable auth method. CompanyOne might have it wired up to LDAP for users to auth. CompanyTwo might use Kerb or RSA or whatever. CompanyThree might use a libcloud-specific Users table with local password hashes stored for use only with libcloud.
Then a strategy to map inbound consumers of libcloud to outbound credentials for the various backend drivers. CompanyOne might have a 1:1 mapping of libcloud user to back-end user. For instance, sending *my* particularly EC2 credentials out with commands to EC2. CompanyOne handles 230 people sending in monthly expense reports for their individual AWS bills.
CompanyTwo might have a many:1 mapping, where "bob" logs into libcloud, but uses a singular corporate-wide credential to fire up stuff on EC2. libcloud tracks the accounting for that. While A/P pays a single bill for $2000, they know that "bob" used $42 of it.
CompanyThree might have a dept:1 mapping, where "bob" is a member of JBoss, and uses JBoss EC2 creds, and "bryan" is a member of 'Red Hat' and uses Red Hat creds. That results in a bill from AWS for each department, instead of individual.
Some backends may require no authentication, where libcloud is the sole source of accounting. For internal datacenter clouds, for instance, running VMware ESXi of vSphere or whatever. "bob" used 400 hours of CPU time, and his department's budget is reduced by some arbitrarily determined "cost" per CPU hour.
Depending on the proxying strategy chosen, all users may already be enrolled in the clouds, or they may have to inform libcloud "here are *my* credentials for a particular backend" before that provider is enabled for them.
Next layer up, libcloud could restrict some users from using some backends. Maybe everyone can use the EC2 backend, but only IT can use the internal production cloud backend.
Which also brings up another point, which I think might relate to "clusters" in RHEV-M if I understand them correctly. While we might have "the RHEV-M driver", which may have different clouds powered by that driver. The QA cluster, the IT production cluster, etc. That can wait for v2 of libcloud, though. :)
-Bob
On Wed, Jul 08, 2009 at 01:45:13PM -0400, Bob McWhirter wrote:
wrt authentication...
I think users should authenticate against libcloud, using a pluggable auth method. CompanyOne might have it wired up to LDAP for users to auth. CompanyTwo might use Kerb or RSA or whatever. CompanyThree might use a libcloud-specific Users table with local password hashes stored for use only with libcloud.
Then a strategy to map inbound consumers of libcloud to outbound credentials for the various backend drivers. CompanyOne might have a 1:1 mapping of libcloud user to back-end user. For instance, sending *my* particularly EC2 credentials out with commands to EC2. CompanyOne handles 230 people sending in monthly expense reports for their individual AWS bills.
CompanyTwo might have a many:1 mapping, where "bob" logs into libcloud, but uses a singular corporate-wide credential to fire up stuff on EC2. libcloud tracks the accounting for that. While A/P pays a single bill for $2000, they know that "bob" used $42 of it.
CompanyThree might have a dept:1 mapping, where "bob" is a member of JBoss, and uses JBoss EC2 creds, and "bryan" is a member of 'Red Hat' and uses Red Hat creds. That results in a bill from AWS for each department, instead of individual.
Some backends may require no authentication, where libcloud is the sole source of accounting. For internal datacenter clouds, for instance, running VMware ESXi of vSphere or whatever. "bob" used 400 hours of CPU time, and his department's budget is reduced by some arbitrarily determined "cost" per CPU hour.
Depending on the proxying strategy chosen, all users may already be enrolled in the clouds, or they may have to inform libcloud "here are *my* credentials for a particular backend" before that provider is enabled for them.
Yes, I think this actually starts being pretty compelling. Look, we've invented a feature!
Next layer up, libcloud could restrict some users from using some backends. Maybe everyone can use the EC2 backend, but only IT can use the internal production cloud backend.
Which also brings up another point, which I think might relate to "clusters" in RHEV-M if I understand them correctly. While we might have "the RHEV-M driver", which may have different clouds powered by that driver. The QA cluster, the IT production cluster, etc. That can wait for v2 of libcloud, though. :)
In effect you might even have a separate connection for each cluster.
We had the same thought with hardware pools in oVirt (logically ~= rhev-m cluster) in the cloud focus, namely that each hardware pool would effectively represent a separate cloud.
--H
Hugh O. Brock wrote:
On Wed, Jul 08, 2009 at 01:45:13PM -0400, Bob McWhirter wrote:
wrt authentication...
I think users should authenticate against libcloud, using a pluggable auth method. CompanyOne might have it wired up to LDAP for users to auth. CompanyTwo might use Kerb or RSA or whatever. CompanyThree might use a libcloud-specific Users table with local password hashes stored for use only with libcloud.
Then a strategy to map inbound consumers of libcloud to outbound credentials for the various backend drivers. CompanyOne might have a 1:1 mapping of libcloud user to back-end user. For instance, sending *my* particularly EC2 credentials out with commands to EC2. CompanyOne handles 230 people sending in monthly expense reports for their individual AWS bills.
CompanyTwo might have a many:1 mapping, where "bob" logs into libcloud, but uses a singular corporate-wide credential to fire up stuff on EC2. libcloud tracks the accounting for that. While A/P pays a single bill for $2000, they know that "bob" used $42 of it.
CompanyThree might have a dept:1 mapping, where "bob" is a member of JBoss, and uses JBoss EC2 creds, and "bryan" is a member of 'Red Hat' and uses Red Hat creds. That results in a bill from AWS for each department, instead of individual.
Some backends may require no authentication, where libcloud is the sole source of accounting. For internal datacenter clouds, for instance, running VMware ESXi of vSphere or whatever. "bob" used 400 hours of CPU time, and his department's budget is reduced by some arbitrarily determined "cost" per CPU hour.
Depending on the proxying strategy chosen, all users may already be enrolled in the clouds, or they may have to inform libcloud "here are *my* credentials for a particular backend" before that provider is enabled for them.
Yes, I think this actually starts being pretty compelling. Look, we've invented a feature!
Next layer up, libcloud could restrict some users from using some backends. Maybe everyone can use the EC2 backend, but only IT can use the internal production cloud backend.
Which also brings up another point, which I think might relate to "clusters" in RHEV-M if I understand them correctly. While we might have "the RHEV-M driver", which may have different clouds powered by that driver. The QA cluster, the IT production cluster, etc. That can wait for v2 of libcloud, though. :)
In effect you might even have a separate connection for each cluster.
Let me go back to the libvloud API and hte service. Should the API have state? Do I believe that the API will have me connecting to 2 clouds at one time? Or.. will the higher level service allow me to do that? Perhaps we are demoing libcloud and cloudcloud (Betty and Wilma).
I make this analgous to libvirt and Virt-Manager. I believe there are 2 connections if I make use of virt-manager to look across 2 libvirt instances.
-- bk
From: libcloud-list-bounces@redhat.com [mailto:libcloud-list- bounces@redhat.com] On Behalf Of Bob McWhirter
Which also brings up another point, which I think might relate to "clusters" in RHEV-M if I understand them correctly. While we might have "the RHEV-M driver", which may have different clouds powered by that driver. The QA cluster, the IT production cluster, etc. That can wait for v2 of libcloud, though. :)
[IH] actually, we have 3 levels: - multiple RHEV-M installations - multiple data centers in an installation - multiple host cluster per data center.
Btw, This another good example for something that RHEV-M also needs. We've looked at these two for the java port: http://www.jboss.org/community/docs/DOC-13258?uniqueTitle=false http://www.acegisecurity.org/
-----Original Message----- From: libcloud-list-bounces@redhat.com [mailto:libcloud-list- bounces@redhat.com] On Behalf Of Bob McWhirter Sent: Wednesday, July 08, 2009 20:45 PM To: Libcloud-list@redhat.com Subject: [Libcloud-list] front-end/back-end authentication
wrt authentication...
I think users should authenticate against libcloud, using a pluggable auth method. CompanyOne might have it wired up to LDAP for users to auth. CompanyTwo might use Kerb or RSA or whatever. CompanyThree might use a libcloud-specific Users table with local password hashes stored for use only with libcloud.
Then a strategy to map inbound consumers of libcloud to outbound credentials for the various backend drivers. CompanyOne might have a 1:1 mapping of libcloud user to back-end user. For instance, sending *my* particularly EC2 credentials out with commands to EC2. CompanyOne handles 230 people sending in monthly expense reports for their individual AWS bills.
CompanyTwo might have a many:1 mapping, where "bob" logs into libcloud, but uses a singular corporate-wide credential to fire up stuff on EC2. libcloud tracks the accounting for that. While A/P pays a single bill for $2000, they know that "bob" used $42 of it.
CompanyThree might have a dept:1 mapping, where "bob" is a member of JBoss, and uses JBoss EC2 creds, and "bryan" is a member of 'Red Hat' and uses Red Hat creds. That results in a bill from AWS for each department, instead of individual.
Some backends may require no authentication, where libcloud is the sole source of accounting. For internal datacenter clouds, for instance, running VMware ESXi of vSphere or whatever. "bob" used 400 hours of CPU time, and his department's budget is reduced by some arbitrarily determined "cost" per CPU hour.
Depending on the proxying strategy chosen, all users may already be enrolled in the clouds, or they may have to inform libcloud "here are *my* credentials for a particular backend" before that provider is enabled for them.
Next layer up, libcloud could restrict some users from using some backends. Maybe everyone can use the EC2 backend, but only IT can use the internal production cloud backend.
Which also brings up another point, which I think might relate to "clusters" in RHEV-M if I understand them correctly. While we might have "the RHEV-M driver", which may have different clouds powered by that driver. The QA cluster, the IT production cluster, etc. That can wait for v2 of libcloud, though. :)
-Bob
Libcloud-list mailing list Libcloud-list@redhat.com https://www.redhat.com/mailman/listinfo/libcloud-list
deltacloud-devel@lists.fedorahosted.org
-
Bob McWhirter -
Bryan Kearney -
Hugh O. Brock -
iheim＠redhat.com