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

Feature Request: New Policy: Default Network Policy in All Namespaces except Namespaces in a given List #722

Open
Martin-Weiss opened this issue Apr 17, 2024 · 0 comments

Comments

@Martin-Weiss
Copy link

Martin-Weiss commented Apr 17, 2024

Is your feature request related to a problem?

Kubernetes does not support a global default network policy i.e. "deny all per default". Some CNIs implement this with custom CRDs (i.e. calico) - but this is CNI and cluster specific and in mixed environments can not be standardized.

Due to that we would need a way that creates a default network policy in each namespace that gets created.

Solution you'd like

A new kubewarden policy that allows to specify a default network policy that should be created including a list of namespaces that should be ingnored.

The default should be "deny all ingress" and "allow all egress" - but should be configurable.

The default exclustions should be "kube-system" and the CNI namespaces for calico, canal and cilium.

Alternatives you've considered

CNI specific global deny policies - but in mixed environments ( AKS, on premise RKE1 / RKE2 / K3S,...) we do not have the same CNI ans versions so we need to base this on kubernetes standards.

Another thought was to use the global CNI based deny policies and filter on labels on namespaces for the whitelist.. and then use a similar thing like the PSA label policy to deploy the right labels to the right namespaces

NeuVector might also be an alternative - but we need to add an additional product in that case..

Anything else?

No response

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: No status
Development

No branches or pull requests

1 participant