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: msm...@smartsoftwareinc.com
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,
