As I understand, the primary users of policy tools are platform teams, infrastructure teams, or some other entity who needs to able to create, manage, and enforce policies over domains that they're responsible for.
When I look at Datree from the POV of a platform team, I see a tool that I must trust dev teams to use to enforce policies.
Yes, I can hide my K8s cluster behind a CI/CD pipeline that runs Datree, but this is limiting for organizations that actually want to let its dev teams access its K8s clusters directly or run workloads that themselves can create K8s resources (e.g. operators).
By contrast, OPA Gatekeeper or Kyverno do not have such limitations because they allow policies to be enforced at the cluster itself.
Both also allow platform teams to create new policies and detect if there are any K8s resources _already_ in the cluster that are in violation of the new policies (i.e. Day 2 operations).
Lastly, both even offer CLI tools for dev teams to use to detect issues earlier during development.
I would argue though that dev teams are actually secondary to platform teams in terms of who to focus on when building policy tools since platform teams usually have more of an interest/responsibility in enforcing policies and therefore more of a say in what policy tools to adopt for an organization.
Hence, I was curious why you started with a CLI tool which seems to be more of a dev-centric approach rather than platform-centric.
Also, more specifically, what makes Datree a better option over OPA Gatekeeper or Kyverno?
My contrarian view is that EC2 + ASG is so pleasant to use. It’s just conceptually simple: I launch an image into an ASG, and configure my autoscale policies. There are very few things to worry about. On the other hand, using k8s has always been a big deal. We built a whole team to manage k8s. We introduce dozens of concepts of k8s or spend person-years on “platform engineering” to hide k8s concepts. We publish guidelines and sdks and all kinds of validators so people can use k8s “properly”. And we still write 10s of thousands lines of YAML plus 10s of thousands of code to implement an operator. Sometimes I wonder if k8s is too intrusive.
Lifting and shifting an "EC2 + ASG" set-up to Kubernetes is a straightforward process unless your app is doing something very non-standard. It maps to a Deployment in most cases.
The fact that you even implemented an operator (a very advanced use-case in Kubernetes) strongly suggests to me that you're doing way more than just lifting and shifting your existing set-up. Is it a surprise then that you're seeing so much more complexity?