shimont

Seems cool, an open source alternative is always good to have

I've recently received an email from AWS about me running a deprecated EKS cluster with version 1.22 So I had to upgrade all of my clusters! So I've created this upgrade guide to EKS version 1.23 I Would love to hear your feedback and I hope this will help

woops! good catch! we will fix it - here are more policies https://hub.datree.io/built-in-rules

Initially as it is in read-only mode, there are no risks. But once you enable policy enforcement it will block non-compliant deployments to your cluster. Your organisation has to be ready for it, as it might block a developer trying to apply a hotfix.. you need to have the right mechanisms of enabling skips and escalating critical deployments, as any security tool i suppose

I agree, I dont know if it's a mental thing of feeling in control or really more convenient

I've created a basic index website https://crd.directory/

congrats on the launch.. What is the added value in using Permit as oppose to just implementing ABAC on top of OPA by myself? if I implement it using Rego policies they will be in Git and managed in a GitOps way with tracking changes etc.. Ofc I understand that you aim for the permissions to be as easy as for a monkey.. Do you offer a way of auditing and tracking who made changes to permissions?

Who uses FreeBSD those days? As a company that runs on the cloud, AWS/GCP/Azure you run windows/linux, and on desktop people mainly run MacOS/Windows/Linux.

I am really asking as for what is the main use case of FreeBSD in 2022?

Thank you Varchol :) Also you can use Helm which might help on top of Kubernetes manifests

We just released support for custom rules :) from interviewing our users, we decided to start with [0] JSON Schema as it is very easy to write rules using it and you do not have to learn rego.

Having said that, we might add OPA .rego support in the near future :)

What is the desired way for you to write custom policy rules?

[0] - https://json-schema.org/

Hey, this is a great question.

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 :)

I hope this answers your question Thank you

I know! I think that the fact that developers are dealing more and more with infra is very empowering but on the other hand brings new challenges. It is no longer Dev VS OPS, but now Devs also need to learn infra best practices, so tools like ours help them :) thank you for your Kudos! <3

The dashboard is also offered as part of our freemium offering :) we offer 1000 policy checks per month for free. Including the dashboard.

In terms of what we offer compared to Polaris: We offer pre-defined policies that comes out of the box along with the ability to write custom rules for your policy by your self.

Take us for a spin and let me know what you think! thank you

Hey, some of our friends were over eager to help hehe :)

I look forward to hearing your feedback! Thank you

Hey all, I am the author of the post, feel free to ask any questions you might have :)

I think that this is a great approach to test out the files. Mistakes in those files can cause a production outage. I like doing those tests once a PR is open and before it is merged into master and executed on the production cluster. (Disclaimer i am a co-founder of datree.io)

Will do! thanks

I totally agree! you should rotate the keys! we explain how to get rid of it in terms of Git. This is in addition to rotating it. Sorry for not being clear

We educate our customers on how to delete the branch and remove it from history: https://docs.datree.io/docs/do-not-include-secret-files

Currently, we support GitHub and working on releasing our support for GitLab and BitBucket. We plan on running on top of existing git hosting solutions

We are actively working on supporting GitLab and BitBucket. Once it is GA we will update you :)

Initially, we started as a CLI tool, but as you said, it is part of the problem, how do you make sure all of your developers are using the CLI/pre-commit hooks?

This is why we choose to integrate on the pull-request level. It is not perfect, but at least your plain text secrets will not be merged into master and go in onto your developer's laptops and your servers(less). :)

We try to find a balance between perfect and achievable in an easy way for our customers

I would love to hear more about your experience! could you please email me at Shimon [AT] Datree IO?

I believe that now is the right time for a solution like Datree. I think so because of the way we develop software has evolved, companies moved from Waterfall into Agile, there is developer autonomy and the move towards distributed micro-services has brought many companies to the reality of having hundreds and thousands of git repositories, each one with its own configuration files for CI, Docker, Kubernetes, etc.. its really hard managing all of those distributed pieces :)

Most companies we see try to implement something by themselves. pre-commit hooks is a major problem as it requires all the developers to install them on their computer, which is part of the problem itself right? aligning the dev team :)

Your unit tests and integration tests should still run using your CI. We run tests around the git and structured files

Hey :) Here are several examples of custom rules:

* Verify that CI configuration includes running certain jobs (e.g. third-party packages scanner).

* Ensure that all Docker containers are using a pinned down tag and not "latest"

* Verify that every commit is tied to an issue tracker (e.g. JIRA) ticket for traceability.

Every policy can be edited and tweaked to your use case using our engine and Regex. In addition, you can use our dashboard to view all executions

You might call it that in a way. This is where the engine is hooking. We scan the entire source control and curate rules for you to use around technologies

I think that what works for companies like Uber/Google/Facebook is not applicable to the rest of fortune 500 or all of the rest of the companies.

disclaimer: I am one of Datree.io founders. We provide a visibility and governance solution to R&D organizations on top of GitHub.

Here are some rules and enforcement around Security and Compliance which most of our companies use for multi-repo GitHub orgs. 1. Prevent users from adding outside collaborators to GitHub repos. 2. Enforce branch protection on all current repos and future created ones - prevent master branch deletion and force push. 3. Enforce pull request flow on default branch for all repos (including future created) - prevent direct commits to master without pull-request and checks. 4. Enforce Jira ticket integration - mention ticket number in pull request name / commit message. 5. Enforce proper Git user configuration. 6. Detect and prevent merging of secrets.