cloudstack-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From ilya <ilya.mailing.li...@gmail.com>
Subject Re: Cloudstack - users, groups, privileges
Date Fri, 20 Mar 2015 19:36:50 GMT
Robert,

There are many ways cloudstack can be used. Please tell us what your 
overall objective is.

LDAP integration works fine as well as SASLv2 support is there. The user 
needs to exist in cloudstack before it can be authenticated with LDAP. 
This can be automated via scripts. There is a feature in the works to be 
able to bypass the need for user imports in LDAP and use LDAP groups, 
but its probably a release out.

 > How do you handle central authentication, ldap, with multiple tenants 
and operation teams in combination with tenant resource dedication and 
the principle of least privilege?

As for managing multiple teams, consider using accounts and domains 
(cloudstack concepts).
For example, you have Team A that works on specific applications, you 
create a domain and an account for that team. The account that was 
created for this domain has 2 roles, admin and user. When user logs into 
that domain, he can only touch, see or create VMs within that domain. 
Domains are very granular when it comes to resource allocation. If you 
have teams that actually paid for specific hardware and want it all, you 
can dedicate that hardware to specific account/domain.

There is also a nifty feature called projects - which is quite helpful 
and works similarly.  You can adjust things on global level by tweaking 
API permissions model as its is stored in config file.

While its a cloud platform which intends to target public cloud 
providers in true sense, there are many private clouds that use 
cloudstack. It jsut takes a bit of playing around to understand how it 
fits in your model.

Also a common trend for very large orgs is to create a front-end 
dashboard that leverages cloudstack API engine and dont use cloudstack UI.

 >PXE and manual configuration of network devices is too slow and 
expensive for some projects.

Not sure what the issue here, but general challenge is managing ACLs and 
VLANs. With CloudStack Security Groups (XEN and KVM supports SG), this 
is handled rather well. You dont need to worry about upstream ACL 
changes on your physical firewall, you dont need to trunk anything. You 
can have 1 or several large networks. With ACS you can create the rules 
of what can talk to what, cloudstack will push the configuration changes 
to each respective hypervisors and update iptables. If VM migrates, 
rules migrate with it. Cloudstack manages rules syncronization across 
all hypervisors in that zone. This model has been ran in very large 
private cloud implementations, largest known customer was Zynga with 40k 
hosts. There are many others..

Tell us about the scale, technology and layout, we can help with design 
- or reach out to consulting firms that offer professional services.

Regards
ilya

On 3/20/15 12:01 PM, Robert wrote:
> Hey,
>
> currently I'm evaluating Cloudstack as internal orchestration software to reach cloud
speed and flexibility. PXE and manual configuration of network devices is too slow and expensive
for some projects.
>
> In the first step our customers will not have direct access to the Cloudstack Api or
UI.
>
> Based on my understanding Cloudstack does not support a permission model, where it's
possible to assign users to groups, groups to tenants and permissions per tenant to groups.
>
> How do you handle central authentication, ldap, with multiple tenants and operation teams
in combination with tenant resource dedication and the principle of least privilege?
>
> Enjoy your weekend.
>
>
> Thanks,
> Robert


Mime
View raw message