You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cloudstack.apache.org by Matthew Smart <ms...@smartsoftwareinc.com> on 2016/07/28 18:49:49 UTC
Architecture Advice
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,
--
Matthew Smart
President
Smart Software Solutions Inc.
108 S Pierre St.
Pierre, SD 57501
Phone: (605) 280-0383
Skype: msmart13
Email: msmart@smartsoftwareinc.com
Re: Architecture Advice
Posted by Rajani Karuturi <ra...@apache.org>.
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
(ilya.mailing.lists@gmail.com) 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: msmart@smartsoftwareinc.com (
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 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,
Re: VR VPN + LDAP access
Posted by Abhinandan Prateek <ab...@shapeblue.com>.
Yes, please do.
Thank you,
-abhi
abhinandan.prateek@shapeblue.com
www.shapeblue.com
53 Chandos Place, Covent Garden, London WC2N 4HSUK
@shapeblue
On 06/08/16, 12:09 AM, "Matthew Smart" <ms...@smartsoftwareinc.com> wrote:
>Abhi,
>
>What we want is to add LDAP support to openswan (ppp plugin maybe?) on
>the VR so that users can be authenticated and authorized via our ldap
>server. I have been digging through the code and familiarizing myself
>with it. Should I move this conversation to the dev list before I get
>into the use case I am working on?
>
>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 08/05/2016 04:17 AM, Abhinandan Prateek wrote:
>> Hi Matthew,
>>
>> What is the use case to add ldap (server ?) to VR ?
>>
>> The system vms are stateless and any support needs to be build into system vm template which as you rightly pointed out, is debian based.
>>
>> The way to get started on this is to first familiarise yourself with the process of building system vm templates. (In tools/appliance )
>> And next step will be to figure out how you can send configuration information from management server to a VR. (You can check how firewall rules are configured etc)
>>
>> -abhi
>>
>>
>>
>>
>> abhinandan.prateek@shapeblue.com
>> www.shapeblue.com
>> 53 Chandos Place, Covent Garden, London WC2N 4HSUK
>> @shapeblue
>>
>>
>>
>> On 04/08/16, 11:36 PM, "Matthew Smart" <ms...@smartsoftwareinc.com> wrote:
>>
>>> Guys,
>>>
>>> Thanks for the info. My next step is to engage the dev mailing list to
>>> see if there is any interest in my team contributing to add ldap or
>>> radius (not familiar with the available plugins for open/strong swan)
>>> support to the VR. I assume the SAML support in cloudstack is for the UI
>>> just like the LDAP support?
>>>
>>> In the meantime, I see two options that I want to run by you guys. The
>>> first being creating a VM cluster in a special account that has access
>>> to all of the isolated networks to use as a master VPN server.
>>> Essentially, I would be replicate my current non-cloudstack setup as a
>>> temporary solution. Given that I am more than qualified to manually
>>> manipulate the api, db, and configs to associate this VM with all of the
>>> isolated guest networks. Is this even possible?
>>>
>>> The other, less appealing option is to override the current VR VM with
>>> one I have configured with the ppp ldap plugin and configs I would need
>>> to support what I want to do. Obviously, I don't like the idea of
>>> breaking my ability to upgrade the VR as new versions are released but I
>>> think this is doable in that the VR looks to be just a Debian VM. If I
>>> am careful I should be able to add my changes without breaking it... but
>>> given my current knowledge of the VR and networking internals of
>>> Cloudstack I could easily break something in some subtle way that does
>>> not present until we are in production. Not ideal.
>>>
>>> What do you guys recommend as a course forward until we get a more
>>> modular access/auth subsystem contributed to the project? I am so close
>>> to having cloudstack do exactly what I want. It is 95% perfect for us. I
>>> just need to figure out this other 5%.
>>>
>>> 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 08/03/2016 12:48 AM, ilya wrote:
>>>> VR VPN + LDAP access
>
Re: VR VPN + LDAP access
Posted by Matthew Smart <ms...@smartsoftwareinc.com>.
Abhi,
What we want is to add LDAP support to openswan (ppp plugin maybe?) on
the VR so that users can be authenticated and authorized via our ldap
server. I have been digging through the code and familiarizing myself
with it. Should I move this conversation to the dev list before I get
into the use case I am working on?
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 08/05/2016 04:17 AM, Abhinandan Prateek wrote:
> Hi Matthew,
>
> What is the use case to add ldap (server ?) to VR ?
>
> The system vms are stateless and any support needs to be build into system vm template which as you rightly pointed out, is debian based.
>
> The way to get started on this is to first familiarise yourself with the process of building system vm templates. (In tools/appliance )
> And next step will be to figure out how you can send configuration information from management server to a VR. (You can check how firewall rules are configured etc)
>
> -abhi
>
>
>
>
> abhinandan.prateek@shapeblue.com
> www.shapeblue.com
> 53 Chandos Place, Covent Garden, London WC2N 4HSUK
> @shapeblue
>
>
>
> On 04/08/16, 11:36 PM, "Matthew Smart" <ms...@smartsoftwareinc.com> wrote:
>
>> Guys,
>>
>> Thanks for the info. My next step is to engage the dev mailing list to
>> see if there is any interest in my team contributing to add ldap or
>> radius (not familiar with the available plugins for open/strong swan)
>> support to the VR. I assume the SAML support in cloudstack is for the UI
>> just like the LDAP support?
>>
>> In the meantime, I see two options that I want to run by you guys. The
>> first being creating a VM cluster in a special account that has access
>> to all of the isolated networks to use as a master VPN server.
>> Essentially, I would be replicate my current non-cloudstack setup as a
>> temporary solution. Given that I am more than qualified to manually
>> manipulate the api, db, and configs to associate this VM with all of the
>> isolated guest networks. Is this even possible?
>>
>> The other, less appealing option is to override the current VR VM with
>> one I have configured with the ppp ldap plugin and configs I would need
>> to support what I want to do. Obviously, I don't like the idea of
>> breaking my ability to upgrade the VR as new versions are released but I
>> think this is doable in that the VR looks to be just a Debian VM. If I
>> am careful I should be able to add my changes without breaking it... but
>> given my current knowledge of the VR and networking internals of
>> Cloudstack I could easily break something in some subtle way that does
>> not present until we are in production. Not ideal.
>>
>> What do you guys recommend as a course forward until we get a more
>> modular access/auth subsystem contributed to the project? I am so close
>> to having cloudstack do exactly what I want. It is 95% perfect for us. I
>> just need to figure out this other 5%.
>>
>> 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 08/03/2016 12:48 AM, ilya wrote:
>>> VR VPN + LDAP access
Re: VR VPN + LDAP access
Posted by Abhinandan Prateek <ab...@shapeblue.com>.
Hi Matthew,
What is the use case to add ldap (server ?) to VR ?
The system vms are stateless and any support needs to be build into system vm template which as you rightly pointed out, is debian based.
The way to get started on this is to first familiarise yourself with the process of building system vm templates. (In tools/appliance )
And next step will be to figure out how you can send configuration information from management server to a VR. (You can check how firewall rules are configured etc)
-abhi
abhinandan.prateek@shapeblue.com
www.shapeblue.com
53 Chandos Place, Covent Garden, London WC2N 4HSUK
@shapeblue
On 04/08/16, 11:36 PM, "Matthew Smart" <ms...@smartsoftwareinc.com> wrote:
>Guys,
>
>Thanks for the info. My next step is to engage the dev mailing list to
>see if there is any interest in my team contributing to add ldap or
>radius (not familiar with the available plugins for open/strong swan)
>support to the VR. I assume the SAML support in cloudstack is for the UI
>just like the LDAP support?
>
>In the meantime, I see two options that I want to run by you guys. The
>first being creating a VM cluster in a special account that has access
>to all of the isolated networks to use as a master VPN server.
>Essentially, I would be replicate my current non-cloudstack setup as a
>temporary solution. Given that I am more than qualified to manually
>manipulate the api, db, and configs to associate this VM with all of the
>isolated guest networks. Is this even possible?
>
>The other, less appealing option is to override the current VR VM with
>one I have configured with the ppp ldap plugin and configs I would need
>to support what I want to do. Obviously, I don't like the idea of
>breaking my ability to upgrade the VR as new versions are released but I
>think this is doable in that the VR looks to be just a Debian VM. If I
>am careful I should be able to add my changes without breaking it... but
>given my current knowledge of the VR and networking internals of
>Cloudstack I could easily break something in some subtle way that does
>not present until we are in production. Not ideal.
>
>What do you guys recommend as a course forward until we get a more
>modular access/auth subsystem contributed to the project? I am so close
>to having cloudstack do exactly what I want. It is 95% perfect for us. I
>just need to figure out this other 5%.
>
>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 08/03/2016 12:48 AM, ilya wrote:
>> VR VPN + LDAP access
>
VR VPN + LDAP access
Posted by Matthew Smart <ms...@smartsoftwareinc.com>.
Guys,
Thanks for the info. My next step is to engage the dev mailing list to
see if there is any interest in my team contributing to add ldap or
radius (not familiar with the available plugins for open/strong swan)
support to the VR. I assume the SAML support in cloudstack is for the UI
just like the LDAP support?
In the meantime, I see two options that I want to run by you guys. The
first being creating a VM cluster in a special account that has access
to all of the isolated networks to use as a master VPN server.
Essentially, I would be replicate my current non-cloudstack setup as a
temporary solution. Given that I am more than qualified to manually
manipulate the api, db, and configs to associate this VM with all of the
isolated guest networks. Is this even possible?
The other, less appealing option is to override the current VR VM with
one I have configured with the ppp ldap plugin and configs I would need
to support what I want to do. Obviously, I don't like the idea of
breaking my ability to upgrade the VR as new versions are released but I
think this is doable in that the VR looks to be just a Debian VM. If I
am careful I should be able to add my changes without breaking it... but
given my current knowledge of the VR and networking internals of
Cloudstack I could easily break something in some subtle way that does
not present until we are in production. Not ideal.
What do you guys recommend as a course forward until we get a more
modular access/auth subsystem contributed to the project? I am so close
to having cloudstack do exactly what I want. It is 95% perfect for us. I
just need to figure out this other 5%.
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 08/03/2016 12:48 AM, ilya wrote:
> VR VPN + LDAP access
Re: Architecture Advice
Posted by ilya <il...@gmail.com>.
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: 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,
>>>
>
>
Re: Architecture Advice
Posted by Matthew Smart <ms...@smartsoftwareinc.com>.
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,
>>
Re: Architecture Advice
Posted by ilya <il...@gmail.com>.
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,
>