intents-operator VS credentials-operator

No more! The open-source intents-operator and credentials-operator enable you to achieve the same, except without all that work: do it all from Kubernetes, declaratively, and just-in-time, through the magic of IBAC (intent-based access control).

As you've mentioned, it is not possible to define deny rules using the native NetworkPolicy resource. Instead, you could use your CNI’s implementation for network policies. If you use Calico as your CNI you can use Calico's network policies to create deny rules. You can also take a look at Otterize OSS, an open-source solution my team and I are working on recently. It simplifies network policies by defining them from the client’s perspective in a ClientIntents resource. You can use the network mapper to auto-generate those ClientIntents from the traffic in your cluster, and then deploy them and let the intents-operator manage the network policies for you.

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

You can try it out by installing an open source, standalone Kubernetes operator that implements them using network policies - https://github.com/otterize/intents-operator

Hi! I'm Tomer, the CEO of Otterize - a cloud-native open-source tool that makes secure access transparent for developers with a declarative approach to service-to-service authorization. Otterize allows you to automate the creation of network policies and Kafka ACLs in a Kubernetes cluster using a human-readable format. Just declare which services your code intends to call using a Kubernetes custom resource, and access will be granted automatically while blocking anything else. Give it a try! It's free and takes 5 min to get started. https://github.com/otterize/intents-operator

You can use https://github.com/otterize/intents-operator to easily configure network policies using only pod names by specifying logical connections (a->b, c->b), and the operator configures network policies and labels for cluster resources automatically.

I'm very passionate about this as I think cybersecurity and ops people lean too far into control -- controlling people, that is, not just programs, and they end up shooting themselves in the foot. Instead, I think you should make it easy for devs in your team to create the right access controls, and that this is the only way to achieve zero trust. Zero-trust inherently relies on all access being intentional and authorized, so if other engineers don't declare which access their code needs, it's impossible to achieve. There's an open source Kubernetes operator that aims to get this concept right with network policies and Kafka ACLs - make it easy for one person to declare which access is intentional and start rolling out zero trust using network policies, and have the access control policy live alongside the client code. Check it out at https://github.com/otterize/intents-operator. Full disclosure - I'm one of the contributors, so I'm a bit biased ;) I'm there on the Slack, so feel free to hit me up (Ori).

Hi all, I’m Tomer @Otterize. We just launched an open-source tool to easily automate the creation of network policies and Kafka ACLs in a Kubernetes cluster using a human-readable format, via a custom resource. Check it out - https://github.com/otterize/intents-operator

No more! The open-source intents-operator and credentials-operator enable you to achieve the same, except without all that work: do it all from Kubernetes, declaratively, and just-in-time, through the magic of IBAC (intent-based access control).

Otterize Credential Operator ( https://github.com/otterize/credentials-operator ) helps you automatically provision credentials as Kubernetes secrets (using a self-hosted SPIRE or a free SaaS solution). You can use pod annotations to determine the certificate's domain names (as well as many other properties). I think it is a straightforward approach to managing trust, especially for a relatively small cluster where you manage everything. (Full disclosure: I am one of the contributors to this project)

Have you taken a look at using SPIRE to create the TLS certificates and attesting about the workload identity? You could couple SPIRE server with the Otterize SPIRE integration operator to declaratively generate TLS certificates. This could be easier to deploy than a service mesh and sidecars, depending on your use case - what the clients are and what the servers are.

You could create JWT or mTLS-based identities, and then verify those in your middleware. If you are on Kubernetes, you might try using SPIRE together with the SPIRE integration operator to automatically issue identities as Kubernetes secrets, which you could then use to connect between services.

In practice, the technical part is implemented by the DevOps/platform team. The way in which you declare and get access to these secrets varies, but can be one of the cloud provider secret managers (e.g. AWS Secret Manager), Hashicorp Vault, or if you're on Kubernetes, could be something like cert-manager, Hashicorp Vault sidecars, or SPIRE coupled with the Otterize SPIRE integration.

If this seems a bit complicated, you could use SPIRE server to issue certificates and Otterize SPIRE integration operator to renew them in Kubernetes and update Secrets.