Open Stack

Hi 

Firewall policies can be implemented with security groups. 

You can create as many isolated networks and routers as you want so an
instance can be isolated in its own network ... but I prefer using
security groups and creating a network for service (kubernetes: master
network, minion project1 network, minion project2 network ...). 

When a server with ip 192.168.56.11 and MAC FA:16:3E:0F:67:90 is
created, this rule is added automatically with default kvm hypervisor: 

Chain neutron-openvswi-sbd739c19-e (1 references)
target prot opt source destination 
RETURN all -- 192.168.56.11 anywhere MAC FA:16:3E:0F:67:90 /* Allow
traffic from defined IP/MAC pairs. */
DROP all -- anywhere anywhere /* Drop traffic without an IP/MAC allow
rule. */

So you cannot set other ip address in port unless you set it with
something like: 

neutron port-update 37f2d07e-4133-478c-b50d-39068adc8c3f
--allowed-address-pairs type=dict list=true
ip_address=192.168.56.11,ip_address=192.168.56.22 

It can be useful to deploy a pacemaker cluster with a cluster IP
address. 

What other feature do you need? 

Jose Manuel 

El 2017-01-31 16:20, Cesar Benito Hernández escribió: 

> We currently have a cloud infrastructure meeting our own requirements. Let's focus on some Networking features (firewall, instances isolation, spoofing control). We are thinking about moving to OpenStack and when we focus on these Networking features, Neutron comes into play. We are currently using Vyattas for these networking features (firewall, instance isolation, spoofing control) and we would like to keep it as it is right now. Therefore, if we move to OpenStack we would like Neutron to orchestrate these Vyattas but these Vyattas would be installed/configured in an outter layer, out of OpenStack. A good comparison we find is Cinder. In Cinder you can configure your storage backend (this storage backend is an external "agent" to OpenStack) and the idea with this networking features would be the same (being able to configure in Neutron our firewall backend).
> 
> This is our desired scenario, and these are the questions that we arise. We would appreciate very much your feedback:
> 
> - We believe the current Neutron FWaaS does not meet our requirement. It's not able to "talk" to an external firewall "backend". Are we right?
> - In case FWaaS does not meet our requirements, we can think of implementing/modifying the Neutron source code. I don't know exactly what this implies, but if we are in the right direction, a new Neutron API set of methods would be needed. Do you think the OpenStack community would accept this change?
> - Again, if we are right, apart from changing the Neutron source code to make it able to "talk" to an external firewall, we would also need to implement the firewall driver that matches the new API set of methods with the corresponding methods of the vendor's API (in our case Vyatta). Are we right?
> 
> If you think this is a wrong forum to discuss all these questions, please, could you tell us another place to discuss all this?
> 
> Thank you very much for your help and attention. We appreciate it.
> 
> _______________________________________________
> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack [1]
> Post to : openstack at lists.openstack.org
> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack [1]
 

Links:
------
[1] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20170201/8ca05e41/attachment.html>