Job Policy Examples

This section provides policy examples for granting users permissions on job resources.

Note the following:

• To allow linking between two jobs, there must be a permit link claim on both the source job and the destination job.
• To allow a job to bind to a service, there must be a permit bind claim on both the job and service.
• To allow a job to join a virtual network, there must be a permit join claim on both the job and the network resource.
• See also the package resolution policy example.
• Job promotion requires permission on the job and the gateway resources.

Available permissions for job resources

The following system policy defines all permissions available for resources in the job::/ realm and its descendants.

job::/ {
  if (permit == all) {
    permit create, read, update, delete
    permit start, stop, map, ssh, link, promote, bind
  }
}

Policy example

The following policy grants all allowable permissions to the named user tom on job resources in the /sandbox/tom namespace (in other words, on resources in the job::/sandbox/tom realm).

job::/sandbox/tom {
  if (auth_server@apcera.me->name == "tom") {
    permit all
  }
  if (permit == all) {
    permit create, read, update, delete
    permit start, stop, promote
    permit map, link, bind, ssh
  }
}

The following policy grants only CRUD permissions to a named user on job resources in the sandboxed namespace. The policy identifies the user by the username that is assigned by policy on the Auth Server resource when the access token is created.

job::/sandbox/bob {
    if (auth_server@apcera.me->name == "bob") {
        permit create, read, update, delete
    }
}