*** SridarK has quit IRC | 03:05 | |
*** yamamoto has quit IRC | 06:17 | |
*** yamamoto has joined #openstack-fwaas | 06:20 | |
*** yamamoto has quit IRC | 07:08 | |
*** yamamoto has joined #openstack-fwaas | 07:21 | |
openstackgerrit | Merged openstack/neutron-fwaas master: Convert policy.json into policy-in-code https://review.openstack.org/527282 | 08:06 |
---|---|---|
*** velizarx has joined #openstack-fwaas | 08:41 | |
*** velizarx has quit IRC | 10:01 | |
*** velizarx has joined #openstack-fwaas | 10:10 | |
*** yamamoto has quit IRC | 10:23 | |
*** yamamoto has joined #openstack-fwaas | 11:09 | |
*** yamamoto has quit IRC | 11:14 | |
*** yamamoto has joined #openstack-fwaas | 12:05 | |
*** yamamoto has quit IRC | 12:12 | |
*** yamamoto has joined #openstack-fwaas | 13:03 | |
*** yamamoto has quit IRC | 13:11 | |
*** yamamoto has joined #openstack-fwaas | 14:08 | |
*** velizarx has quit IRC | 14:42 | |
*** hongbin has joined #openstack-fwaas | 15:01 | |
*** yamamoto has quit IRC | 15:12 | |
*** yamamoto has joined #openstack-fwaas | 15:35 | |
*** yamamoto has quit IRC | 16:08 | |
*** yamamoto has joined #openstack-fwaas | 16:13 | |
*** yamamoto has quit IRC | 16:17 | |
openstackgerrit | Merged openstack/neutron-fwaas master: doc: Add policy reference https://review.openstack.org/625407 | 16:18 |
*** velizarx has joined #openstack-fwaas | 16:41 | |
*** velizarx has quit IRC | 17:34 | |
*** velizarx has joined #openstack-fwaas | 17:51 | |
*** velizarx has quit IRC | 18:36 | |
*** yamamoto has joined #openstack-fwaas | 18:57 | |
*** yamamoto has quit IRC | 19:02 | |
*** hongbin has quit IRC | 22:02 | |
*** hongbin has joined #openstack-fwaas | 22:03 | |
*** mlavalle has joined #openstack-fwaas | 22:27 | |
mlavalle | hongbin: ping | 22:30 |
hongbin | mlavalle: pong | 22:31 |
mlavalle | let's give Sridar a few minutes | 22:31 |
hongbin | sure | 22:31 |
* mlavalle working on monthly report | 22:32 | |
* hongbin is doing more code review :) | 22:33 | |
mlavalle | that's good, keep doing that | 22:34 |
hongbin | :) | 22:34 |
* mlavalle pinging Sridar in Whatsapp to check if he is still to join us for conversation today | 22:45 | |
*** SridarK has joined #openstack-fwaas | 22:49 | |
SridarK | mlavalle: hongbin: hi | 22:50 |
SridarK | just got back sorry | 22:50 |
hongbin | SridarK: hi sridar | 22:50 |
hongbin | np | 22:50 |
mlavalle | hi there | 22:50 |
mlavalle | Thanks for joining us | 22:50 |
hongbin | let's begin | 22:50 |
SridarK | thx for meeting late in ur timezone | 22:50 |
SridarK | today morn was too crazy | 22:50 |
* mlavalle will have his exit interview in 10 minutes | 22:50 | |
SridarK | yes lets start | 22:51 |
SridarK | oh oh | 22:51 |
mlavalle | please continue without me. I'll re-join as soon as I can | 22:51 |
SridarK | mlavalle: ok no issues | 22:51 |
hongbin | mlavalle: ack | 22:51 |
SridarK | i think i stated my inputs in the email as well | 22:51 |
hongbin | so yesterday, we were discussing the pros and cons of both models | 22:51 |
hongbin | multiple policies VS multiple FWG | 22:51 |
hongbin | per my understanding, SridarK opinion is that the multiple policies model is easier to implement , which is the key point | 22:52 |
SridarK | yes | 22:52 |
hongbin | SridarK: is that correct? | 22:52 |
SridarK | hongbin: yes and the complexity in making a priority relationship across FWG | 22:53 |
SridarK | if there are a few ports in which there more than one FWG | 22:53 |
SridarK | FWG1 could be on Port1, Port2, Port3 | 22:54 |
SridarK | if we have FWG2 on Port3, Port4 | 22:54 |
SridarK | and some other FWG3 on Port1 and Port6 | 22:55 |
SridarK | we will need to manage the priority relationships across multiple FWG | 22:55 |
SridarK | and it can get a bit tricky | 22:55 |
hongbin | yes, i agree with that, the implementation could be a difficulty | 22:56 |
SridarK | Also if we were create a new FWG with a port that is already on a different FWG | 22:56 |
SridarK | now during validation we will need to enforce the priority | 22:56 |
SridarK | similarly on update cases - if we are updating the ports in a FWG | 22:56 |
hongbin | i assume the validation is hard to implement, right? | 22:57 |
SridarK | Today it is simplistic in that if we have a port that is already associated with a FWG we fail the validation or Create or Update | 22:57 |
SridarK | it is simplistic but also simpler to implement and no corner cases | 22:57 |
hongbin | ok | 22:58 |
SridarK | This is my main concern | 22:58 |
hongbin | so your arguement is more about the technical perspective about the implementation | 22:58 |
hongbin | however, i would argue that there is a buniness need for implementing that | 22:59 |
hongbin | (perhaps, not implement, but the model) | 22:59 |
SridarK | That definitely is the primary concern also IMO having another policy could be more efficient | 22:59 |
hongbin | in our case, we are hosting a public cloud, and there are lots of users, vms, FWGs | 22:59 |
hongbin | and we are evaluating two models about how easy the cloud operators manage the FWG | 23:00 |
SridarK | I think as long as we are unique to a port - we shd be able to use different FWG today without any change | 23:00 |
hongbin | yes, i agree | 23:01 |
SridarK | are u also evaluating chargeback, billing for resources ? | 23:01 |
hongbin | maybe just a simpler scenario | 23:01 |
hongbin | for example | 23:01 |
SridarK | Also i am not being religious abt this at all - | 23:02 |
SridarK | the priority stuff can get very tricky hence my concern | 23:02 |
SridarK | Also if we can achieve ur objectives with as minimal code change - the better | 23:02 |
hongbin | a cloud operator manage a FWG and want to trace back to the list of VMs of this FWG | 23:02 |
hongbin | and add/remove VMs from a FWG | 23:03 |
SridarK | ok | 23:03 |
hongbin | in the model of multiple policies, it is difficult to do that | 23:03 |
SridarK | These VMs will be on different ports | 23:04 |
hongbin | but most VMs just have one port | 23:04 |
SridarK | In which case i believe there is no issue | 23:04 |
SridarK | I am thinking the Port the VM plugs into | 23:04 |
SridarK | the neutron port | 23:04 |
hongbin | sure, we can assume VM-port is one-to-one mapping | 23:05 |
SridarK | each VM is plugged into a neutron port | 23:05 |
hongbin | yes | 23:05 |
SridarK | and we apply the FWG on this port | 23:05 |
hongbin | we apply FWG to this port, only at creation time | 23:05 |
hongbin | let me clarify | 23:05 |
SridarK | ok | 23:05 |
hongbin | if using the multiple policies model, we apply FWG to port at creation time only | 23:06 |
hongbin | if using multiple FWG model, we can apply FWG to port at runtime | 23:06 |
SridarK | We can always update the FWG with a policy at run time | 23:07 |
hongbin | yes | 23:07 |
SridarK | which in essence is the same thing | 23:07 |
hongbin | then, the operator need to manage the policy, trace down the all the FWGs with that policy, then trace down to all ports with that FWG | 23:07 |
hongbin | so the path is police -> FWGs -> ports | 23:08 |
hongbin | however, in the multiple FWG model, it is FWG -> ports | 23:08 |
hongbin | which is easier to manage the relationship | 23:08 |
SridarK | Hmm sorry dont follow | 23:09 |
hongbin | ok, i will give an example | 23:09 |
SridarK | u still have the FWG -> ports relationship | 23:09 |
SridarK | and it will be a single FWG | 23:09 |
SridarK | and u can look up the policy on that | 23:09 |
hongbin | so there is a FWG1, Port1, Policy1 | 23:10 |
SridarK | ok | 23:10 |
SridarK | and VM1 is on Port 1 ? | 23:10 |
hongbin | yes | 23:10 |
hongbin | FWG1, Policy1 is the user-manged resource at the VM creation time | 23:11 |
SridarK | ok | 23:11 |
hongbin | FWG1, Policy1 is for the application | 23:11 |
hongbin | (user application) | 23:11 |
hongbin | then, in admin side, | 23:11 |
hongbin | there is FWG2, Policy2 | 23:12 |
hongbin | in the model of multiple policies | 23:12 |
hongbin | admin add Policy2 to VM1 | 23:12 |
hongbin | sorry, admin adds Policy2 (admin resource) to FWG1 (user resource) | 23:13 |
hongbin | for example, if a VM is compromise, admin adds/removs Policy to user's FWG | 23:13 |
hongbin | then, admin trace down from a policy, to a list of FWG, to a list of ports | 23:14 |
hongbin | is that correct? | 23:14 |
SridarK | So if the VM1 is compromised | 23:14 |
SridarK | we want to do something like a drop all on that port ? | 23:15 |
hongbin | yes, or drop a specific port | 23:15 |
SridarK | ok | 23:15 |
hongbin | (depending on the severity of the situation) | 23:16 |
SridarK | So u want the ablity to add a drop rule (in a Policy) (or as a FWG) on that port | 23:16 |
hongbin | then, in the muliple FWG model, if VM1 is compromise, admin adds/removs FWG2 to Port1 | 23:16 |
SridarK | which is a drop all | 23:17 |
SridarK | so even if FWG1 is on multiple ports | 23:18 |
hongbin | in precise, i want to add something (policy/FWG) to a port, which can drop all ports or a specific port | 23:18 |
SridarK | we want the ability to specify for a specific port | 23:18 |
SridarK | ok | 23:18 |
SridarK | FWG1 on Port1, Port2, Port3 | 23:18 |
SridarK | U want to be able to add FWG2 just on Port1 | 23:19 |
hongbin | yes | 23:19 |
SridarK | to drop all traffic for ex | 23:19 |
hongbin | yes | 23:19 |
SridarK | yes in that case it is easier to do that | 23:19 |
SridarK | the alternate is to remove Port1 from FWG1 | 23:20 |
SridarK | then we will go to a default drop all | 23:20 |
SridarK | and then add FWG2 to Port1 | 23:20 |
hongbin | yes, we can do that | 23:20 |
SridarK | which is more cumbersome | 23:20 |
SridarK | i agree | 23:20 |
hongbin | so we want a model that is easier for cloud operator to manage the things | 23:21 |
mlavalle | when you say cloud operator, that means the admin in the above examples | 23:21 |
hongbin | yes | 23:21 |
SridarK | The priority issues will be the problem case | 23:22 |
SridarK | I am just thinking out aloud | 23:22 |
SridarK | if we had the ability to enforce a port association for a policy | 23:23 |
SridarK | we dont do that today | 23:23 |
SridarK | but we also only support 1 ingress and 1 egress policy per FWG | 23:23 |
hongbin | what do you mean by "enforce a port association" | 23:24 |
hongbin | ok | 23:24 |
SridarK | If we are able to state FWG1: has multiple Policies | 23:24 |
SridarK | P1 & P2 | 23:24 |
SridarK | and if we are able to state P1 has priority 5 and is associated with Port1, Port2, Port3 | 23:25 |
SridarK | and we see that the VM on Port1 is compromised | 23:26 |
hongbin | yes | 23:26 |
SridarK | then we add the drop all Policy P2 with Priority 0(highest) and applied only to Port1 | 23:26 |
SridarK | on FWG1 | 23:26 |
SridarK | it will achieve what u need | 23:27 |
SridarK | and we can keep the notion of Priority within the FWG | 23:27 |
SridarK | again i am just quickly stating one possibile approach | 23:28 |
hongbin | so P1 is owned by user's tenant, and P2 is owned by admin's tenant? | 23:28 |
SridarK | yes | 23:28 |
hongbin | and user create a port with P1 | 23:28 |
SridarK | I can see what u need | 23:28 |
SridarK | the ability to do | 23:28 |
SridarK | but the priority will become the issue | 23:29 |
hongbin | perhaps, we can think of another way to replace the "priority" | 23:29 |
SridarK | or we will need to make some special priveleges for admin owned rule sets | 23:29 |
mlavalle | so your key concern is the management of the priorities accross FWGs | 23:29 |
SridarK | and make it very restrictive | 23:29 |
SridarK | yes | 23:30 |
SridarK | i think that is very tricky | 23:30 |
hongbin | i am still following what SridarK said above | 23:32 |
hongbin | could we order the list of FWGs in a list | 23:33 |
hongbin | right now, we order SGs in a list in the neutron port, right? | 23:34 |
hongbin | i imagine we could order FWGs in a list as well | 23:34 |
hongbin | (within the port) | 23:34 |
hongbin | then, the priority between FWGs will be decided by the list | 23:35 |
SridarK | but how do we order it ? | 23:35 |
SridarK | we will need another grouping | 23:35 |
hongbin | no | 23:35 |
SridarK | that is a group of FWG with an ordered list of FWG | 23:35 |
hongbin | Port1: [FWG1, FWG2, ...] | 23:36 |
hongbin | then, later, admin see the VM is compromise, it add FWG3 at the beginning | 23:36 |
hongbin | Port1: [FWG3, FWG1, FWG2, ...] | 23:36 |
SridarK | Meaning u want a change in neutron to the Port attributes ? | 23:36 |
* mlavalle just received call from HR person | 23:37 | |
hongbin | yes, that is one option | 23:37 |
hongbin | add FWG to port, is a port_update call | 23:37 |
SridarK | u will need neutron to support that | 23:39 |
SridarK | we dont have that today | 23:39 |
SridarK | or something like a port ext | 23:39 |
hongbin | yes, that can be extended by a api extension to neutron | 23:40 |
SridarK | we are now making a fundamental change to how FWaaS is deployed | 23:40 |
hongbin | no really | 23:40 |
hongbin | we can maintain the original behavior if the extension is not added to neutron | 23:41 |
hongbin | so, we can have an optional feature, that supports multiple FWG to port, as long as there is a certain API extension is enabled in neutron | 23:42 |
hongbin | again, that is just one option, we might have other implementation alternative | 23:43 |
SridarK | So we will have 2 ways of deplying FWaaS | 23:43 |
hongbin | yes | 23:44 |
hongbin | if it is too hard to maintain 2 ways to deploy FWaaS, we can deprecate one, and move to another | 23:45 |
SridarK | We just deprecated FWaaS v1 | 23:47 |
hongbin | yes :) | 23:47 |
SridarK | :-) | 23:47 |
SridarK | I would strongly suggest making incremental changes | 23:47 |
SridarK | easier to move fwd | 23:47 |
hongbin | sure, i think it is possible to do that | 23:47 |
SridarK | esp as the number of contributors is coming down | 23:48 |
SridarK | :-( | 23:48 |
hongbin | huawei will contribute the codes if they want to take this approach (i am not sure their opinion yet) | 23:49 |
SridarK | ok | 23:50 |
SridarK | My suggestion is to make some simpler steps fwd | 23:50 |
hongbin | sure | 23:50 |
SridarK | Having multiple policies is good for other use cases too | 23:51 |
SridarK | and then we can take step into multiple fwg if it is needed | 23:51 |
SridarK | i am open to making sure that we support all use cases | 23:51 |
SridarK | It will be great if Huawei can add more folks | 23:52 |
SridarK | Most of the Fujitsu folks have also moved on to other priorities | 23:53 |
hongbin | i see | 23:53 |
hongbin | i can definitely communicate with huawei about that | 23:53 |
SridarK | xgerman:, yushiro & myself are also pulled into other things and mostly doing this to keep things moving | 23:53 |
SridarK | that will be good | 23:54 |
xgerman | o/ | 23:54 |
hongbin | xgerman: so we were discussing an approach to add an attribute to the neutron port resource to maintain the list of FWGs | 23:55 |
hongbin | for example, Port1: [FWG1, FWG2,..] | 23:55 |
hongbin | in this way, we can avoid doing prioritaziation between FWGs, while allows multiple FWGs associate with a port | 23:56 |
* mlavalle just finished exit interview | 23:57 | |
hongbin | mlavalle: see the last comment i wrote to xgerman | 23:57 |
mlavalle | yes, I'm caught up | 23:57 |
SridarK | mlavalle: my suggestion is to make incremental changes | 23:58 |
mlavalle | I agree | 23:58 |
xgerman | mlavalle: Congrats to the new job!! | 23:58 |
hongbin | +1 | 23:58 |
mlavalle | SridarK^^^^ | 23:58 |
mlavalle | Thanks xgerman | 23:58 |
SridarK | mlavalle: yes congrats :-) | 23:58 |
mlavalle | Thanks everybody | 23:58 |
SridarK | But mlavalle's office does not change ;-) | 23:58 |
mlavalle | I'll still work the rest of the evening for Huawei, though | 23:59 |
mlavalle | nope same office | 23:59 |
SridarK | :-) | 23:59 |
hongbin | yes :) | 23:59 |
mlavalle | and really, same boss: my wife | 23:59 |
SridarK | mlavalle: ;-) | 23:59 |
hongbin | haha | 23:59 |
SridarK | And u forgot ur Beagle - he will upset now | 23:59 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!