andrew.dunn.dev

egress

~3 min
air-gapcontrolled-egressegressgitlabself-managed
Source Site

A self-managed GitLab instance is not silent on the network. Service Ping, license checks, Duo, package-registry proxying, webhooks: each has its own outbound story, and each differs in what it sends, who can enable it, and whether an allowlist gates it. In a controlled-egress or air-gapped environment, every one of those connections needs a justification that a firewall reviewer or an accreditor can check before it is allowed to exist.

watchesre-deriveINPUTpublic evidencesource and docsPROCESSderivationper releaseDATAYAML profileschema-gatedOUTPUTrenderingsmaps and tablesWATCHtripwireweekly
Public GitLab evidence becomes one versioned YAML profile of every outbound connection, which compiles into the published maps and tables and is re-derived whenever the weekly tripwire reds.

The starting question was whether that could be answered as data rather than as prose. GitLab’s own documentation covers the pieces, spread across the page for each feature and written once for a first read. Answering “is this safe for my environment” one modality at a time, from documentation scattered across products, does not scale. What a reviewer needs has different properties: one profile per deployment form, every destination carrying a version-validity range, a ledger recording when it was last checked and against which release, and a citation to go re-derive instead of a claim to take on trust.

The build is where that gets interesting, because the same machinery has to serve both the first assessment and every re-assessment after it.

current release tagswatched weeklyupdates the dataredpublic evidenceGitLab source at pinned tagspublic documentationrelease and deprecation dataderivationstatic derivation per releasea capture bench settles whatsource alone cannotprofile dataYAML per modality, per formschema-validated, gatedledger and provenance per factfreshness tripwirereds when the ledger fallsbehind, cited evidence drifts,or a citation link rotsre-derivation passa supervised sessionre-checks the flagged facts,then appends to theverification ledgerfour renderingsegress map · east-west mapreference table · llms.txtone compile step; no viewencodes a fact of its own
Public evidence derives schema-gated profile data that compiles into four renderings, while a weekly freshness tripwire routes stale facts through a supervised re-derivation pass that updates the same data.

Nothing in that loop is a one-time artifact. A red tripwire is a work order rather than an alarm, and because re-derivation appends to the same ledger the renderings already read from, a profile cannot quietly become a snapshot of whatever release happened to be current the day it was written.

The egress map as published: three zones, the operator's own infrastructure on the left, the self-managed instance in the middle, and GitLab and third-party destinations on the right, with every connection drawn as an edge between them

egress covers self-managed GitLab only, not GitLab.com, and I draw the line at the runner’s own infrastructure: what a user-authored CI job sends over the network is that job’s business, not the platform’s, and it is a stated non-goal rather than a gap to close.

The conformance-contract shape, a declared standards file plus a component that checks it, looks like the part worth carrying to anything meant to outlive a single maintainer, and evidence-factory is where I carried it next: its three consumer repos are seeded on the same report, cutover, enforce ladder egress uses for its own conformance contract.

varve asks a much smaller version of the same question, of one machine instead of a platform, where the answer it has to keep proving is that nothing leaves at all.