Role Asssignment Policy Example

You use policy to create roles and map permissions and users to roles. The flexible policy langugage lets you create roles for multiple environments in a cluster and grant permissions to specific roles in those environments.

To define a role, you use the role claim type and a user-defined string for the value. The claim issuer is the policy engine. See Policy Syntax for details.

Single environment example

To add new roles for a single environment to your cluster, typically you will create a policy called roleMembership.pol that maps users to roles.

See the default role permissions policy for an example of this. This policy defines the admin role and assigns full permissions on each resource type realm.

Multi-environment example

If you are creating roles for multiple environments, a common scenario is having dev, test, and prod environments with admin, developer, qa (quality assurance), and auditor as the roles with varied permissions in those environments.

Typically, these roles have the following configuration:

Role Configuration
Admin Users in this role can administer all aspects of an Apcera cluster.
Developer Users in this role can create and manage apps and services in their dev environment.
QA Users in this role can create and manage apps and services in their test environment.
Auditor Users in this role have read-only access to all entities in the Apcera cluster.

This example creates dev, test, and prod environments with the above role configuration. Use <role>Permissions.pol to list the roles and their mapping to permissions for realms in multiple environments. Use <role>Membership.pol to map users to roles.

Document Namespace Description
adminMembership.pol /prod Users in the admin role.
adminPermissions.pol /prod Permissions in all environments for the admin role.
developerMembership.pol /dev Users in the dev role.
developerPermissions.pol /dev Permissions in /dev for the dev role.
qaMembership.pol /test Users in the qa role.
qaPermissions.pol /test Permissions in /qa for the qa role.
auditorMembership.pol / Users in the audit role.
auditorPermissions.pol / Permissions in all environmentsfor the audit role.
shared.pol / Access to Apcera provided to stagers, packages, and other commonly used stuff

NOTE: The example policy documents below assume that you have already added users to the cluster.

adminMembership.pol

For every resource type except auth, add the following policy rule for each member of the admin role:

<resourceType>::/ {
  if (auth_server->name == <adminName>) {
    role admin
  }
}

adminPermissions.pol

For every resource type except auth, add the following rule to assign permissions to the admin role:

<resourceType>::/ {
  if (role == admin) {
    permit all
  }
}

developerMembership.pol

For every resource type except auth, add the following policy rule for each member of the developer role:

<resourceType>::/dev {
  if (auth_server@apcera.me->name==<developerName>) {
    role developer
  }
}

developerPermissions.pol

For every resource type except auth, add the following rule to assign permissions to the developer role, for example:

job::/dev {
  if (role == developer) {
    permit all
  }
}

package::/dev {
  if (role == developer) {
    permit all
  }
}

service::/dev {
  if (role == developer) {
    permit all
  }
}

route::/ {
  if (role == "developer" && job fqnMatch "job::/dev") {
    permit map
  }
}

qaMembership.pol

For every resource type except auth, add the following policy rule for each member of the QA role:

<resourceType>::/test {
  if (auth_server@apcera.me->name==<qaName>) {
    role qa
  }
}

qaPermissions.pol

For every resource type except auth, add the following policy rule to assign permissions to the QA role, for example:

job::/test {
  if (role == qa) {
    permit all
  }
}

package::/test {
  if (role == qa) {
    permit all
  }
}

service::/test {
  if (role == qa) {
    permit all
  }
}

route::/ {
  if (role == "qa" && job fqnMatch "job::/test") {
    permit map
  }
}

auditorMembership.pol

For every resource type except auth, add the following policy rule for each member of the auditor role:

<resourceType>::/ {
  if (auth_server@apcera.me->name==<auditorName>) {
    role auditor
  }
}

auditorPermissions.pol

For every resource type except auth, add the following policy rule to assign permissions to the auditor role:

job::/ {
  if (role == auditor) {
    permit read
  }
}

package::/ {
  if (role == auditor) {
    permit read
  }
}

service::/ {
  if (role == auditor) {
    permit read
  }
}

audit::/ {
  if (role == auditor) {
    permit read
  }
}

stagpipe::/ {
  if (role == auditor) {
    permit read
  }
}

sempiperule::/ {
  if (role == auditor) {
    permit read
  }
}

policy::/ {
  if (role == auditor) {
    permit read
  }
}

shared.pol

Lastly, add policy rules granting permissions to shared resources, for example:

package::/apcera {
  if (role == "developer" || role == "qa") {
    permit read, use
  }
}

package::/apcera/pkg/docker {
  if (role == "developer" || role == "qa") {
    permit create, update, delete
  }
}

stagpipe::/apcera {
  if (role == "developer" || role == "qa") {
    permit read, use
  }
}

gateway::/apcera {
  if (role == "developer" || role == "qa") {
    permit use
  }
}

job::/apcera {
  if (role == "developer" || role == "qa") {
    permit read
  }
}

service::/apcera {
  if (role == "developer" || role == "qa") {
    permit read, bind
  }
}

Role templating

Role assignment is often templates. See Templating Policy Example for guidance.