Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Disable network_policy by default again #804

Closed
ghost opened this issue Jan 31, 2021 · 4 comments · Fixed by #809
Closed

Disable network_policy by default again #804

ghost opened this issue Jan 31, 2021 · 4 comments · Fixed by #809
Labels

Comments

@ghost
Copy link

ghost commented Jan 31, 2021

First of all: thanks to everyone who is working actively on this repo to improve and maintain it! Keep up the great work!

I'm suggesting to disable the network_policy option by default again, reverting PR #356 (linked to issue #138).

I understand that the CIS GCP Benchmark recommends this policy to be enabled, but this option causes an overhead that can't be neglected in my opinion. As documented by Google, this option increases the memory footprint by approximately 128 MB and requires approximately 300 millicores of CPU. Because of this, it is no longer possible to run all kube-system pods on a single e2-small or e2-medium instance. Instead, you need at least 2 e2-medium instances, and Google's documentation even recommends 3 e2-medium instances.

This overhead could be acceptable if it would improve the security out-of-the-box, but this option does not contribute anything to the security of your system as long as it's not configured. I'm sure that a lot of users don't know that this option is enabled by default, which means they will probably not configure the network_policy, resulting in 300 mCPU and 128 MB of wasted resources (and as previously explained, probably also a wasted VM instance).

I would finally also like to add that the network_policy option is not enabled by default when a Kubernetes cluster is created through Google Cloud Platform console.

Given all these arguments, I feel like the cons outweigh the pros of enabling the network_policy by default. I actually feel like there are no real pros for this feature, since users who are planning to use the network_policy feature will probably inform themselves on how to enable it within this module. It also makes more sense that users who are not aware of this feature or don't want to use it, don't need to do anything. (In contrast to the current situation where this last category of users is probably experiencing the described overhead without realising it.)

Thanks for taking this suggestion into consideration! I'm more than happy to create a PR if this gets approved.

@morgante
Copy link
Contributor

morgante commented Feb 1, 2021

In general, we do try to use more secure options by default. Using network policies is more secure, but you rightfully point out that's only true if they're actually configured.

A reasonable compromise might be to disable them by default on the "normal" modules but leave them on in the safer-cluster module.

@ghost
Copy link
Author

ghost commented Feb 1, 2021

Thanks for your answer @morgante ! I agree with you that this is something that would be suitable for the safer-cluster module, thus leaving PR #315 intact.

There's currently not even an option/input to deactivate it in the safer-cluster module. I do see that there is a code comment documenting that enabling the network policy is not sufficient to enforce restrictions. It would probably be nice to also add this comment somewhere in the safer-cluster module README to inform users about this. This way, users will be made aware of the fact that this option needs to be configured and will probably do it (since they did choose for a safer cluster in the first place).

@morgante
Copy link
Contributor

morgante commented Feb 1, 2021

Agreed, we should document the additional setup/recommendation in the README.

@ghost
Copy link
Author

ghost commented Feb 3, 2021

I opened a PR to change the default value of network_policy to false again.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
1 participant