Access Control

In TSB, Tenants, Environments and Applications have a policy document that describes who can access it and the operations that are allowed to that subject. Each resource has one and only one policy document that can be obtained using the Policy API.

The current policy model is based on RBAC, where a resource can be bound to a set of subjects and permissions.

Getting the policy document for an object

Policy documents can be accessed for each resource in the URI <resource uri>/policy, as described by the Policy API. The following example resource shows a policy document for a TSB resource:

curl https://${TSBIP}:8443/v1/tenants/tenant1/environments/dev/policy
{
  "bindings": [
    {
      "role": "Owner",
      "subjects": [
        "tenants/nacx-tenant/teams/ops",
        "tenants/nacx-tenant/users/nacx",
        "tenants/nacx-tenant/users/zack"
      ]
    }
  ]
}

That policy means that the dev environment can be accessed by:

• Users nacx and zack.
• All users in the ops group.

Supported roles

In TSB 0.6.2 there is still no support for fine-grained permissions. The platform comes with just the Owner role that gives full access to the resources. In this version access control is a binary option in which users have full access or no access to the resources they are assigned to.

Modifying the access policy for a resource

To modify the access policy of a given resource, a simple call to the SetPolicy method for that resource can be done. For example, to grant access to a new team to the resource in the example above, it just needs to be added to the subjects list:

curl https://${TSBIP}:8443/v1/tenants/tenant1/environments/dev/policy \
    -X PUT \
    -H 'content-type: application/json' \
    -d @- <<EOF
{
  "bindings": [
    {
      "role": "Owner",
      "subjects": [
        "tenants/nacx-tenant/teams/ops",
        "tenants/nacx-tenant/users/nacx",
        "tenants/nacx-tenant/users/zack",
        "tenants/nacx-tenant/teams/dev"
      ]
    }
  ]
}
EOF