Access model

This part gives the persons and the components that have access to the state of the system, and the limits of that access. The tables that have the label "generated" come from the code at each build of the documentation (core/docs/md/technical-design/access-model.nix). The threats and the controls are in the threat model.

Actors

Permissions of each role

In the panel

The panel has three levels of access.

• A visitor without an account can read the public pages.
• An operator can read and change only the deployments for which Deployment.operator is the account of the operator (panel/src/panel/models.py). The views filter on this field.
• A superuser has the access of an operator. A superuser can also list, claim and assign domains for all operators, and can read the audit history of each account (reads_all_history and _AUTHZ_SUPERUSER_PROCEDURES in panel/src/panel/views.py).

The admin site of Django (/admin/) shows only the User model (panel/src/panel/admin.py). The views of the panel do not use is_staff. The directory groups fediversity-staff and fediversity-admins give no permission in the panel.

In the api

The api does not keep accounts and does not decide on access. For each request, the api sends the name of the procedure, the scope and the headers to the authorization callback of the panel (authorize in api/src/fediversity_api/authz.py, AuthzCallback in panel/src/panel/views.py). The callback accepts a request only with the callback token of the api (AUTHZ_CALLBACK_TOKEN), when that token is set. The panel identifies the requester from a bearer token that the panel signed, which stays valid for API_TOKEN_TTL seconds (panel/src/panel/tokens.py).

The callback denies a procedure that is not in AUTHZ_PROCEDURE_RULES. Without a callback URL, the api starts only when API_AUTHZ_ALLOW_ALL is set, and then it permits each request.

Directory groups of the hosting provider

The groups are in the lldap of the hosting provider. The section Manage users and groups of the hosting-provider guide tells how to give a group to a user.

When ADMIN_SOURCES is set, the firewall of each node accepts the administrative ports (port 22 by default) only from those addresses (core/resources/firewall/default.nix). An operator gets no shell access to the nodes of its deployment. The persons who can read each log, trace and audit channel are in Logs, traces and audit records.

Application roles

Each deployment of an operator has its own lldap, with the same group names. The lldap of a deployment has the groups application-admins and application-moderators (core/resources/ldap/application-role-groups.nix), and the groups of each application. Each application gives a role to the members of a group at log-in. The Grafana of a deployment accepts the members of fediversity-admins in the lldap of that deployment (core/components/operator/grafana/oidc.nix).

Generated from the role-groups.nix file of each application in core/components/operator/:

Access of each component to each store

The tables in this section are generated from the configuration of the nodes, with the groups of core/testers/groups.nix. That evaluation knows no deployment. Thus <own deployment> shows where a name has the namespace of the deployment of the node, and <each deployment> shows a path that applies to all deployments.

Secrets in the KV of OpenBao

Each node logs in to OpenBao with its SPIRE certificate and gets the policy host-<name>. The entries of the hosting provider are below secret/data/vars/. The entries of a deployment are below secret/data/vars/operator-deployments/<namespace>/. Each entry has a public half and a secret half. The credentials register gives the lifetime and the rotation of each credential. The table gives the name of the entry when a policy has the same capabilities on the two halves, and <half>/<entry> when it has them on one half. The table gives a grant on secret/metadata/ only when the policy has no grant on the data of the same entry.

The policy fediversity-admins in this table is that of the evaluation, where ADMIN_UI_WRITE is not set.

Other paths in OpenBao

These paths give certificates (pki), database passwords (database, postgresql), directory passwords (ldap, ldap-operator) and child tokens.

PostgreSQL

The database engine of OpenBao owns the password of each role and changes it at the interval in the table. A node reads the password of its role from OpenBao (core/setups/wiring/postgresql-roster.nix). The database and the role of a deployment have the namespace of the deployment as a suffix, and the OpenTofu graph of the deployment creates and drops them (core/effects/tf/incus/operator/postgresql.tf).

The postgresql node also has these group roles:

Two actors have access to all databases of the node: the front-end deployer, which reads the password of the postgres superuser (the entry secret/postgresql-admin in the KV table), and a member of fediversity-admins through pgweb.

Buckets in Garage

Each row is one ensureAccess entry of a key that a node requests. owner lets the key change the configuration of the bucket.

How the system keeps the tenants apart

• Nodes. Each deployment has its own nodes for each application and for valkey, authelia, smtp, lldap and grafana (core/setups/groups/operator.nix). The users, the sessions and the cache of a deployment are thus not in a store that a different deployment uses.
• Network. All nodes are on one Incus bridge. Each deployment gets a /28 of its own, and an Incus network ACL on each NIC drops the traffic to and from the other deployments (core/effects/tf/incus/operator/bridge-isolation.tf). The Incus host declares the ACL of each /28 (core/components/hosting-provider/incus-bridge-acls.nix), thus the certificate of a deploy runner is restricted to the Incus project of the deployments and cannot change an ACL. Each NIC has MAC and IP address filtering (core/effects/tf/incus/instance.tf). A second ACL and the firewall of each node of the hosting provider permit only the ports that a deployment uses (core/components/hosting-provider/operator-reach.nix). The second ACL holds only the IPv4 addresses of the nodes of the hosting provider. The bridge has no IPv6 subnet (ipv6.address = none in core/components/hosting-provider/incus.nix), thus Incus drops all IPv6 on eth0. A node of a deployment sends IPv6 only on its public eth1, which has no NAT, thus the firewall of the destination node sees the real source address and applies the port limit.
• Secrets. The policy of a node of a deployment names the KV paths with a template that OpenBao replaces with the namespace from the certificate of the node. Thus a node reads only the entries of its own deployment (core/components/hosting-provider/openbao/spire-auth.nix).
• Databases. All deployments use the PostgreSQL node of the hosting provider. Each deployment has its own database and role for each application, and a node can read only the password of the role that has its own namespace.
• Buckets. All deployments use the Garage cluster of the hosting provider. Each bucket and key has the namespace of the deployment as a prefix (tenant in core/resources/garage/default.nix), and a key has access only to the buckets in the table above.
• Metrics. The query path for the metrics of an application adds the deployment_id label to each query (core/components/hosting-provider/metrics-query.nix).
• Panel and api. An operator gets only the deployments that it owns (see In the panel).

These components are common to all tenants, and the separation there is weaker:

• The front-end deployer is one identity for all deployments. Its OpenBao policy can write the entries of each deployment that the KV table gives, and it can read the password of the postgres superuser. The state backend has one user operator for the states of all deployments (core/components/hosting-provider/terraform-backend/front.nix).
• The Grafana of the hosting provider has one organization, thus fediversity-staff and fediversity-admins can read the telemetry of all deployments.
• A member of fediversity-admins can read the secrets, the databases and the containers of all deployments.