Mailing-List: contact users-help@cloudstack.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@cloudstack.apache.org
Subject: Re: Architecture Advice
To: users@cloudstack.apache.org
References: <e6a87649-3a8f-aaef-4432-644ab84245f4@smartsoftwareinc.com>
 <4a0d226d-2af3-3fad-65f8-c23bf46d6542@gmail.com>
From: Matthew Smart <msmart@smartsoftwareinc.com>
Message-ID: <24f69b20-f72b-538a-e49c-8d956241d702@smartsoftwareinc.com>
Date: Tue, 2 Aug 2016 14:52:49 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.1.1
MIME-Version: 1.0
In-Reply-To: <4a0d226d-2af3-3fad-65f8-c23bf46d6542@gmail.com>
Content-Type: multipart/alternative;
 boundary="------------64C317593841953BDC627AF0"
archived-at: Tue, 02 Aug 2016 19:53:10 -0000

--------------64C317593841953BDC627AF0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

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: msmart@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,
>>


--------------64C317593841953BDC627AF0--