Secrets Policy Examples

This section provides policy examples for using secrets.

About secrets

Secrets are treated as first-class objects in Apcera and controlled via policy. A secret is either a SSL/TLS certificate or a private key (private).

You can import certificates and keys into the system and assign them to routers

Supported claim types

The secrets::/ realm supports the following claim types. Note that domain.allow must be on a separate line.

secrets::/ {
  if (permit == all) {
    permit create, read, delete
    domain.allow VALUE
  }
}

Policy secrets example 1

The following policy variable example allows user “sandy” to read (list, get) certificates in the /apcera namespace. The user is not allowed to read any other secrets.

on secret::/apcera {
  if (auth_server@apcera.me->name == “sandy” && query->secretType == “certificate”) {
    permit read
  }
}

Policy secrets example 2

The following policy variable example allows user “sandy” to read (list, get) private keys in the /apcera namespace. The user is not allowed to read any other secrets.

on secret::/apcera {
  if (auth_server@apcera.me->name == “sandy” && query->secretType == “private”) {
    permit read
  }
}

Policy secrets example 3

The following traditional policy example allows a specific certificate and secret to be added to the router, and only for the specific domain purchasing.acme.com.

on secret::/sandbox/user::acmecert {
  if (role == “dev”) {
    permit read
    domain.allow purchasing.acme.com
  }
}

on secret::/sandbox/user::acmekey {
  if (role == “dev”) {
    permit read
    domain.allow purchasing.acme.com
  }
}

Policy secrets example 4

The following traditional policy example allows an administrator to import and manage certificates and keys.

on secret:: {
  if (role == admin) {
    permit create, read, delete
  }
}