Operations
Security and secrets
This page is written to be read by someone whose job is to say no. It states the boundaries in the order a security review asks about them, and it names the gaps in the same voice as the guarantees.
How credentials are held
A connection string is never an ordinary String in
this codebase. It is a SensitiveString, which records
where it came from and whose Debug implementation prints
<redacted>. A stray {:?}
in a log line or a panic message therefore cannot leak a password — the type
refuses, rather than a reviewer having to catch it.
Under environment: production an inline value is
rejected outright, so the only two forms that reach a running service are an
environment-variable reference and an absolute file path. Kafka credentials follow
the same rule and are resolved only while constructing the librdkafka client; the
resolved value is not retained in the public config types and does not appear in
adapter errors.
The read-only guarantee
trellara-check is the first thing you will be asked
to run against a production database, so its boundary is the one that matters
most. It issues read-only SQL and creates nothing — no publication, no
replication slot, no schema, no checkpoint table, no target state.
That is structural rather than promised: every query the binary can issue comes
from one shared manifest, source_safety_read_only_queries,
which the crate exposes as a compatibility surface and which the HTML report
prints in full so you can read the exact SQL before you run it. Adding a write
query to that manifest breaks the crate's own contract tests.
trellara-check "$DATABASE_URL" --format html --output source-safety.html
Connection strings are redacted before they reach any of the three renderers, so the report is safe to attach to a ticket.
What the database account needs
The diagnostic needs only read access to catalog and statistics views. Capture
needs a role with REPLICATION, and the publication and
slot are ordinary database objects you can inspect through
pg_publication and
pg_replication_slots and drop with ordinary DDL. Nothing
is hidden from the DBA.
On the target, Trellara owns one schema. It creates and writes thirteen tables
under trellara. — progress, deduplication,
snapshot state, DDL barriers, quarantine, verification events and Iceberg commit
records — plus the rows it applies to your tables. It does not read or
modify anything else.
A least-privilege role template with the exact grant list, per provider. It is on the roadmap and it does not exist. Until it does, scope the role the way you would scope any replication consumer, and tell us what you had to grant.
Transport
| Hop | Protection |
|---|---|
| Trellara → PostgreSQL | Ordinary PostgreSQL TLS handling, the same path a managed provider expects. No custom trust store and no verification-bypass flag. |
| Trellara → Kafka | Required TLS with mutual TLS or SASL SCRAM under the production contract. Enforced in validation. |
| Trellara → local durable log | Filesystem. Topic names are validated so they cannot escape the configured root. |
| Native extension → relay | A Unix domain socket the relay creates and then sets to mode 0600, with a shared secret on every frame. |
| Trellara → object storage and catalog | Whatever your S3-compatible endpoint and REST catalog require. Trellara adds no credential store of its own. |
The native extension boundary
If you deploy the optional extension, three things deserve a reviewer's
attention. The relay secret is registered as a SUPERUSER_ONLY
setting flagged NO_SHOW_ALL, so it does not appear in
SHOW ALL for an ordinary role. Broker and network I/O
stay outside the PostgreSQL process — the extension hands frames to a local
relay over that 0600 socket and does nothing else off-host. And the shared-memory
queue is bounded at sixteen slots of 64 KiB, so a stalled relay applies
backpressure and leaves the slot unacknowledged rather than growing without limit
inside the server.
What ends up in an artifact you forward
This question is usually asked last and deserves to be asked first. Reports, proof bundles and pilot packages are built to be forwardable: passwords, tokens, private keys, certificate contents and complete connection strings are excluded by construction, and every output surface has a redaction test.
But verification output can contain bounded row samples, because a drift report that cannot show you the drifting row is not evidence. Treat an evidence package as data-classified at the level of the tables it covers. Retention and deletion of those packages is your policy to set; Trellara neither expires them nor uploads them anywhere.
Telemetry and egress
There is none. No usage reporting, no licence check, no crash reporting, no hosted component in the open-source path. Trellara talks to your PostgreSQL, your broker or local disk, and your object storage and catalog. If you would rather verify that than take it on trust, run it with egress denied except to those hosts — nothing will complain.
Supply chain, stated plainly
Release binaries are built in CI from a Rust toolchain pinned in
rust-toolchain.toml and published with SHA-256 checksums.
They are not signed. There is no SBOM. There is
no build-provenance attestation. There has been no third-party
security review of any kind.
If your process requires signed artifacts with an SBOM, Trellara does not clear that bar today, and no amount of reading this page changes it. It is tracked in the evidence table as a release gate, not as a documentation gap.