233 lines
9.0 KiB
Markdown
233 lines
9.0 KiB
Markdown
# 10 · Feedser + CLI Quickstart
|
||
|
||
This guide walks through configuring the Feedser web service and the `stellaops-cli`
|
||
tool so an operator can ingest advisories, merge them, and publish exports from a
|
||
single workstation. It focuses on deployment-facing surfaces only (configuration,
|
||
runtime wiring, CLI usage) and leaves connector/internal customization for later.
|
||
|
||
---
|
||
|
||
## 0 · Prerequisites
|
||
|
||
- .NET SDK **10.0.100-preview** (matches `global.json`)
|
||
- MongoDB instance reachable from the host (local Docker or managed)
|
||
- `trivy-db` binary on `PATH` for Trivy exports (and `oras` if publishing to OCI)
|
||
- Plugin assemblies present in `PluginBinaries/` (already included in the repo)
|
||
- Optional: Docker/Podman runtime if you plan to run scanners locally
|
||
|
||
> **Tip** – air-gapped installs should preload `trivy-db` and `oras` binaries into the
|
||
> runner image since Feedser never fetches them dynamically.
|
||
|
||
---
|
||
|
||
## 1 · Configure Feedser
|
||
|
||
1. Copy the sample config to the expected location (CI/CD pipelines can stamp values
|
||
into this file during deployment—see the “Deployment automation” note below):
|
||
|
||
```bash
|
||
mkdir -p etc
|
||
cp etc/feedser.yaml.sample etc/feedser.yaml
|
||
```
|
||
|
||
2. Edit `etc/feedser.yaml` and update the MongoDB DSN (and optional database name).
|
||
The default template configures plug-in discovery to look in `PluginBinaries/`
|
||
and disables remote telemetry exporters by default.
|
||
|
||
3. (Optional) Override settings via environment variables. All keys are prefixed with
|
||
`FEEDSER_`. Example:
|
||
|
||
```bash
|
||
export FEEDSER_STORAGE__DSN="mongodb://user:pass@mongo:27017/feedser"
|
||
export FEEDSER_TELEMETRY__ENABLETRACING=false
|
||
```
|
||
|
||
4. Start the web service from the repository root:
|
||
|
||
```bash
|
||
dotnet run --project src/StellaOps.Feedser.WebService
|
||
```
|
||
|
||
On startup Feedser validates the options, boots MongoDB indexes, loads plug-ins,
|
||
and exposes:
|
||
|
||
- `GET /health` – returns service status and telemetry settings
|
||
- `GET /ready` – performs a MongoDB `ping`
|
||
- `GET /jobs` + `POST /jobs/{kind}` – inspect and trigger connector/export jobs
|
||
|
||
> **Security note** – authentication is not wired yet; guard the service with
|
||
> network controls or a reverse proxy until auth middleware ships.
|
||
|
||
### Authority companion configuration (preview)
|
||
|
||
1. Copy the Authority sample configuration:
|
||
|
||
```bash
|
||
cp etc/authority.yaml.sample etc/authority.yaml
|
||
```
|
||
|
||
2. Update the issuer URL, token lifetimes, and plug-in descriptors to match your
|
||
environment. Authority expects per-plugin manifests in `etc/authority.plugins/`;
|
||
sample `standard.yaml` and `ldap.yaml` files are provided as starting points.
|
||
For air-gapped installs keep the default plug-in binary directory
|
||
(`../PluginBinaries/Authority`) so packaged plug-ins load without outbound access.
|
||
|
||
3. Environment variables prefixed with `STELLAOPS_AUTHORITY_` override individual
|
||
fields. Example:
|
||
|
||
```bash
|
||
export STELLAOPS_AUTHORITY__ISSUER="https://authority.stella-ops.local"
|
||
export STELLAOPS_AUTHORITY__PLUGINDIRECTORIES__0="/srv/authority/plugins"
|
||
```
|
||
|
||
---
|
||
|
||
## 2 · Configure the CLI
|
||
|
||
The CLI reads configuration from JSON/YAML files *and* environment variables. The
|
||
defaults live in `src/StellaOps.Cli/appsettings.json` and expect overrides at runtime.
|
||
|
||
| Setting | Environment variable | Default | Purpose |
|
||
| ------- | -------------------- | ------- | ------- |
|
||
| `BackendUrl` | `STELLAOPS_BACKEND_URL` | _empty_ | Base URL of the Feedser web service |
|
||
| `ApiKey` | `API_KEY` | _empty_ | Reserved for future auth; keep empty today |
|
||
| `ScannerCacheDirectory` | `STELLAOPS_SCANNER_CACHE_DIRECTORY` | `scanners` | Local cache folder |
|
||
| `ResultsDirectory` | `STELLAOPS_RESULTS_DIRECTORY` | `results` | Where scan outputs are written |
|
||
|
||
Example bootstrap:
|
||
|
||
```bash
|
||
export STELLAOPS_BACKEND_URL="http://localhost:5000"
|
||
export STELLAOPS_RESULTS_DIRECTORY="$HOME/.stellaops/results"
|
||
dotnet run --project src/StellaOps.Cli -- db merge
|
||
```
|
||
|
||
To persist configuration, you can create `stellaops-cli.yaml` next to the binary or
|
||
rely on environment variables for ephemeral runners.
|
||
|
||
---
|
||
|
||
## 3 · Operating Workflow
|
||
|
||
1. **Trigger connector fetch stages**
|
||
|
||
```bash
|
||
dotnet run --project src/StellaOps.Cli -- db fetch --source osv --stage fetch
|
||
dotnet run --project src/StellaOps.Cli -- db fetch --source osv --stage parse
|
||
dotnet run --project src/StellaOps.Cli -- db fetch --source osv --stage map
|
||
```
|
||
|
||
Use `--mode resume` when continuing from a previous window:
|
||
|
||
```bash
|
||
dotnet run --project src/StellaOps.Cli -- db fetch --source redhat --stage fetch --mode resume
|
||
```
|
||
|
||
2. **Merge canonical advisories**
|
||
|
||
```bash
|
||
dotnet run --project src/StellaOps.Cli -- db merge
|
||
```
|
||
|
||
3. **Produce exports**
|
||
|
||
```bash
|
||
# JSON tree (vuln-list style)
|
||
dotnet run --project src/StellaOps.Cli -- db export --format json
|
||
|
||
# Trivy DB (delta example)
|
||
dotnet run --project src/StellaOps.Cli -- db export --format trivy-db --delta
|
||
```
|
||
|
||
Feedser always produces a deterministic OCI layout. The first run after a clean
|
||
bootstrap emits a **full** baseline; subsequent `--delta` runs reuse the previous
|
||
baseline’s blobs when only JSON manifests change. If the exporter detects that a
|
||
prior delta is still active (i.e., `LastDeltaDigest` is recorded) it automatically
|
||
upgrades the next run to a full export and resets the baseline so operators never
|
||
chain deltas indefinitely. The CLI exposes `--publish-full/--publish-delta` (for
|
||
ORAS pushes) and `--include-full/--include-delta` (for offline bundles) should you
|
||
need to override the defaults interactively.
|
||
|
||
**Smoke-check delta reuse:** after the first baseline completes, run the export a
|
||
second time with `--delta` and verify that the new directory reports `mode=delta`
|
||
while reusing the previous layer blob.
|
||
|
||
```bash
|
||
export_root=${FEEDSER_EXPORT_ROOT:-exports/trivy}
|
||
base=$(ls -1d "$export_root"/* | sort | tail -n2 | head -n1)
|
||
delta=$(ls -1d "$export_root"/* | sort | tail -n1)
|
||
|
||
jq -r '.mode,.baseExportId' "$delta/metadata.json"
|
||
|
||
base_manifest=$(jq -r '.manifests[0].digest' "$base/index.json")
|
||
delta_manifest=$(jq -r '.manifests[0].digest' "$delta/index.json")
|
||
printf 'baseline manifest: %s\ndelta manifest: %s\n' "$base_manifest" "$delta_manifest"
|
||
|
||
layer_digest=$(jq -r '.layers[0].digest' "$base/blobs/sha256/${base_manifest#sha256:}")
|
||
cmp "$base/blobs/sha256/${layer_digest#sha256:}" \
|
||
"$delta/blobs/sha256/${layer_digest#sha256:}"
|
||
```
|
||
|
||
`cmp` returning exit code `0` confirms the delta export reuses the baseline’s
|
||
`db.tar.gz` layer instead of rebuilding it.
|
||
|
||
4. **Manage scanners (optional)**
|
||
|
||
```bash
|
||
dotnet run --project src/StellaOps.Cli -- scanner download --channel stable
|
||
dotnet run --project src/StellaOps.Cli -- scan run --entry scanners/latest/Scanner.dll --target ./sboms
|
||
dotnet run --project src/StellaOps.Cli -- scan upload --file results/scan-001.json
|
||
```
|
||
|
||
Add `--verbose` to any command for structured console logs. All commands honour
|
||
`Ctrl+C` cancellation and exit with non-zero status codes when the backend returns
|
||
a problem document.
|
||
|
||
---
|
||
|
||
## 4 · Verification Checklist
|
||
|
||
- Feedser `/health` returns `"status":"healthy"` and Storage bootstrap is marked
|
||
complete after startup.
|
||
- CLI commands return HTTP 202 with a `Location` header (job tracking URL) when
|
||
triggering Feedser jobs.
|
||
- Export artefacts are materialised under the configured output directories and
|
||
their manifests record digests.
|
||
- MongoDB contains the expected `document`, `dto`, `advisory`, and `export_state`
|
||
collections after a run.
|
||
|
||
---
|
||
|
||
## 5 · Deployment Automation
|
||
|
||
- Treat `etc/feedser.yaml.sample` as the canonical template. CI/CD should copy it to
|
||
the deployment artifact and replace placeholders (DSN, telemetry endpoints, cron
|
||
overrides) with environment-specific secrets.
|
||
- Keep secret material (Mongo credentials, OTLP tokens) outside of the repository;
|
||
inject them via secret stores or pipeline variables at stamp time.
|
||
- When building container images, include `trivy-db` (and `oras` if used) so air-gapped
|
||
clusters do not need outbound downloads at runtime.
|
||
|
||
---
|
||
|
||
## 5 · Next Steps
|
||
|
||
- Introduce authentication/authorization in the web service before exposing it on
|
||
shared networks.
|
||
- Automate the workflow above via CI/CD (compose stack or Kubernetes CronJobs).
|
||
- Pair with the Feedser connector teams when enabling additional sources so their
|
||
module-specific requirements are pulled in safely.
|
||
|
||
---
|
||
|
||
## 6 · Microsoft Authentication Integration (Planned)
|
||
|
||
- The Feedser web service will integrate with the Microsoft identity stack (Entra ID)
|
||
using OAuth 2.0. Expect additional configuration keys for authority URLs, client
|
||
IDs/secrets, and audience scopes once the implementation lands.
|
||
- CLI commands already pass `Authorization` headers when credentials are supplied.
|
||
When auth is enabled, point `stellaops-cli` at the token issuer (client credentials
|
||
flow) or run it behind a proxy that injects bearer tokens.
|
||
- Keep network-facing deployments behind reverse proxies or firewalls until the
|
||
authentication middleware ships and is fully validated.
|