[Enhancement] Security model / Whitelist / ACL?

[HSPDev]

Hello, Nice project, I really like the UI, and I want to help out as this will be a nice fit for our infrastructure.

One thing that I've noticed however is that because of the clustering, we have a "full trust model" - If you have the 128 bit key used for encryption and/or access to Consul/etcd, you have full access to run jobs across the cluster. If you compromise a webserver, you suddenly have shell access to the entire datacenter!

Of course you can use a limited / chroot user to run dkron, but I'm a firm believer in security in depth. Other projects have these security systems in place to try and keep some level of control, but the only alternative for dkron is to run one scheduler with unique keys pr. tier; that's a PITA.

Examples of security features:

• Nomad.io has full blown ACL policies across the cluster, that can allow/deny access to schedule, edit, and view jobs based on individual server tokens.
• Your go-based cousin Cronsun (https://github.com/shunfei/cronsun) has a "security" feature where it can allow only execution of some extensions. I really like this approach, but their implementation seems broken as they only do a string match and I'm 99,9% sure you can escape it by using shell escapes or other shell features.

To sum it up, I like the simplicity of Dkron (almost automatic clustering, no backend stores needed), simple to use etc. but it would be nice to have a whitelisting feature on individual servers only allowing one or more of the following.

• Specific scripts
• Scripts in certain directories (resolved with realpath ofc)
• Scripts ending with certain whitelisted extensions (.dkron.sh or .cron.sh etc.)

I'm currently working on a patch for internal use, but would like to know if the maintainers of this project are interested in having these (core) extensions merged upstream.

[vcastellm]

@HSPDev thanks for your comments.

You're right, Dkron is now implemented to be used in a trusted environment, delegating security to external measures, aside from the encryption key for clustering.

It's an interesting feature to have, let's see this patch so I can evaluate if it will fit upstream.

[HSPDev]

@victorcoder I'll be back sometime.. I need to test and evaluate it as Golang is not my main language and I dont want to waste your time. The trick is that we'll have to find a way to make sure that we are ONLY executing a certain command and not interpreting any command line arguments as that could lead to a shell escape. I've also considered the ability to just sign the scheduled job with a private key (Think PKI) but that's probably reserved for internal scope for now.

[vcastellm]

This features will be included in the commercial version

[HSPDev]

@victorcoder Sounds great, can I subscribe for updates somewhere?

We ended up going for a native scheduler (Laravel Schedule) with a centralized locking infrastructure (Redis backed) for firing cron - managed by Ansible - over dkron, due to some weird issues we had in prod, but would definitely go back and look again, especially if there will be paid support. :)