Runtime image lacks libgssapi_krb5.so.2 — Npgsql logs a load error on every connection #332

Observed during host live-verification on a managed PostgreSQL 18.4 cluster (deployment repo, host-selection work). Filing per the deployment-boundary convention: image contents are app-repo territory, so this is an ask rather than a change.

Observation

Every process that opens an Npgsql connection emits, to stdout, before any structured log line:

Cannot load library libgssapi_krb5.so.2
Error: libgssapi_krb5.so.2: cannot open shared object file: No such file or directory

Reproduced on both the migrate one-shot and the serving process, using the published multi-stage image (aspnet:10.0 runtime base, non-root uid 1654) against a TLS (sslmode=verify-full) managed Postgres endpoint.

Impact

Non-fatal — migrations applied cleanly (31 migrations, exit 0) and the app serves normally. The cost is log noise: two unstructured error lines per connecting process, emitted outside Serilog, on a path operators will be watching during deploys and incidents. It reads like a failure when it isn't.

Relevant given the deploy-side plan to ship logs to an OTLP/log sink — these lines are unstructured and pre-logger, so they land awkwardly.

Cause

Npgsql probes for GSSAPI/Kerberos support at connection setup. The Debian aspnet runtime image doesn't carry libgssapi-krb5-2, so the probe fails loudly rather than silently degrading.

Options (app team's call)

1. Install libgssapi-krb5-2 in the runtime stage — silences it, but adds a package to an image that Deploy: container/image hardening — non-root USER, pinned base digests, image vulnerability scan #267 deliberately keeps minimal and Trivy-scanned.
2. Disable the GSSAPI path via connection-string/Npgsql configuration if a supported switch exists, so the probe never runs.
3. Accept and document it, so operators recognise it as benign.

No preference from the deploy side beyond wanting the production log stream to be free of misleading errors; option 2 or 3 both work for us, and option 1 has an image-surface trade-off worth weighing against #267/#294.

Context

• Deploy-side host verification: mforce/cluckwork-deploy#1
• Image hardening: Deploy: container/image hardening — non-root USER, pinned base digests, image vulnerability scan #267 / PR chore(docker): image hardening — non-root user, pinned digests, Trivy CI, Dependabot (references #267) #294
• Not related to Deploy: enforce TLS (sslmode) on every production Postgres connection #262/Deploy: separate the migration/owner DB role from the runtime app role (no DDL at request-time) #263 — TLS and the role split both verified working in the same run.