-
intents-operator
Manage network policies, AWS, GCP & Azure IAM policies, Istio Authorization Policies, and Kafka ACLs in a Kubernetes cluster with ease.
However, if you want to control pod-to-pod communication, you might be better suited with managing network policies using ClientIntents, which let you specify which pods should communicate with which, from the client's point of view, and without requiring labels beforehand. It's open source, have a look at the intents operator here: https://github.com/otterize/intents-operator
-
CodeRabbit
CodeRabbit: AI Code Reviews for Developers. Revolutionize your code reviews with AI. CodeRabbit offers PR summaries, code walkthroughs, 1-click suggestions, and AST-based analysis. Boost productivity and code quality across all major languages with each PR.
-
You do still have to create a policy for every namespace, but don't have to worry about labeling individual pods. We're starting to move to Helm/kustomize for our namespaces to deploy default things like network policies to each one, and we're also starting to use kyverno more, which I think is a little more purpose built for this type of thing than metacontroller is.
-
Related posts
-
Can I create a NetworkPolicy with podSelector that matches a pod name instead of its labels?
-
Creating network policies for pods with services
-
otterize/intents-operator: Manage network policies and Kafka ACLs in a Kubernetes cluster with ease.
-
Show HN: Intents Operator, turns dev intent into K8s netpolicies and Kafka ACLs
-
Policy Management in Kubernetes with Kyverno