A very basic admission controller for Kubernetes that denies all network policies. It works as a validation webhook and can be used to prevent users from creating network policies. This is especially useful in multi-tenant clusters where you want to prevent users from creating network policies that might affect other users, or (like in my case) in environments where you exclusively rely on Istio AuthorizationPolicies.
See the full changelog here
See the README for the Helm Chart for more information.
This controller is very lightweight and does not consume a lot of resources. To give you a few key values, here are some numbers:
| CPU | Memory | Container Size | Load Test |
|---|---|---|---|
| 0.005 Cores | 5-10Mi | about 10MB | 1000 req/s delivered by single Pod: avg 1.83ms, min 149µs, max 700ms, p95 3.58ms |
If you want to deploy kube-networkpolicy-denier locally, you can use the provided Makefile to spin up a Minikube cluster, build the container image yourself and deploy the controller to your cluster:
make localThese instructions will get you a copy of the project up and running on your local machine for development and testing purposes.
Things you need to install the software from source:
- Go - The programming language used
- Docker - Containerization
- Kubernetes - The container orchestration system used
- This controller was tested on a Kubernetes 1.27.4 cluster, but should work on any Kubernetes cluster that supports admission webhooks in version
v1. For instance, you can use a Minikube cluster for local development.
- This controller was tested on a Kubernetes 1.27.4 cluster, but should work on any Kubernetes cluster that supports admission webhooks in version
- Helm (v3) - The package manager for Kubernetes, needed to deploy the chart.
A step by step series of examples that tell you how to get a development environment running.
If you want to get started locally fast, you can use the Makefile to generate self-signed certificates and start the server locally:
make ssl
make runIf you want to work in a containerized environment to prevent pollution of your machine, you can use the provided Dockerfile to build a container image and run it locally:
make devFrom this running container on, you can proceed and build everything.
Contributions are very welcome. I am happy to accept pull requests or issues. Please stay respectful. I don't plan on adding a code of conduct, but please be nice.
This project is licensed under the MIT License - see the LICENSE file for details. Basically, you can do whatever you want with this project, but you have to include the license and the license notice. And if you break something while using this piece of software or anything around it, I'm not responsible for that.
This project uses a mixed approach for versioning.
The version of the Helm Chart uses Semantic Versioning.
The version of the controller Docker image uses the short git commit hash of the commit that was used to build the respective image. A newer build of the image will always have a newer commit hash.
A newer build is not guaranteed to make it into a new release of the Helm Chart. This is mostly due to the fact that not every change to the controller is relevant for a release of the Helm Chart or not releasable at all. Anyway, you are free to use any version of the controller image with any version of the Helm Chart. Although, it is recommended to use the controller image version which is referenced in the appVersion field of the Helm Chart. A image version that has not been referenced in a Helm Chart version is not guaranteed to work as expected.
I tested this Helm Chart in multiple Kubernetes v1.27 (and upwards) clusters. According to the Kubernetes API Version Guide, the API that was introduced the last was autoscaling/v2 since Kubernetes v1.23. This means that this Helm Chart should work with Kubernetes v1.23 and above and can be recommended.
If you want to use this Helm Chart with a Kubernetes version below v1.23, you will need to disable the HorizontalPodAutoscaler by setting the autoscaling.enabled field in the values.yaml file to false. If you do so, you should be able to run the Helm Chart with any Kubernetes version above (and including) v1.16. However, this is not recommended because I did NOT test with Kubernetes v1.16 and I can't guarantee that everything will work as expected in the long run. (v1.16 was EOL in 2020, please upgrade your cluster if you are still using it.)