Matthew, 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. Regards ilya 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: [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 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: http://www.shapeblue.com/cloudstack-101/ - 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, >>> > >
