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:

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.

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.