Control built in
BeyondCron is built from the ground up with controls in place to support the separation of duties, teams and environments.
Underlying controls
Underlying controls within BeyondCron are sophisticated and exhaustive.
User and role ACLs
Roles are equivalent to operating system groups. ACLs grant entitlements on jobs/calendars & groups (of jobs/calendars), to users and roles, as with UNIX. Each ACL has an associated user/role and permission list.
Supported permissions are:
- read – view groups, jobs and calendars;
- execute – execute jobs. read permission is not required if you know the name of the job;
- enable – enable/bypass/disable jobs;
- write – create/modify/delete jobs/calendars, and view private properties;
- admin – create/modify/delete acls below the group/directory where ACL is applied
Multiple ACls can be applied to a name or group.
Host ACLs
Host ACls are similar in function to UNIX netgroups, and are attached to users/roles. By default a user can only create jobs that execute as themselves, on any server. Host ACLs allow you to define the user and host access entitlement via globs or regex’s user-host patterns. e.g. www@dev* could be attached to a developer role, to allow developers to create jobs that run as www on development servers.
Protected users/hosts
In order to protect against bad/wide host ACls, users and hosts can be defined as protected. Once protected, a host ACL only applies if the protected user/host is exactly defined. For example root, bc-daemon and localhost are protected by default, as such a host ACL of root@localhost is required to define a job that runs as root on localhost. A host ACL of *@localhost, root@* or r*@local* would all fail.
root is protected for obvious reasons, localhost is protected because it could be any host running a BeyondCron agent, whilst bc-ademon is protected to protect BeyondCrons’ configuration and data.
Sudo
Whenever BeyondCron executes a job as a user other than itself, it uses sudo. Providing a layer of protection completely independent of BeyondCron.
Root
BeyondCron refuses to run as root, and only accepts connections from agents running under the same os user.
Separation of duties
In a typical development/uat/production environment, separation of duties is required. By assigning users to roles, and applying Access Control Lists (ACLs) to each role, BeyondCron makes it simple to provide different teams with only the permission required to perform their duties.
| Permission | Access |
|---|---|
| Read | View jobs and their history. |
| Execute | Start/stop jobs. |
| Enable | Enable, disble and bypass jobs. |
| Write | Create, modify and delete jobs. |
Separation of teams
Using roles and ACLs, is also easy to provide complete separation of teams jobs. For example, HR and IT.
Separation of environments
With the addition of host ACLs, it is simple within BeyondCron to assign servers (and users) on which teams can define their jobs to run. For example, developers may be able to define jobs for controlling development, but not production, web servers.
