cloudstack-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From ilya <>
Subject Re: Architecture Advice
Date Wed, 03 Aug 2016 05:48:14 GMT

Noticed that you are on users list, if you get no response, try asking
on dev list.

Also, perhaps refine the subject to VR VPN + LDAP access. Lastly, there
is StrongSwan initiative to replace OpenSwan, but nothing about LDAP
integration that i could find.


On 8/2/16 12:52 PM, Matthew Smart wrote:
> Ilya,
> Thanks for the response. For the most part, our deployment is much
> simpler than yours. We allow only our senior sysadmins access to the
> Cloudstack UI (and only have 2 senior sysadmins currently). This access
> is already tied to LDAP and working perfectly. I don't mind using a vm
> for VPN since we have sysadmin staff with direct physical access to the
> datacenter 24/7. Worst case in an outtage they can connect directly to
> the bare metal servers and interface with a VM through the hypervisor
> vnc port just like the Cloudstack Console Proxy does.
> What we are stumbling on is allowing our development staff, sysadmins,
> and clients to access the vms directly via ssh and other access
> protocols. I have to allow them the ability to remote into vms to
> perform maintenance, configuration, and troubleshooting but have to keep
> these networks completely segregated and managed by our centralized LDAP
> system. This access is currently facilitated in our non-cloudstack
> environment by allowing them to VPN into segregated networks and
> directly access the vms but we do so by allowing our VPN cluster to
> access ALL segregated networks. This creates a single point of
> vulnerability in that if an attacker gains access to a server in the VPN
> cluster they have penetrated our segregation and can access all networks.
> My plan was to use the built in VPN capabilities of the VRouter
> instances to provide for a more secure asset segregation while allowing
> stakeholders the necessary access to their vms. The stumbling point
> right now is how we manage the vpns for the 50-60 separate networks we
> will have when this is rolled out. From what I can find, the current VPN
> implementation allows for the manual creation of 8 VPN users for each
> Cloudstack Account and I cannot find anything to indicate whether the
> VPN users can be managed via LDAP the way that the Cloudstack UI users are.
> Does anyone have any guidance on the capabilities of the VRouter VPN
> offering? Am I correct in my determination that there is not currently
> any way to configure it to pull auth and access rights from LDAP?
> Thanks,
> Matthew Smart
> President
> Smart Software Solutions Inc.
> 108 S Pierre St.
> Pierre, SD 57501
> Phone: (605) 280-0383
> Skype: msmart13
> Email:
> On 07/29/2016 02:30 AM, ilya wrote:
>> Matthew,
>> Interesting challenge, i operate in slightly different environment -
>> let me explain how it works in places i've been too in past and you can
>> decide if its something you see being a fit.
>> Since data center access is treated as top tier - access to it must be
>> guaranteed at all times - especially to sysadmin. Hence, i'm personally,
>> hesitant placing it on a VM - managed by cloudstack, openstack or vmware
>> or any virtual technology..
>> I'd prefer for it to be a physical redundant VPN appliance - but its
>> just me, being overly paranoid, bitten by many outages - and probably
>> not cloudy enough.
>> With that said, the VPN profile - will inherit a configuration that can
>> access whatever number of VLANs you have to offer - on the network
>> layer. For example, i'd create a Admin network that can access all
>> networks underneath that is bound to my VPN users.
>> As for cloudstack access, i see few ways of solving your challenge - but
>> i also believe i may not fully understand you design.
>> For example, in my environment, i may have close to 100 cloud admins.
>> These are the people that tend to different environments across many
>> datacenters doing different things. Some fix hypervisors, other deal
>> with network and vms or do capacity planning.
>> When they login to cloudstack to perfom management task - select few -
>> that we may trust - get root admin priveleges. They can access all
>> cloudstack entities below ROOT domain - there are no restrictions. This
>> is something that is available now cloudstack.
>> However, i may also have 98 users that i dont trust as much and want to
>> limit what they can do, for that - we will leverage another feature
>> called Dynamic CloudStack Roles A.K.A. RBAC.
>> link: - scroll down to
>> Management
>> What RBAC gets is an ability to define you won custom role within
>> cloudstack to perform only specific operations based on fairly granular
>> cloudstack API. For example, you may want a user who needs to be able to
>> READ content from CloudStack - but not make any changes.
>> You would create a role with "List*" priveleges, assing an account and
>> user on ROOT domain. This would be equivalent of read-only-admin user.
>> Other admins, could do VM stop, start, reboot, snapshot and read and
>> change some  settings - you can create a Power User role to do that as
>> well and since they are sysadmin users - you will assign them to ROOT
>> domain - so they can see all your customers within ACS.
>> There is no limit as to how granular you can be in terms of access to
>> cloudstack. If there is an API that does it - you can decide how and who
>> uses it.
>> You can also tie your cloudstack with LDAP group, but you still have to
>> import your users into cloudstack once - there is an import api command
>> for that. These users can be tied to specific account and role of your
>> choosing to only perform specific operations.
>> Lastly, RBAC has been committed to master branch and i believe it maybe
>> part of 4.9 release that community is testing now. However, if you feel
>> you want to be on older - more stable release - you can backport the
>> commits to your own branch and rebuild from source. We had this feature
>> backported to 4.5.2 - which we find stable for our needs.
>> Hope i answered some of your questions and VPN can be addressed by
>> someone else.
>> Regards
>> ilya
>> On 7/28/16 11:49 AM, Matthew Smart wrote:
>>> Not sure if this is the right place for this question but I am in the
>>> process of migrating my datacenter to cloudstack from a manually managed
>>> virtualization cluster. I am doing this because we need to implement
>>> full segregation between assets owned by different entities and managing
>>> that manually would be highly inefficient.
>>> I have everything configured and working exactly the way I want it from
>>> a segregation standpoint. When fully migrated we will have around 50
>>> separate accounts all segregated onto their own vlans. The stumbling
>>> block for me now is VPN access. We do not operate a public cloud. A
>>> small number of sysadmins in my organization are responsible for all
>>> management and administration of all assets hosted in the datacenter.
>>> Afaik, to use the VPN capability of the VRouter I would have to create
>>> users for each sysadmin in all 50 accounts and then propagate any
>>> changes to access rights via the api or manually through the UI. Our
>>> current setup has 7 segregated vlans that are accessible via a single
>>> OpenVPN gateway that queries my ldap server to determine access rights
>>> and pushes network routes when a user authenticates.
>>> I would like to reproduce this capability in Cloudstack but am faltering
>>> at determining how it could be done. I would prefer to keep all assets
>>> including the Master VPN gateway as vms inside my Cloudstack environment
>>> and really don't want to incur the overhead of adding an OpenVPN VM to
>>> each account. I also can't really just create a shared network and give
>>> each vm a nic on it since that breaks the asset segregation that
>>> precipitated this move to cloudstack. Finally, I have to be able to
>>> query my ldap server for authentication and authorization instead of the
>>> Cloudstack database.
>>> Has anyone dealt with a similar architecture? How do you minimize the
>>> overhead of a small group of admins and automated scripts needing access
>>> to all the accounts? We are a software development and hosting firm. I
>>> have 20 years experience both in development and in datacenter
>>> administration. I am not afraid to get my hands dirty and write
>>> something custom to handle this but I am a novice at cloudstack and am
>>> looking for some advice on how you would tackle this problem.
>>> Thanks,

View raw message