On 06-Dec-2012, at 9:59 PM, Koushik Das <[email protected]> wrote:
> Rohit, > > Can you explain the "admin" and "user" security level? I don't see that in > https://cwiki.apache.org/confluence/display/CLOUDSTACK/CloudStack+API+refactoring. Koushik, 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 category". 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. Regards. > > Thanks, > Koushik > > -----Original Message----- > From: Rohit Yadav [mailto:[email protected]] > Sent: Friday, December 07, 2012 1:37 AM > To: [email protected] > 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. commands.properties 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 commands.properties 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 > commands.properties, 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 commands.properties. Multiple API servers can > be run with different combination of rules in commands.properties. 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.
