plexsphere

Appearance

Apply the ReBAC schema ​

The authorisation model lives in schema/authz.zed. There is no operator surface for the schema itself — plexctl rebac manages relation tuples and authorization checks, not the .zed model — so the schema is applied over SpiceDB's gRPC WriteSchema API. The production authzed/spicedb image is distroless and ships no tar, so kubectl cp cannot be used — every path here writes over gRPC.

Prerequisites ​

  • An authenticated session — see Log in with plexctl.
  • kubectl against the target cluster and the upstream zed CLI.
  • The edited schema/authz.zed, validated with make authz-lint.

Steps ​

Resolve the SpiceDB pod ​

SpiceDB runs as a Deployment, so the pod name is generated. Resolve it with a label selector:

shell
SPICEDB_POD=$(kubectl get pod -l app.kubernetes.io/name=spicedb \
  -n plexsphere-dev -o jsonpath='{.items[0].metadata.name}')
# $SPICEDB_POD now holds e.g. spicedb-7d9f8c6b4-x2k9p

Use "$SPICEDB_POD" for any follow-up kubectl logs / kubectl describe.

Write the schema over gRPC ​

Port-forward the gRPC endpoint and push the schema with zed:

shell
kubectl -n plexsphere-dev port-forward service/spicedb 50051:50051 &
zed schema write schema/authz.zed \
  --endpoint=localhost:50051 --insecure --token "$SPICEDB_PRESHARED_KEY"

Alternatively run the e2e probe in-cluster — it dials spicedb:50051 over gRPC with apply-schema --schema-path=/etc/plexsphere/authz.zed. Both routes go through WriteSchema and never touch the pod filesystem. The schema is forward-only; there is no down migration.

Verification ​

shell
zed schema read --endpoint=localhost:50051 --insecure --token "$SPICEDB_PRESHARED_KEY"
# definition user { … }
# definition domain { … }
# definition project { … }
# …

The output must reflect the edited definitions.

See also ​