As of now, VPN users cannot be managed via LDAP in CloudStack. ~ Rajani http://cloudplatform.accelerite.com/
On August 3, 2016 at 11:18 AM, ilya ([email protected]) wrote:Matthew, Noticed that you are on users list, if you get no response, try askingon dev list. Also, perhaps refine the subject to VR VPN + LDAP access. Lastly, thereis StrongSwan initiative to replace OpenSwan, but nothing about LDAPintegration that i could find. Regardsilya On 8/2/16 12:52 PM, Matthew Smart wrote:Ilya, Thanks for the response. For the most part, our deployment is muchsimpler than yours. We allow only our senior sysadmins access to theCloudstack UI (and only have 2 senior sysadmins currently). This accessis already tied to LDAP and working perfectly. I don't mind using a vmfor VPN since we have sysadmin staff with direct physical access to thedatacenter 24/7. Worst case in an outtage they can connect directly tothe bare metal servers and interface with a VM through the hypervisorvnc 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 accessprotocols. I have to allow them the ability to remote into vms toperform maintenance, configuration, and troubleshooting but have to keepthese networks completely segregated and managed by our centralized LDAPsystem. This access is currently facilitated in our non-cloudstackenvironment by allowing them to VPN into segregated networks anddirectly access the vms but we do so by allowing our VPN cluster toaccess ALL segregated networks. This creates a single point ofvulnerability in that if an attacker gains access to a server in the VPNcluster they have penetrated our segregation and can access all networks. My plan was to use the built in VPN capabilities of the VRouterinstances to provide for a more secure asset segregation while allowingstakeholders the necessary access to their vms. The stumbling pointright now is how we manage the vpns for the 50-60 separate networks wewill have when this is rolled out. From what I can find, the current VPNimplementation allows for the manual creation of 8 VPN users for eachCloudstack Account and I cannot find anything to indicate whether theVPN 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 VPNoffering? Am I correct in my determination that there is not currentlyany way to configure it to pull auth and access rights from LDAP? Thanks, Matthew SmartPresidentSmart Software Solutions Inc.108 S Pierre St.Pierre, SD 57501 Phone: (605) 280-0383Skype: msmart13Email: [email protected] ( [email protected] ) 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 candecide if its something you see being a fit. Since data center access is treated as top tier - access to it must beguaranteed at all times - especially to sysadmin. Hence, i'm personally,hesitant placing it on a VM - managed by cloudstack, openstack or vmwareor any virtual technology.. I'd prefer for it to be a physical redundant VPN appliance - but itsjust me, being overly paranoid, bitten by many outages - and probablynot cloudy enough. With that said, the VPN profile - will inherit a configuration that canaccess whatever number of VLANs you have to offer - on the networklayer. For example, i'd create a Admin network that can access allnetworks underneath that is bound to my VPN users. As for cloudstack access, i see few ways of solving your challenge - buti 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 manydatacenters doing different things. Some fix hypervisors, other dealwith 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 allcloudstack entities below ROOT domain - there are no restrictions. Thisis something that is available now cloudstack. However, i may also have 98 users that i dont trust as much and want tolimit what they can do, for that - we will leverage another featurecalled Dynamic CloudStack Roles A.K.A. RBAC. link: http://www.shapeblue.com/cloudstack-101/ ( http://www.shapeblue.com/cloudstack-101/ ) - scroll down toManagement What RBAC gets is an ability to define you won custom role withincloudstack to perform only specific operations based on fairly granularcloudstack API. For example, you may want a user who needs to be able toREAD content from CloudStack - but not make any changes.You would create a role with "List*" priveleges, assing an account anduser on ROOT domain. This would be equivalent of read-only-admin user. Other admins, could do VM stop, start, reboot, snapshot and read andchange some settings - you can create a Power User role to do that aswell and since they are sysadmin users - you will assign them to ROOTdomain - so they can see all your customers within ACS. There is no limit as to how granular you can be in terms of access tocloudstack. If there is an API that does it - you can decide how and whouses it. You can also tie your cloudstack with LDAP group, but you still have toimport your users into cloudstack once - there is an import api commandfor that. These users can be tied to specific account and role of yourchoosing to only perform specific operations. Lastly, RBAC has been committed to master branch and i believe it maybepart of 4.9 release that community is testing now. However, if you feelyou want to be on older - more stable release - you can backport thecommits to your own branch and rebuild from source. We had this featurebackported to 4.5.2 - which we find stable for our needs. Hope i answered some of your questions and VPN can be addressed bysomeone else. RegardsilyaOn 7/28/16 11:49 AM, Matthew Smart wrote:Not sure if this is the right place for this question but I am in theprocess of migrating my datacenter to cloudstack from a manually managedvirtualization cluster. I am doing this because we need to implementfull segregation between assets owned by different entities and managingthat manually would be highly inefficient. I have everything configured and working exactly the way I want it froma segregation standpoint. When fully migrated we will have around 50separate accounts all segregated onto their own vlans. The stumblingblock for me now is VPN access. We do not operate a public cloud. Asmall number of sysadmins in my organization are responsible for allmanagement and administration of all assets hosted in the datacenter. Afaik, to use the VPN capability of the VRouter I would have to createusers for each sysadmin in all 50 accounts and then propagate anychanges to access rights via the api or manually through the UI. Ourcurrent setup has 7 segregated vlans that are accessible via a singleOpenVPN gateway that queries my ldap server to determine access rightsand pushes network routes when a user authenticates. I would like to reproduce this capability in Cloudstack but am falteringat determining how it could be done. I would prefer to keep all assetsincluding the Master VPN gateway as vms inside my Cloudstack environmentand really don't want to incur the overhead of adding an OpenVPN VM toeach account. I also can't really just create a shared network and giveeach vm a nic on it since that breaks the asset segregation thatprecipitated this move to cloudstack. Finally, I have to be able toquery my ldap server for authentication and authorization instead of theCloudstack database. Has anyone dealt with a similar architecture? How do you minimize theoverhead of a small group of admins and automated scripts needing accessto all the accounts? We are a software development and hosting firm. Ihave 20 years experience both in development and in datacenteradministration. I am not afraid to get my hands dirty and writesomething custom to handle this but I am a novice at cloudstack and amlooking for some advice on how you would tackle this problem. Thanks,
