People and permissions

coming with the provisioner’s first release.

Who may do what is decided once per environment, not once per product: an administrator should be an administrator everywhere. Write it in one access file, and the provisioner sets it up at the identity provider.

Where	What it says
each product’s chart	which roles the product has
the access file	the groups, who is in them, which product roles each group holds, demo accounts, and people who sign in through a provider such as Google

Example

apiVersion: tinyblox.ai/v1alpha1
kind: Access
environment: production
namespace: tinyblox                     # where demo account passwords are written
identity:
  issuer: https://guard.example.com/auth/v1
  provisioning:
    provider: tinyguard                 # tinyguard or keycloak
    adminUrl: http://tinyguard.tinyblox.svc:8080

apps:                                   # the products, and where their roles live
  conductor: { clientId: tinyconductor-console }
  vault: { clientId: tinyvault-console }
  guard: { identityProvider: true }     # the identity provider's own administration

groups: [admins, operators, viewers]

roleBindings:                           # <app>:<role>
  admins: [conductor:admin, vault:platform_admin, guard:tinyguard_admin]
  operators: [conductor:operator, conductor:task-worker]
  viewers: [conductor:viewer]

federation:
  provider: google                      # the sign-in provider's name at the identity provider
federatedUsers:
  - { email: ana@example.com, groups: [admins] }
  - { email: ben@example.com, groups: [operators] }

For a demo or test environment you can add local accounts with a generated password:

localUsers:
  secretName: tinyblox-local-users
  users:
    - { username: demo-viewer, email: demo-viewer@example.com, groups: [viewers] }

What happens

• Groups are created. A group you remove from the file is deleted, unless a product still uses it.
• Members are found by e-mail. Someone you take out of a group in the file is taken out; someone added by hand stays.
• Roles: each group gets the product roles listed. A role you remove from the file is taken away; a role given by hand stays.
• People who sign in through a provider (federatedUsers) get their groups at their first sign-in, where the identity provider supports it. No account is made for them in advance.
• Local accounts get a 24-character password, written to the Secret before the account is made and never printed. Read one with kubectl -n tinyblox get secret tinyblox-local-users -o jsonpath='{.data.demo-viewer\.password}' | base64 -d.

What each identity provider supports

	TinyGuard 0.3	Keycloak
Groups, members by e-mail	yes	yes
A group holds a product role	not yet: map groups to roles in each product’s own mapping rules (the plan reports it as skipped)	yes
The identity provider’s own administration role	not yet	give it by hand
Local accounts	yes (sign in with the e-mail)	yes (sign in with the username)
Groups for federated people before their first sign-in	not yet: they join at the first run after they signed in	yes

The provisioner uses newer TinyGuard operations as soon as a TinyGuard release offers them, with no change to your file.

Running it

The access file uses its own credential, separate from the products’ one: it manages groups and people, never clients.

• TinyGuard: an API key with groups and users (read, create, update, delete), providers read when you use federatedUsers, and never tenants or api_keys.
• Keycloak: a service account with the realm-management roles view-clients, query-groups, view-users and manage-users, plus view-identity-providers and manage-identity-providers when you use federatedUsers.

Run the image as a Kubernetes Job after the products are installed, and again whenever the file changes. Put the file in a ConfigMap, the credential in a Secret, and give the Job a service account that may create the demo accounts’ Secret:

apiVersion: batch/v1
kind: Job
metadata: { name: tinyblox-access, namespace: tinyblox }
spec:
  backoffLimit: 1
  template:
    spec:
      serviceAccountName: tinyblox-access
      restartPolicy: Never
      containers:
        - name: provision
          image: registry.tinyfactory.ai/tinyblox/provision:0.1.0
          args: [apply]
          env:
            - { name: PROVISION_CONFIG, value: /etc/provision/access.yaml }
            - name: POD_NAMESPACE
              valueFrom: { fieldRef: { fieldPath: metadata.namespace } }
          volumeMounts:
            - { name: config, mountPath: /etc/provision, readOnly: true }
            - { name: credential, mountPath: /var/run/provision/credential, readOnly: true }
      volumes:
        - { name: config, configMap: { name: tinyblox-access } }
        - { name: credential, secret: { secretName: access-provisioning } }

The service account’s Role needs create on secrets, and get, update and delete on the one Secret named in localUsers.secretName.

Check the changes first with plan; see Commands.