Registry model and auth reference

This page covers registry storage, routing, and access control for Everlock's OCI service. The Distribution protocol itself comes from the embedded apimeister-registry engine; reaching registries over public DNS or a private LAN is covered in DNS vhosts and ACME and mDNS discovery.

Service model

mounted through frontend-http
implemented as an adapter over apimeister-registry
selected by vhost, similar to the site backend
backed by one Everlock store per configured registry
authenticated through Everlock HTTP Basic auth and Everlock grants

Storage

Each configured OCI registry is backed by its own Everlock versioned-storage store.

That means:

one logical OCI registry maps to one Everlock store
OCI data is persisted through Everlock storage rather than a separate filesystem blob directory
current OCI writes are auditable in the same general way as the other versioned-storage-backed backends

The store-backed implementation is the source of truth for OCI persistence.

Admin CLI

OCI registries are managed through the admin SSH console:

/oci list
/oci create <name> [store=<name>] vhost=<host>
/oci set <name> store=<name> | vhost=<host>
/oci unset <name> vhost=<host>
/oci delete <name>

Registry configuration changes apply on restart rather than live reload.

Authorization

Authorization uses normal Everlock identity and grant checks:

HTTP Basic auth validates against the Everlock user registry
pull maps to Everlock read access
push maps to Everlock write access
delete maps to Everlock delete access
anonymous pull works by granting Reader on the OCI instance to the built-in anon user

The path shape is coarse-grained at OCI instance level, so authorization is applied per registry instance rather than per repository path.