Adding a Subtenant

It might be useful to create a subtenant and assign certain resources and capabilities to the subtenant. The subtenant is completely isolated from its parent, in terms of secrets. It is not possible for a parent tenant to access secrets of a subtenant, nor is it possible for a subtenant to access secrets in the parent.

However, a subtenant is limited in resources and capabilities by its parent. It cannot deploy applications on sites that its parent are not allowed to deploy on, nor can it consume more resources than the parent.

When creating a subtenant the first step should be to create a policy for the subtenant. This policy will constrain the subtenant to certain parts of the system. For example, to create a policy that allows a subtenant to deploy applications and generally access most of the resources the following policy may be created:

supctl create policy policies <<EOF
name: acme-tenant-policy
rest-api:
  rules:
    - path: /**
      operations:
        all: allow
    - path: /v1/*/strongbox/transit-keys/infra/**
      description: Prevent access to infra keys.
      operations:
        all: reject
    - path: /v1/*/strongbox/system/**
      description: Prevent access to system actions and config.
      operations:
        all: reject
    - path: /v1/*/strongbox/internal/**
      description: Prevent access to internal actions and config.
      operations:
        all: reject
    - path: /v1/*/system/cluster
      description: Allow access to cluster state.
      operations:
        all: allow
    - path: /v1/*/system/**
      description: Prevent access to system internal actions and config.
      operations:
        all: reject
capabilities:
  registry-pull: allow
  registry-push: allow
volga:
  topics:
    - name: "*"
      operations:
        create: allow
        delete: allow
        produce: allow
        consume: allow
  infras:
    - name: "*"
      operations:
        produce: allow
        consume: allow
EOF

This policy can now be referenced when the tenant is created.

Before creating a subtenant it must be decided what type of tenant to create, an application-owner or a site-provider. Application owner are allowed to deploy applications on existing sites, whereas a site provider is also allowed to manage sites.

For example, to create a tenant called acme of type application-owner:

supctl create tenants <<EOF
name: acme
kind: application-owner
policies:
  - acme-tenant-policy
EOF

Transferring Control of a Subtenant

After a subtenant has been created control over the subtenant should be handed over to the administrator of the tenant. A subtenant is initially without much configuration, ie it does not have any users or applications deployed.

The first step is to create a root token that can then be used by the subtenant administrator to create further configuration like adding users etc.

The parent tenant creates a root token for the new tenant using the action create-root with the tenants name as argument, for example:

supctl do strongbox token create-root --name acme
{
  "accessor": "1c15f223-271e-4a48-ac23-c949cfe345f6",
  "token": "c2e45f7d-9efc-48f2-adff-7a1355bc28a6",
  "creation-time": "2022-05-11T12:35:49.429590Z"
}

The information returned by this action should be given to the subtenant administrator. Note that the create-root operation can only be used once for any given tenant. This is to prevent a parent tenant from accessing a subtenant after it has been created.

The subtenant should use the supplied root token to create an admin user, for example:

supctl -t "c2e45f7d-9efc-48f2-adff-7a1355bc28a6" create strongbox authentication userpass <<EOF
name: admin@acme.com
password: verysecret
token-ttl: 15d
token-policies:
  - root
EOF

And then revoke the root token it received from its parent tenant. That way the parent can no longer access the subtenant, ie:

supctl do strongbox token revoke --token c2e45f7d-9efc-48f2-adff-7a1355bc28a6

A new root token can always be created for the own tenant if needed, ie

supctl -d .topdc.acme do strongbox token create-root

It is possible for a parent tenant to create a new root token for a subtenant but only with the --wipe argument. This will cause the entire Strongbox configuration to be removed except for authentication configuration, ie, all secrets and encryption keys will be removed.

Transferring Control of a Subtenant​

Transferring Control of a Subtenant