feat: add simple Firewall design #114
Conversation
sergeymatov
force-pushed
the
pr/smatov/firewall-api-propoasl
branch
from
873a289 to
f08bdd5
Compare
sergeymatov
force-pushed
the
pr/smatov/firewall-api-propoasl
branch
from
f08bdd5 to
8f8729f
Compare
sergeymatov
changed the title
sergeymatov
force-pushed
the
pr/smatov/firewall-api-propoasl
branch
from
8f8729f to
ad10042
Compare
Signed-off-by: Sergey Matov <[email protected]>
sergeymatov
force-pushed
the
pr/smatov/firewall-api-propoasl
branch
from
ad10042 to
1f6aae8
Compare
There was a problem hiding this comment.
I note that the concept is very close to K8s' Network Policies. Have we considered making our API closer to these? I do understand they're different objects, but users might find the syntax easier to remember if they're already familiar with it?
One point in particular is that we currently define CIDRs under tcp -> src, for example; but it seems to me like it's more frequent to define access to multiple services for a given IP or CIDR, so this may lead to some duplication of the CIDRs involved. Wouldn't it make more sense to specify the CIDR first, then for this CIDR, to specify the protocol?
| ## Simple firewall implementation | ||
| VPC Firewall implies zero trust if firewall pattern is specified. |
There was a problem hiding this comment.
Do I understand this right?:
- No
firewallpolicy specified: all traffic allowed allowpolicy specified: all traffic denied, save for allowed patternsdeny-only policy specified: all traffic deniedallow+denypolicies: traffic not matching allowed patterns is denied; traffic matching allowed patterns is allowed, except if it's explicitly denied by thedenypolicy, which always takes precedence
Is this correct?
There was a problem hiding this comment.
Yes. If there is deny only policy specified, allow should be added for any other traffic.
Also, order is defined by order in the API message.
There was a problem hiding this comment.
Yes. If there is
denyonly policy specified,allowshould be added for any other traffic.
Sounds good to me, thanks!
Also, order is defined by order in the API message.
This is more concerning to me. It sounds super-easy to enable by mistake the traffic you specifically wanted to deny, because a user didn't understand the significance of the order, or they got confused and mentally swapped the order, or did a copy-paste error and put the deny policy at the wrong place. Are we sure we need to nest multiple levels of allow and deny policies? Wouldn't a single level of allow + a preceding level of deny be safer (and easier) to use?
No description provided.