BaseHarbor v0.4.9

BaseHarbor v0.4.9

v0.4.9 adds centralized workload log collection without putting Loki into the portable application contract, and hardens the provider/runtime boundary that the rest of the v0.4 line depends on.

Centralized logs without product coupling

Repository workloads can now be collected through the provider-neutral logs/v1 lifecycle. Deployment policy decides whether collection is enabled and which provider placement is used.

The first Compose reference implementation uses:

• Grafana Loki 3.7.8 for log storage/query;
• Grafana Alloy 1.19.2 as the collection/forwarding component;
• shared placement by default, including optional named sharing boundaries;
• application placement for a dedicated application/environment provider.

Applications do not request Loki. BaseHarbor derives workload log sources from the selected repository Compose services and records the logical resources and provider placement in the protected provider registry.

Development enables application log collection by default. Test, staging and production remain opt-in through deployment policy.

Zero-trust workload preflight

Before BaseHarbor starts a repository workload it now evaluates the fully rendered Compose configuration for isolation bypasses.

The preflight detects privileged containers, runtime socket mounts, host networking, host PID/IPC namespaces, dangerous Linux capabilities, host devices and critical host filesystem mounts. Results are machine-readable and classified as allow, warn or deny.

Managed/non-development environments fail closed for isolation-breaking settings. Development can acknowledge explicitly supported exceptions, but no warning can silently bypass a deny policy.

BaseHarbor-managed Compose services are hardened as unprivileged runtimes. PostgreSQL, Valkey, OpenBao, Caddy, SeaweedFS, the OpenTelemetry Collector, Prometheus, Loki, Alloy and BaseHarbor's broker/executor/relay paths run with an explicit non-root identity or a BaseHarbor image that is itself non-root. Where technically supported they use read-only roots, drop all Linux capabilities, enable no-new-privileges and expose only required writable volumes/tmpfs. Loki and Alloy receive no Docker/Podman socket.

Compose-specific service UIDs are deployment detail. BaseHarbor-owned runtime images also prepare writable state directories for platform-assigned arbitrary non-root UIDs so future OpenShift/Kubernetes adapters do not need to inherit a fixed Compose UID. A provider image that cannot satisfy a target runtime's non-root/arbitrary-UID policy must be rejected for that runtime instead of requiring elevated privileges.

Executable provider conformance

The Provider Integration Contract v1 now has reusable executable lifecycle conformance tests rather than descriptor-only checks.

The suite exercises:

• unsupported placement failing before mutation;
• side-effect-free preflight;
• create followed by idempotent no-op convergence;
• binding and verification;
• deterministic drift/repair;
• provider failure between lifecycle phases;
• verify failure never becoming READY;
• retry convergence without unnecessary resource identity changes;
• ownership-safe destroy;
• secret-safe diagnostics.

A deterministic in-process fake provider drives fault-injection tests. The Loki reference provider consumes the same conformance harness.

Provider/core cleanup

The v0.4.9 audit removed a duplicated provider-descriptor switch in the application registry and now resolves descriptors through the canonical Provider Integration Contract registry. Remaining provider/placement switches are authoritative mapping points or provider-internal topology decisions rather than duplicated lifecycle knowledge.

Compatibility and upgrade impact

Manifest v1 is unchanged. Existing PostgreSQL, Valkey, OpenBao, Caddy, S3, OTLP, Prometheus and Runtime Resource API behavior remains compatible.

Log collection is deployment/platform behavior rather than a new product field in baseharbor.yaml. Existing repositories therefore do not need a manifest migration.

When logs are enabled, BaseHarbor adds a generated Compose logging override for selected workload services. Application-owned Compose source and volumes are not rewritten or taken over.

Security notes

• BaseHarbor-managed Compose containers must not require UID 0 for normal operation; validation checks both the configured user and the effective process UID.
• The bundled OpenBao service starts directly as non-root openbao, uses a read-only root filesystem, writes generated local config to an ephemeral writable /openbao/config tmpfs and suppresses privileged entrypoint chown attempts with the image-supported SKIP_CHOWN mode.
• BaseHarbor-owned runtime images prepare writable state paths for arbitrary platform-assigned non-root UIDs.
• Loki/Alloy receive no Docker or Podman socket.
• Loki API and Alloy syslog listeners are host-loopback only; provider-internal traffic stays on an internal network while a separate provider bridge exists only to realize those loopback host bindings.
• provider registry/state files are owner-only;
• log labels contain application/environment/service identity, not credentials;
• workload security analysis runs before workload mutation;
• unsupported provider placement fails closed;
• production-like environments cannot use development-only security acknowledgements.

Intentionally deferred

• Kubernetes/OpenShift runtime support is not part of v0.4.9.
• External Loki/provider loading is not implemented; the integration descriptor advertises only placements the current Compose adapter can realize.
• Grafana and Tempo are not provisioned by logs.
• Loki HA/object-storage topologies remain future provider profiles. The current single-binary reference topology uses provider-local persistent filesystem storage; a future topology that requires S3 must use provider-internal storage dependency wiring rather than granting an application S3 capability.
• A broad dynamic provider plugin runtime remains deferred.