cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rohit Yadav <>
Subject Re: Arch Rework RFC: API refactoring updates
Date Fri, 07 Dec 2012 18:22:00 GMT
On 06-Dec-2012, at 9:59 PM, Koushik Das <> wrote:

> Rohit,
> Can you explain the "admin" and "user" security level? I don't see that in

That was part of Alex's talk on "The future of CloudStack Architecture", will ask him to share
somewhere, I'm unable to find it myself.
The FS document on that wiki page refers to this work, "packaging the commands per entity

I'm not sure if we should do separate cmds per security level, but the idea is that certain
apis should not be shipped with the user API server, so that would be the ultimate isolation
or restriction of APIs.

>From a sysadmins perspective, if we get it right the storyboard would be like this: they
would install CloudStack and it would only have cloud-engine and nothing else, they can go
ahead and install the mgmt API server which can be controlled via the UI or cloudmonkey, using
which they can configure their hosts, zones, etc. If they want to have API servers for users,
they can start a VM which would run user API server. The idea is that unless you want a service,
CS should not start it, for ex. for their own consumption an org may not require an user API
server. On each VM the user API server could have different sets of APIs served via different
urls end points (like url/hr, url/mgmt, url/engg etc.) for users.

> Is this just a classification in terms of packaging or will there be a separate class
hierarchy for admin vs. user commands?

Yes, that is finished now, about 300 apis.
You may checkout the code from api_refactoring. But, Mice raised an interesting question about
domain admins, which I'm not sure. Will discuss and get back on this. The assumption I made
was domain and system admins are within the datacenter. If not, one solution is to run multiple
mgmt servers (in VMs as a service) with different sets of whitelisted apis served on different
end points.

> Also will there be more stringent input validations/additional checks in user level APIs
compared to admin ones?

All the validations should be dealt by the API layer, cloud-engine should orchestrate and
not do any checking.


> Thanks,
> Koushik
> -----Original Message-----
> From: Rohit Yadav [] 
> Sent: Friday, December 07, 2012 1:37 AM
> To:
> Subject: Arch Rework RFC: API refactoring updates
> Few updates;
> 1. Moved and classified all apis (except the anomalies, see other email) into namespace
org.apache.cloudstack.api 2. There are two packages, admin and user in which the APIs are
grouped based on security level. Note; APIs are not grouped based on roles.
> 3. Further in each org.apache.cloudstack.api.{admin,user}.command pkg, the APIs are grouped
as per api affinity (for ex. all vm related ones in vm pkg).
> 4. Few usage related APIs could not be moved from cloud-server to cloud-api, as they
are tightly coupled with classes available in cloud-server.
> 5. is fixed.
> 6. Checked, the api_refactoring merges fine with a minor merge conflicts. The build on
the branch is broken, would be fixed soon.
> I request that if you're adding any new class, please use the namespace org.apache.cloudstack.
> Road ahead:
> - Because of 1,2,3; there would be two classes of API server. The first one would be
available for users, the user API server which would handle requests from network outside
the datacenter which Alex refers to as "over the wire" requests. The second one would be available
for sysadmins, the mgmt API server which would handle requests from admins/sysadmins within
the datacenter;
> user API server would use only the org.apache.cloudstack.api.user artifact admin API
server would use both org.apache.cloudstack.api.admin and org.apache.cloudstack.api.user Based
on the arch. rework docs, ppts, talks, Alex's idea was to separate api based on security level
would give ultimate isolation.
> - Separate out cloud-api, and make it run as a separate web app like awsapi.
> - Annotations and separation of API based on api affinity would help automate apidoc
generation, api discovery over an api endpoint, so clients (UI or cloudmonkey etc.) would
be able to discover
> - The syntax is horrible, I want to get rid of the evil syntax by
having an apiname annotation for all API Cmd classes and the API server would be able to load
this info during runtime. In, we should be just able to set policy for
user role for each api, if apiname is not declared it's blacklisted. It becomes tricky with
plugins. I don't know how to get it right the first time, but let's try.
> - ACL and security checking at API layer, the requests would be just passed to (multiple)
cloud-engine which won't handle them, as that will only orchestrate.
> - Roles would be decided from Multiple API servers can be run with
different combination of rules in This would allow separation of policy
from mechanism, and multiple roles and end points. For example, an admin can create http routers
for these api server, so: <url>/hr, <url>/finance, <url>/marketting can
be proxies to different user api servers with different set of whitelisted apis.
> Comments, suggestions, flames?
> Regards.

View raw message