cloudstack-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rajani Karuturi <>
Subject Re: Architecture Advice
Date Wed, 03 Aug 2016 08:28:05 GMT
As of now, VPN users cannot be managed via LDAP in CloudStack.

~ Rajani

On August 3, 2016 at 11:18 AM, ilya
( 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.
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?
Matthew SmartPresidentSmart Software Solutions Inc.108 S Pierre
St.Pierre, SD 57501
Phone: (605) 280-0383Skype:
msmart13Email: ( )
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
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
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: (
) - scroll down
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
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
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
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.
  • Unnamed multipart/alternative (inline, 7-Bit, 0 bytes)
View raw message