cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Will Stevens <>
Subject Re: [PROPOSE] Palo Alto Firewall Integration
Date Thu, 28 Feb 2013 17:19:22 GMT
Hi Manan,

Thanks for taking an interest in this project.

1. I am working with the 5.0.0 version of their OS, but I think the APIs I
am implementing are backwards compatible to the 4.1.0 version.
2. I am using the API that is exposed by the Firewall device (or Panorama),
so if you have a Palo Alto device then you have access to the APIs.  I am
confirming that I can make the API documentation available publicly.  If I
can, I will add it to the spec.
3. The main reason the Virtual Firewall is out of scope is because I am
working on a tight delivery timeline.  I will touch on this topic more when
I answer 5.
4. I do not plan to support Inline mode (yet).  The firewall will be able
to handle Source NAT, Static NAT, Firewall Policies and Port Forwarding to
start with.  Basically what the SRX currently supports.  Let me know if you
want more details about something specific.
5. This question goes to the heart of what I am trying to figure out right
now.  I want to write it so it is multi-tenant aware, but there are a few
ways to do that (which I am still researching).

   - I could use vsys and setup a different vsys for each tenant.  This
   would give us tenant separation and is the easiest to implement and manage.
    However, this concept only works on the newer Palo Alto firewalls.  Also,
   this mechanism will NOT work on Virtual Firewalls as they are not setup to
   handle multiple vsys.
   - Another option is separation by Zone.  We would have the Untrusted
   zone (being the internet) and instead of just having a single Trusted
   internal zone, we would have a different trusted zone per tenant.  I still
   have to figure out all the details with this approach, but that is the
   basic idea.
   - The next option I am not as clear on.  It would use dynamic addresses
   and each tenant would get an address group with their dynamic addresses.  I
   have to spend more time understanding how this would work to figure out if
   it is a viable option.

The options above basically cover the 'Shared' firewall setup.  The next
piece of your question is about managing multiple firewall devices.  This
is supported by Palo Alto through the Panorama addition.  Panorama does
have an additional cost.  According to Palo Alto it is nominal in
comparison to the cost of the device its self.  They say that pretty much
everyone buys Panorama with their device.
If we ignore the additional cost for the sake of argument.  How would you
expect the firewalls to be managed.  Would all config get pushed to all
firewalls all the time?  Or would there have to be a mechanism for
isolating a specific firewall in the CloudStack UI?

If you can flesh out more of what you have in mind for this piece I will
look into it more.

6. My understanding is that Palo Alto's virtual firewall implementation
assumes that it is providing service to a single tenant (which is why vsys
is not compatible with it).  We might be able to figure out how to add
support for it by requiring that it be a Dedicated firewall.  I have not
put much thought into this yet.  I have to put a lot of thought into the
multi-firewall, multi-tentant configuration still.  I only just started
looking into how I am going to handle this.

Please feel free to ask follow up questions.  A knowledgable debate on this
topic will probably help everyone.



On Tue, Feb 26, 2013 at 7:05 PM, Manan Shah <> wrote:

> Hi Will,
> It is nice to see that you are adding integration with Palo Alto Firewall.
> I have read the functional spec and I have a few additional questions.
> 1. Would this module work with all Palo Alto Firewalls or any specific
> firewall models only?
> 2. Are you using all Publicly available APIs?
> 3. You mentioned that the Virtual Firewall is out-of-scope. Is that
> because it uses a different set of APIs?
> 4. What use cases you plan to enable?
> 5. Are you going to enable it as a per-Tenant/per-Network instance?
> Currently, there are some restrictions with the Juniper SRX support in
> that you can't have multiple SRX supported per Zone and there is no way to
> specify if you want to have a shared FW or a dedicated FW. It would be
> quite useful if you can provide the functionality to support multiple FW /
> Zone and identify them as dedicate or shared. Similar functionality exists
> for Load balancers.
> 5. I know Virtual Firewalls are out of scope but if and when the support
> is added, it would be good to add support for Life Cycle Management of
> Palo Alto Firewalls?
> Sorry in advance for so many questions but I wanted to better understand
> the support you are providing.
> Regards,
> Manan Shah
> On 2/14/13 10:13 AM, "Will Stevens" <> wrote:
> >Thanks for the information as well as the jira permissions.  I have
> >assigned the issue to myself.
> >
> >I will keep it in 'nonoss' for now and as I get near the end of the
> >project
> >I can make a more educated decision on that point.  The change is pretty
> >simple and it won't impact the implementation of the code, so its a
> >non-blocking issue for now.
> >
> >Thanks again...
> >
> >
> >On Thu, Feb 14, 2013 at 12:54 PM, Chip Childers
> ><>wrote:
> >
> >> On Thu, Feb 14, 2013 at 12:24:13PM -0500, Will Stevens wrote:
> >> >    - I am currently compiling my code using the 'nonoss' flag similar
> >>to
> >> >    JuniperSRX, Netscaler, etc...  I will not be referencing any code
> >> external
> >> >    to CloudStack, but I will be integrating with the Palo Alto API.  I
> >> need to
> >> >    confirm that the Palo Alto API documentation can be made publicly
> >> >    accessible.  What is the standard practice regarding the nonoss
> >>flag
> >> and
> >> >    when it should be used?
> >>
> >> The non-oss flag is basically so that our default build does not pull in
> >> non ASLv2 compatible dependencies (as defined by the ASF legal folks).
> >> In the scenario that you describe, you are creating CloudStack code that
> >> will call a remote web service API, which means you are not adding a new
> >> dependency to the project.  Based on this, there's no reason that you
> >> would need your code to be in the non-default build (but we'll adjust as
> >> needed as you get further along).
> >>
> >> One point to note - Inclusion of the WSDL in our code may be
> >> questionable.  Inclusion of proxy class files generated from that WSDL
> >> should not be a problem.
> >>
> >> > Also, I do not have permission to assign the New Feature issue I
> >>created
> >> in
> >> > Jira to myself, so if someone could do that for me that would be great
> >> > (link is in the spec).
> >>
> >> You have permission now.  Give it a shot!
> >>
> >> -chip
> >>

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message