# StellaOps Authority Container Scaffold

This directory provides a distroless Dockerfile and `docker-compose` sample for bootstrapping the Authority service alongside MongoDB (required) and Redis (optional).

## Prerequisites

- Docker Engine 25+ and Compose V2
- .NET 10 preview SDK (only required when building locally outside of Compose)
- Populated Authority configuration at `etc/authority.yaml` and plugin manifests under `etc/authority.plugins/`

## Usage

```bash
# 1. Ensure configuration files exist (copied from etc/authority.yaml.sample, etc/authority.plugins/*.yaml)
# 2. Build and start the stack
docker compose -f ops/authority/docker-compose.authority.yaml up --build
```

`authority.yaml` is mounted read-only at `/etc/authority.yaml` inside the container. Plugin manifests are mounted to `/app/etc/authority.plugins`. Update the issuer URL plus any Mongo credentials in the compose file or via an `.env`.

To run with pre-built images, replace the `build:` block in the compose file with an `image:` reference.

## Volumes

- `mongo-data` – persists MongoDB state.
- `redis-data` – optional Redis persistence (enable the service before use).
- `authority-keys` – writable volume for Authority signing keys.

## Environment overrides

Key environment variables (mirroring `StellaOpsAuthorityOptions`):

| Variable | Description |
| --- | --- |
| `STELLAOPS_AUTHORITY__ISSUER` | Public issuer URL advertised by Authority |
| `STELLAOPS_AUTHORITY__PLUGINDIRECTORIES__0` | Primary plugin binaries directory inside the container |
| `STELLAOPS_AUTHORITY__PLUGINS__CONFIGURATIONDIRECTORY` | Path to plugin manifest directory |

For additional options, see `etc/authority.yaml.sample`.

> **Graph Explorer reminder:** When enabling Cartographer or Graph API components, update `etc/authority.yaml` so the `cartographer-service` client includes `properties.serviceIdentity: "cartographer"` and a tenant hint. Authority now rejects `graph:write` tokens that lack this marker, so existing deployments must apply the update before rolling out the new build.

## Key rotation automation (OPS3)

The `key-rotation.sh` helper wraps the `/internal/signing/rotate` endpoint delivered with CORE10. It can run in CI/CD once the new PEM key is staged on the Authority host volume.

```bash
AUTHORITY_BOOTSTRAP_KEY=$(cat ~/.secrets/authority-bootstrap.key) \
./key-rotation.sh \
  --authority-url https://authority.stella-ops.local \
  --key-id authority-signing-2025 \
  --key-path ../certificates/authority-signing-2025.pem \
  --meta rotatedBy=pipeline --meta changeTicket=OPS-1234
```

- `--key-path` should resolve from the Authority content root (same as `docs/11_AUTHORITY.md` SOP).
- Provide `--source`/`--provider` if the key loader differs from the default file-based provider.
- Pass `--dry-run` during rehearsals to inspect the JSON payload without invoking the API.

After rotation, export a fresh revocation bundle (`stellaops-cli auth revoke export`) so downstream mirrors consume signatures from the new `kid`. The canonical operational steps live in `docs/11_AUTHORITY.md` – make sure any local automation keeps that guide as source of truth.