As someone who works in a similar space (K8s configuration management and IaC), I'm curious what drove you to develop a CLI tool for enforcing policies as opposed to something that is able to integrate with K8s more closely such as OPA Gatekeeper or Kyverno?
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?
We are big believers in "shift-left" and trying to fix/avoid issues as early as possible.
We started with a CLI tool as it is agnostic and can be run in the devs IDE like VSCODE, in the terminal and finally in the CI/CD process.
We love OPA and think that GateKeeper is a good solution, but we want to provide feedback as early as possible. While Gatekeeper will block a deployment to the Kubernetes cluster at the end of the development process.
As a developer myself I would rather be notified for an issue as early as possible and not find our about it in the very last second before it goes live to production.
We might add support similar to GateKeeper in the future, but we wanted to be shift-left first :)
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?