Skip to main content

Policies

Policies exist on two levels, per tenant and per user. The tenant policies govern what a tenant is allowed to access regardless of user policies.

Policies associated with a token govern what a user or application is allowed to access inside the scope of the tenant policy. There are three different type of policies

  • REST API
  • Capabilities
  • Volga topics

The REST API policies controls access to different REST resources. The most specific path wins when evaluating policies. The default policy is reject. A single wildcard can match anything on a given level, two wildcards match the entire sub-tree.

For a given path a policy may specify different privileges for different operations. The different operations are read, create, update, and execute. A REST request is mapped to these operations as follows:

  • GET is checked against the read operation
  • POST is checked against the create operation
  • PATCH and PUT are checked against the update operation

Any REST operations towards an endpoint that is an action or RPC will be checked against the execute operation in the policy. In most cases actions and RPCs are invoked using an HTTP POST operation.

View the contents of the default policy.

supctl show --config policy policies default
name: default
rest-api:
  rules:
    - path: /v1/*/strongbox/authentication/change-password
      description: Allow user to change password.
      operations:
        read: allow
        execute: allow
    - path: /v1/*/strongbox/authentication/enable-totp
      description: Allow user to enable totp.
      operations:
        read: allow
        execute: allow
    - path: /v1/state/strongbox/token/refresh
      description: Allow token refresh
      operations:
        all: allow
    - path: /v1/state/strongbox/token/info
      description: Allow viewing token-info.
      operations:
        all: allow
    - path: /v1/token-info
      description: Allow viewing token-info.
      operations:
        all: allow
    - path: /logout
      description: Always allow logout.
      operations:
        all: allow
volga:
  topics:
    - name: "*"
      operations:
        create: allow
        delete: allow
        produce: allow
        consume: allow

This allows access to the token refresh and info actions, as well as read access to strongbox identity and read action to strongbox transit-keys.

To determine which policies a token has use the token-info action.

supctl do token-info
display-name: userpass-joe@popcorn-systems.com
accessor: fc102ed9-686f-48d0-bc8b-8c4a9c4156a2
tenant: popcorn-systems
tenant-kind: application-owner
policies:
  - default
  - user
meta:
  email: admin@theater-operation.com
  authenticator: avassa-strongbox
  username: joe@popcorn-systems.com
  source: userpass
  ip: 192.168.100.1
creation-time: 2021-08-24T12:23:27.339465Z
renewal-time: 2021-08-24T12:23:27.339465Z
entity-alias-id: a9823ad6-afa4-4a85-b61e-ca6ae58709d1
explicit-max-ttl: 0s
num-uses: 0
orphan: true
renewable: true
period: 0s
type: default
ttl: 14d
max-ttl: 32d

This token is associated with the default and the user policies.

Control application access to APIs​

An application is assigned policies in the approles entry.

supctl create strongbox authentication approles <<EOF
name: app
token-policies:
  - app
EOF

The token created when the application authenticates gets the app policy and the default policy (the default policy can be prevented by setting token-no-default-policy: true.

Give the app full access to the db vault.

supctl create policy policies <<EOF
name: app
rest-api:
  rules:
    - path: /v1/*/strongbox/vaults/db/**
      operations:
        all: allow
EOF

Note that modifying policies requires root privileges to prevent privilege escalation.

Subtenant policies​

A subtenant can be given access to certain parts of the system by associating policies in the tenants definition. Without such policies the tenant isn't allowed to use the APIs at all.

Define an app-owner policy

supctl create policy policies app-owner <<EOF
name: app-owner
rest-api:
  rules:
    - path: /**
      operations:
        all: allow
    - path: /v1/*/strongbox/transit-keys/infra
      operations:
        all: reject
    - path: /v1/*/strongbox/transit-keys/infra/**
      operations:
        all: reject
    - path: /v1/*/strongbox/system/**
      operations:
        all: reject
    - path: /v1/*/strongbox/internal/**
      operations:
        all: reject
    - path: /v1/*/system/**
      operations:
        all: reject
capabilities:
  registry-pull: allow
  registry-push: allow
volga:
  topics:
    - name: "*"
      operations:
        creation: allow
        produce: allow
        consume: allow
EOF

Create a new subtenant popcorn-systems with the app-owner policy.

supctl create tenants <<EOF
name: popcorn-systems
kind: application-owner
policies:
  - app-owner
EOF

Grant capabilities to subtenant​

Some functionality associated with greater degree of control and in some cases reduced isolation between applications is protected by capabilities. This means that a system provider decides whether a tenant is trusted to get access to such functionality.

In order to grant a tenant a capability, or a set of capabilities, such capabilities may be added to an existing policy (as shown in the Subtenant policies section, or a new policy may be created as follows:

supctl create policy policies extended-networking <<EOF
name: extended-networking
capabilities:
  container-net-admin: allow
  service-host-network-mode: allow
EOF

The policy may then be added to the list of tenant's existing policies:

supctl merge tenants popcorn-systems <<EOF
policies:
  - extended-networking
EOF

Verify that the desired set of policies is assigned to the tenant:

supctl show tenants popcorn-systems
name: popcorn-systems
kind: application-owner
policies:
  - app-owner
  - extended-networking

Debugging policy rules​

Logging can be enabled by setting the global policy log level. There are two different levels of detail:

  • none: Log nothing
  • reject: Log reject
  • all: Log both reject and allow
supctl create policy log <<EOF
level: all
EOF

All log events will end up in the system:trace-log Volga stream.

supctl show --config policy policies user
supctl do volga topics system:logs consume --payload-only
<INFO> (theater-operation) 2022-02-14 14:29:44.714676+00:00 topdc-001 strongbox_policies:1358 <0.3052.0>
policy log: read /v1/config/policy/policies/user => allow (allowed by parent-tenant (movie-theater-owner), checking tenant policies)
<INFO> (theater-operation) 2022-02-14 14:29:44.714791+00:00 topdc-001 strongbox_policies:937 <0.3052.0>
policy log: read /v1/config/policy/policies/user => allow (user)
<INFO> (theater-operation) 2022-02-14 14:29:47.705457+00:00 topdc-001 strongbox_policies:1358 <0.3068.0>
policy log: execute /v1/state/volga/topics/system:logs/consume => allow (allowed by parent-tenant (movie-theater-owner), checking tenant policies)
<INFO> (theater-operation) 2022-02-14 14:29:47.705583+00:00 topdc-001 strongbox_policies:937 <0.3068.0>
policy log: execute /v1/state/volga/topics/system:logs/consume => allow (user)
<INFO> (theater-operation) 2022-02-14 14:29:47.707113+00:00 topdc-001 strongbox_policies:1394 <0.3076.0>
policy log: consume topic system:logs => allow (allowed by parent-tenant (movie-theater-owner), checking tenant policies)
<INFO> (theater-operation) 2022-02-14 14:29:47.707182+00:00 topdc-001 strongbox_policies:858 <0.3076.0>
policy log: consume topic system:logs => allow (default)