[BUG] Portainer AllowInsecureHttp logs no runtime warning while plaintext HTTP is in use #276

Summary

DockerUpdateGuard:DockerInstances:<n>:Portainer:AllowInsecureHttp: true lets the Portainer integration send the API token, or username/password and the returned JWT, over plaintext http. It is only a validation switch today: nothing is logged at runtime while it is active. .squad/project.md requires the transport relaxations SkipCertificateValidation and AllowInsecureHttp to "stay opt-in and keep their runtime warnings", and SkipCertificateValidation already logs one. AllowInsecureHttp needs the same kind of warning, once per Docker instance.

Area

• docs/areas/container-actions.md (Transport security)
• Security area (.squad/project.md): TLS and transport relaxations

Current behavior

• Validation accepts an http Portainer BaseUrl only with AllowInsecureHttp: true (src/DockerUpdateGuard/Configuration/DockerUpdateGuardOptionsValidator.cs:337-340). There is no other use of the flag at runtime: PortainerClient.CreateAuthenticatedClientAsync (src/DockerUpdateGuard/Portainer/PortainerClient.cs:134-187) sets BaseAddress to the http URL and sends X-API-Key or posts the credentials to /api/auth without a log entry.
• For comparison, SkipCertificateValidation logs a warning once per instance name per process lifetime: src/DockerUpdateGuard/Docker/DockerInstanceClient.cs:287-292 with _certificateValidationWarningInstances (line 34) and DockerInstanceCertificateValidationDisabled (EventId 3106, src/DockerUpdateGuard/Docker/DockerInstanceClientLogging.cs:90-93).
• docs/areas/container-actions.md:32 states: "It is a validation switch: no runtime warning is logged while it is active."

Scenario: an operator sets BaseUrl: http://portainer:9000 plus AllowInsecureHttp: true for a quick test and forgets it. Nothing in the logs reveals that Portainer credentials have been sent unencrypted ever since.

Expected behavior

• When a Portainer request is about to be made for a Docker instance whose Portainer BaseUrl uses the http scheme (which validation only allows with AllowInsecureHttp: true), a warning is logged once per Docker instance name per process lifetime, e.g. "Portainer for Docker instance {DockerInstanceName} uses plaintext HTTP (AllowInsecureHttp); API token, credentials and session token are transmitted unencrypted".
• The warning names the Docker instance (and may name the Portainer base URL), never the token, username, password or JWT.
• The warning is logged regardless of whether the call is a capability check or an action, and regardless of its outcome.
• AllowInsecureHttp stays opt-in, default false; https URLs produce no warning, also when AllowInsecureHttp is true but unused.

Acceptance criteria

• Two capability checks / actions for the same instance with an http Portainer URL log exactly one warning.
• Two different instances with http Portainer URLs log one warning each.
• An https Portainer URL with AllowInsecureHttp: true logs no warning.
• The warning text contains no secret (asserted in the test with a known token/password value).
• Unit tests (MSTest, naming per docs/UNIT_TESTS.md) in PortainerClientTests, e.g. PortainerClientGetCapabilityWithInsecureHttpLogsWarningOncePerInstance, PortainerClientExecuteActionWithHttpsDoesNotLogInsecureWarning; follow the pattern of DockerInstanceClientCreateHttpClientWhenSkipCertificateValidationLogsWarningOncePerInstance (src/Tests/DockerUpdateGuard.Tests/DockerInstanceClientTests.cs:652).
• README (README.md:187, AllowInsecureHttp row) says that a warning is logged at runtime while it is active, like the SkipCertificateValidation row.
• The area document docs/areas/container-actions.md describes the new behavior and its Known gaps entry for this issue (currently Open questions item 4) is removed; docs/ARCHITECTURE.md, Security posture, stays consistent.

Implementation notes

• PortainerClient is registered as a singleton (src/DockerUpdateGuard/ServiceCollectionExtensions.cs:104), so an instance-level ConcurrentDictionary<string, byte> (or a static one like DockerInstanceClient's) keyed by instance name with TryAdd is sufficient. Prefer an instance field over a static so tests stay isolated, unless the Lead prefers symmetry with DockerInstanceClient.
• Add a source-generated LoggerMessage to src/DockerUpdateGuard/Portainer/PortainerClientLogging.cs with the next free EventId in the 33xx range.
• Decide on the scheme check from the parsed BaseUrl (Uri.Scheme == Uri.UriSchemeHttp), not from the flag alone.
• Optional (Lead's call): also log the warning once at startup for every enabled instance with an http Portainer URL, so it is visible even if Portainer is never contacted. If chosen, still keep it to once per instance.
• No configuration or migration impact. Must not change: validation of http without AllowInsecureHttp still fails startup; secrets never logged (.squad/project.md).

Related

• F-040 (P6) — Critical paths without their own trace spans: scan.run/Portainer/CVE/persistence never started #83 (Portainer calls without trace spans — same client, independent)
• PR [Docs] Describe the current behavior by area #263 (area documents)

Generated by Claude Code