Service Gateway Policy Examples

Policy on the gateway resource type control service gateway creation and use. Service gateways are jobs that configure connections (binding URIs) between services and apps.

Policy on gateway gives requestors with a valid token access to gateways, which means promoting a job to a service gateway and using a gateway to create a service.

A service gateway is required for service creation. Users who will be consuming services need use permissions on the service gateway realm.

Gateway permissions

The following policy defines the permissions for resources in the gateway::/ realm and its descendants:

on gateway::/ {
  if (permit == all) {
    permit promote
    permit use
  }
}

Gateway permission examples

The following policy lets a user with a valid access token use and promote service gateways in his or her namespaced sandbox:

gateway::/sandbox/[name] {
  if (auth_server@apcera.me->name==[name]) {
    permit all
  }
}

The same can be accomplished using a role:

gateway::/sandbox/[name] {
  if (auth_server@apcera.me->name==[name]) {
    role admin
  }
}

gateway::/sandbox/[name] {
  if (role == "admin")
    { permit all }
}

The following policy could be used to limit gateway to use only (no promote):

gateway::/sandbox/[name] {
  if (auth_server@apcera.me->name==[name]) {
    permit use
  }
}

Examples for default gateways

Apcera ships with a default set of service gateways, such as MySQL, Postgres, etc. These default gateways are found in the /apcera/service-gateways namesapce.

You could grant general access to use all system-provided service gateways using the following policy:

job::/apcera/service-gateways {
  { permit use }
}

Or, you could grant specific permissions to individual gateways as follows:

gateway::/apcera/service-gateways::cloudant {
  { permit use }
}

gateway::/apcera/service-gateways::generic {
  { permit use }
}

gateway::/apcera/service-gateways::http {
  { permit use }
}

gateway::/apcera/service-gateways::ipm {
  { permit use }
}

gateway::/apcera/service-gateways::memcache {
  { permit use }
}

gateway::/apcera/service-gateways::mysql {
  { permit use }
}

gateway::/apcera/service-gateways::network {
  { permit use }
}

gateway::/apcera/service-gateways::nfs {
  { permit use }
}

gateway::/apcera/service-gateways::postgres {
  { permit use }
}

gateway::/apcera/service-gateways::redis {
  { permit use }
}

Or, you could grant blanket access to service gateways to any requestor with a valid token:

on gateway::/ {
  { permit use }
}

Gateway promotion example

The promote claim type lets a user promote a job to be a service gateway. The following policy block permits jobs in the /foo namespace to be promoted to a service gateway in the /bar namespace.

gateway::/bar {
	if (job fqnMatch "job::/foo") {
		permit promote
	}
}

To promote a job to a gateway, the permit promote claim must exist for both the job and gateway resource. Thus, for the job you need the following policy:

job::/foo {
	{ permit promote }
}