On Tue, Jul 14, 2009 at 07:16:12AM -0400, Bryan Kearney wrote:
Bob McWhirter wrote:
I know it's probably an implementation detail, but always better to consider security sooner rather than later.
Also, given that security is one way that cloud vendors differ, it's something we should bake into the API correctly the first time through.
And yet also, given the desire for stateless drivers where possible, it may affect our security decisions, depending on how we define "stateless" or "security".
Three main models if security seen by me thus far are:
a) Some login() type of call, which takes a name and a password. Many times the "password" is not your personal password associated with web-console logins, but another, randomly-generated (hah!) key that you can use for just API calls. The API key can be regenerated if it's been compromised, without affecting your web-UI login credentials. This login() returns a session token which is then passed through to every other call. This is basically normal web workflow with session ID in query string or a cookie, but with a separate password.
b) no login(), but an API key passed with each request. The ultimate service has no concept of sessions.
c) no login(), but each request is cryptographically signed. Once again, no concept of sessions.
Does our desire for stateless drivers also include a desire to have no session state? Or would that be an acceptable level of state the implementor of the API needs to concern himself with?
If our goal is to cross many APIs, I believe libvirtd (or the drivers in it) will need the notion of a session. That way it can locate my credentials and do the transformation.
If we insist on no sessions, and we're using, let's say, the adapter that talks EC2 signed SOAP out the backside, how do we communicate our EC2 credentials to the libcloud receiver? If we're doing credential mapping, then I can login to the proxy as "bob", and it's already in possession of my EC2 X.509 credentials, provided through some out-of-band method (ie, a portal).
But, if I'm using the driver directly, on port 80, over REST... Do we still insist on the driver having a store of credentials local to it? Or would the client be expected to ship his X.509 certificate to the driver with every request, so that the driver can sign the ultimate EC2 SOAP requests on his behalf?
I have assumed that the call between client->libvirtd would be different from libvirtd->driver (REST on the former, some internal AST on the latter). If that is the case, the client would need to use some frontend to do REST->AST, and therefore the use should be the same as if not local.
If we allow/require stateful sessions, then at least login(...) could take a driver-specific hash of information to set up the security context.
ie:
login( :x509_cert=>'.....', :access_key=>'...', :secret_access_key=>'....' )
for the EC2 driver, which would expect those 3 members.
Yes, login() would actually be a PUT to /sessions, and be RESTful...
But basically, leave the schema for the Session resource as void*, or implementation-defined, to allow for flexibility.
For name/password, login( :name=>'...', :password=>'...'), and for API key-based, just login( :key=>'...' ) or such.
So, is session state too much state? I think it'd be okay to store in RAM, no guarantee on longevity, and requires no local long-term storage.
No.. it is fine.
-- bk
My naive inclination would be to have the various libcloud adapters be completely stateless and *not* support sessions -- i.e. pass the key on every call. This is going to make them easier to talk through from e.g. the proxy. I'm willing to be talked out of this though if someone has a better idea.
--H