cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Grizzanti <>
Subject Re: IAM guidelines for CS APIs
Date Tue, 18 Mar 2014 14:46:53 GMT

Thanks for the overview.  Will take a look at this and starting reviewing with the team here
to see where we can contribute.

What's the best way to contribute our code back for a feature like this?  So far for anything
I've been working on, I've created reviews on Review Board with patches that are linked to
a Jira (mostly bugs). Should we create a private fork, work on our changes and then raise
a review for each item?


David Grizzanti
Software Engineer
Sungard Availability Services
w: 215.446.1431
c: 570.575.0315

On March 17, 2014 at 2:18:15 PM, Min Chen ( wrote:

Hi David,  

Thanks a lot for your interest and willing to help on this feature. For  
the Phase I work laid out in  
and+Access+Management+%28IAM%29+Plugin, we have pretty much completed most  
of implementations and merged into 4.4 branch. The major items left for  
this feature are:  
1) Add more automated marvin test cases. We have added test_vm_iam marvin  
test for VM under new IAM model, but we need more coverage on most other  
entity types to make sure that there are not much regressions.  
2) As mentioned in the FS, for this release, creating a custom  
policy/group is supported through API only. For further releases, we can  
provide either a UI or a config file + policy language mechanism to  
facilitate the custom policy/group creation. If you have enough bandwidth  
to develop a simple utility to read from JSON-like policy/group  
configuration file to ease custom policy/group creation, that would be  
very beneficial to people who are interested in this feature. UI work is  
currently planned for 4.5.  
3) Phase I work has only built the foundation for us to provide true IAM  
services for CloudStack resources. But we haven't had time to modify all  
existing CloudStack hard-coded RBAC logics to integrate with this new IAM  
model, which are planned for Phase II and include the following 3 aspects:  
- Eliminate the need for shared and isolated networks  
- Modify dedicated resource feature to use new IAM model.  
- Handle IAM control on such non ControlledEntity like Domain and Service  
Offering(Disk offering, Network Offering). In Phase I, our current  
implementation has handled all ControlledEntity. These Non controlled  
entities are still using the old logic as before.  


On 3/17/14 10:57 AM, "David Grizzanti" <> wrote:  

>Hi Prachi,  
>I've been loosely following the work you've been doing with regard to the  
>IAM enhancements. We've been having some discussions recently regarding a  
>better access control model to CloudStack at SunGard for upcoming  
>requirements we have. I didn't realize until today that the work was this  
>close to being complete!  
>From looking over the documentation you provided, this feature looks  
>I was curious if everything you set out to accomplish that is discussed  
>completed? Otherwise, are there any outstanding items that you think  
>you need help with? We have some developers here who are looking to start  
>contributing. If there are no major items, even something like unit tests  
>for this feature could work.  
>On Fri, Mar 14, 2014 at 7:32 PM, Prachi Damle  
>> Hi there,  
>> With the introduction of the IAM feature, there are some new  
>> annotations/mechanisms to implement access control at CS API and Service  
>> layer.  
>> Min and I have documented guidelines to follow while adding APIs to  
>> CloudStack:  
>> If you are adding a new API or modifying an existing one, please refer  
>> this document to know:  
>> - How to set API permissions  
>> - How to use annotations for specifying correct entity  
>> permissions in CUD APIs  
>> - How to write list API's  
>> - How to support Response View Separation for API Commands  
>> Thank you,  
>> Prachi  
>David Grizzanti  
>Software Engineer  
>Sungard Availability Services  
>w: 215.446.1431  
>c: 570.575.0315  

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message