DROP vs REJECT for rules

[zetsub0u]

Hi,

Quick question, I don't see a way to set the policy for the rules from DROP to REJECT (silently drop vs quick RST), is this accurate? If so, any reason why this isn't configurable and would it be acceptable PR?

Thanks.

[lwr20]

Its always been DROP, mostly because in the firewall world, its a bad idea to let people know that the IP address has a host behind it, and to slow down their reconnaissance of your hosts.

What's your use case for REJECT?

[zetsub0u]

I know and i agree completely, but we've had our firewalls do REJECT for years, on our custom implementation in docker and after that with kube-router (they do REJECT too) and when we switched to DROP with calico a lot of users started complaining because they used the behavior of the quick connection refused to debug network policy issues for example. We are trying to convince them it's better to go DROP but we might lose the battle, so i was wondering if having the option somewhere would be an acceptable change.

[lwr20]

This almost got added previously: https://github.com/projectcalico/felix/pull/2161/files

[olljanat]

Any update to this one? Our use case is that we want to go zero trust kind of architecture where we block all connections between namespaces are blocked by default and REJECT is just more clear for those who are trying to debug why some of needed connections fails.

Example I'm new with Kubernetes and just wasted couple of hours because I though that there was some routing, etc issue on my Kubernetes/infra setup before remembered that there is also that default network policy which blocks everything...

[rowanj]

Just like to add that we'd also like to create REJECT policies - the network policies we enact are intended to ease the UX of our developers and operators by making the security boundaries clear. DROP rules just cause a higher debugging and support load because of the number of situations that can result in a connection stalling forever.

i.e. a pod in our cluster is assumed to have a high degree of knowledge about available services and endpoints, we want a quick and relatively clear feedback cycle on the attempted use of something which has not been allowed in the current scope; so that the appropriate configuration change or access request can be made.

[lwr20]

I'm afraid this hasn't made it to the top of the core team's list yet.

Does anyone here fancy taking over https://github.com/projectcalico/felix/pull/2161 ?

[olljanat]

Btw. I looks to be that https://github.com/projectcalico/felix/pull/2532 already added support for REJECT at least on some parts of code https://github.com/projectcalico/felix/blob/87c68a8b66f6a57170a3ab5084c8c7b66baacdd4/iptables/actions.go#L89-L99 but not sure (at least yet) that what is actually still missing.

[olljanat]

@lwr20 any possibility to get this to core team list or at least get some guidance that what would be right way and place to implement this one?

[lwr20]

@caseydavenport is the core team lead - perhaps he can comment?

But my understanding is that https://github.com/projectcalico/felix/pull/2161 was pretty close, just the the author moved to a new employer who didn't permit OSS contributions without permission.

[caseydavenport]

Yep. I think we're still looking for someone from the community to pick this thread up. I agree the last PR was close - probably needed some work on the tests mostly.

[olljanat]

Ok. Created PR #5735 based on code from https://github.com/projectcalico/felix/pull/2161 and added initial set of tests for now and will try to working with it when I have spare time.

[olljanat]

Status update. #5735 have been there for a while and should contain most of the needed logic.

However it looks that I will need help from someone who know this codebase better to understand that why make test in felix folder fails? For me it looks that felix does not actually read DropActionOverride setting value even when it is configured.

EDIT: Finally found where I have made mistake in tests (DropActionOverride value must be in capital letters REJECT instead of Reject on tests).

[olljanat]

Status update. #5735 have been ready for code review about one month now. I only have rebased it time to time when other merged PRs has required it.

[james-callahan]

While #5735 is merged, it's not quite what I wanted/expected with this issue. I was hoping that action in a Rule would gain a Reject value which could be used instead of Deny.

[caseydavenport]

Updated the title to represent the remaining request scope