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;
  • enableenable/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.

Seperation of duties - team 1

Seperation of duties - team 2

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.

Seperation of teams - team 1

Seperation of teams - team 2

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.

Seperation of environments - team 1

Seperation of environments - team 2