Public cloudstack UI

[Brian Galura <Br...@citrix.com>]

I get the impression cloudstack was really designed for internal clouds. Does anyone have recommendations for securing a publicly facing install?

I saw recently there was a patch for rate limiting to mitigate some attacks and we can have some network devices do some basic things in front of the UI/API like ssl etc. 

Re: Public cloudstack UI

[David Nalley <da...@gnsa.us>]

Ed from Datapipe presented about some of the challenges at the CCC in Vegas
http://www.slideshare.net/elaczynski/solving-the-cloudstack-puzzle-the-complete-stack-explored

To be clear, the UI is a reference implementation, and while plenty of
folks use it completely stock as well as the default API interface -
lots of people don't and implement their own tools or use other
publicly available tools.

--David



On Thu, Jul 18, 2013 at 4:04 PM, Brian Galura <Br...@citrix.com> wrote:
> I get the impression cloudstack was really designed for internal clouds. Does anyone have recommendations for securing a publicly facing install?
>
> I saw recently there was a patch for rate limiting to mitigate some attacks and we can have some network devices do some basic things in front of the UI/API like ssl etc.

RE: Public cloudstack UI

["Musayev, Ilya" <im...@webmd.net>]

I've looked at Eds slides, I do disagree with him on some aspects. I have a feeling he bases it off older version or older CCP platform.

> -----Original Message-----
> From: Chip Childers [mailto:chip.childers@sungard.com]
> Sent: Thursday, July 18, 2013 4:19 PM
> To: users@cloudstack.apache.org
> Subject: Re: Public cloudstack UI
> 
> On Thu, Jul 18, 2013 at 08:04:58PM +0000, Brian Galura wrote:
> > I get the impression cloudstack was really designed for internal clouds.
> 
> I wouldn't say that at all.  There are many public clouds using CloudStack.
> 
> > Does anyone have recommendations for securing a publicly facing install?
> 
> That would be a great document / blog post to write, but I'm not aware of
> one.
> 
> >
> > I saw recently there was a patch for rate limiting to mitigate some attacks
> and we can have some network devices do some basic things in front of the
> UI/API like ssl etc.
> 
> Correct, and really that's where a provider has to spend the time.
> Securing the management environment is the primary area of effort for a
> provider, since CloudStack itself takes care of the tenants.  That environment
> should (1) be built with redundancy in mind, (2) be protected from the big
> bad Internet with appropriate FW and / or other network security
> technologies.  Load balancing is also critical to add somewhere, and would
> normally be the place where you would do your SSL termination for access to
> the CloudStack API / UI.
> 
> OTOH, The method of protecting the customer environments will vary,
> depending on the zone type and other network offering selections that the
> provider makes.
> 
> For example, let's assume an advanced networking zone using VLANs for
> isolation.  In that environment, there is a "public" network that can easily be
> tied to the Internet directly.  The VR's provide FW services for the customer
> VMs.
> 
> Now, you can take it a step further and provide cloud-wide edge security,
> but anything that limits the customer's ability to self service firewall policies
> should probably be avoided (in the general IaaS use case).  If an org is more
> comfortable using a hardware FW, then that can be done as well.  Lots of
> flexibility is available for deployment designs.
> 
> So to sum it up, CloudStack is *absolutely* designed for a public provider.
> You just have to think about how to configure your environment correctly.
> That's really out of scope from what CloudStack itself should be handling.
> 
> -chip

Re: Public cloudstack UI

[Chip Childers <ch...@sungard.com>]

On Thu, Jul 18, 2013 at 08:04:58PM +0000, Brian Galura wrote:
> I get the impression cloudstack was really designed for internal clouds. 

I wouldn't say that at all.  There are many public clouds using
CloudStack.

> Does anyone have recommendations for securing a publicly facing install?

That would be a great document / blog post to write, but I'm not aware
of one.

> 
> I saw recently there was a patch for rate limiting to mitigate some attacks and we can have some network devices do some basic things in front of the UI/API like ssl etc. 

Correct, and really that's where a provider has to spend the time.
Securing the management environment is the primary area of effort for a
provider, since CloudStack itself takes care of the tenants.  That
environment should (1) be built with redundancy in mind, (2) be
protected from the big bad Internet with appropriate FW and / or other
network security technologies.  Load balancing is also critical to add
somewhere, and would normally be the place where you would do your SSL
termination for access to the CloudStack API / UI.

OTOH, The method of protecting the customer environments will vary, depending
on the zone type and other network offering selections that the provider
makes.  

For example, let's assume an advanced networking zone using
VLANs for isolation.  In that environment, there is a "public" network
that can easily be tied to the Internet directly.  The VR's provide FW
services for the customer VMs.

Now, you can take it a step further and provide cloud-wide edge
security, but anything that limits the customer's ability to self
service firewall policies should probably be avoided (in the general
IaaS use case).  If an org is more comfortable using a hardware FW, then
that can be done as well.  Lots of flexibility is available for
deployment designs.

So to sum it up, CloudStack is *absolutely* designed for a public
provider.  You just have to think about how to configure your
environment correctly.  That's really out of scope from what CloudStack
itself should be handling.

-chip