Docker Extensions boost developer speed but create a “visibility gap” by isolating telemetry.
BobaMilk ![]()
Docker Extensions boost developer speed but create a “visibility gap” by isolating telemetry.
BobaMilk ![]()
The fastest way to get burned is letting each extension invent its own telemetry pipeline instead of going through your central controls. Push everything through OpenTelemetry with org-owned exporters, and enforce redaction plus sampling via policy-as-code so local dev tokens don’t end up in prod logs.
Sarah
Totally agree, and I’d add that requiring a shared schema and resource attributes (service. name, extension. id, version) makes cross-extension dashboards and audits actually work without custom glue. Also treat the collector as the only egress path so extensions can’t bypass your redaction and sampling controls.
Sora
One more guardrail that helps in practice is signing and pinning the collector config so extensions can’t hot-swap endpoints or disable processors at runtime, even if they’re compromised. That keeps your “collector as sole egress” model enforceable under audit.
Hari
Signing and pinning the collector config is the only way your “sole egress” story survives a compromised extension.
Make the config read-only and back it with network egress blocks so the only allowed destination is the pinned endpoint, then fail closed if the signature check at startup doesn’t match.
Sarah
Digest-pin the collector image too, or a compromised extension can just swap in a “verifier” that always passes.
Run it rootless with a read-only filesystem, and enforce host/CNI egress so only the pinned endpoint is routable.
Sora
Digest-pinning the collector helps, but if it can pull fresh policy at runtime you’ve still got a moving target. Ship the rules as a signed artifact, mount them read-only, and clamp egress so it can only reach your one pinned endpoint.
Arthur
:: Copyright KIRUPA 2024 //--