test(egress): prove workload secret injection through egress gateway #206

User request

Add an actual E2E test for the implemented feature: Secrets injection through Egress Gateway data plane.

The test must prove that a request from a workload container goes through Egress Gateway and the upstream destination receives the required authorization token/header injected from a platform Secret. Postman Echo can be used as the upstream echo service.

Specification

Architecture source: agynio/architecture change changes/2026-05-14-egress-gateway.md.

Prerequisite runtime work:

• agynio/egress-gateway issue test: migrate terraform acceptance suites #7 / PR feat: migrate agents orchestrator e2e suite #8 wires the OpenZiti data-plane listener into the gateway runtime.

Existing e2e coverage is not sufficient:

• TestEgressGatewayFeaturePath covers control-plane rule/secret/attachment behavior.
• TestEgressGatewayDenyAndNoRulePaths covers deny/no-rule lookup.
• TestEgressGatewayDeploymentWiring covers gateway deployment/Kubernetes wiring.
• None of these proves that a real workload request reaches an upstream destination with injected Secret-backed authorization.

Required E2E behavior

Add a new Go core E2E scenario after the existing egress gateway tests.

The test should:

1. Create an organization/user/agent fixture using existing egress and workload helpers where possible.
2. Create a Secret containing a unique token value, e.g. e2e-egress-token-<uuid>.
3. Create an allow EgressRule for postman-echo.com:443 that injects:
   • header name: Authorization
   • header value from the Secret as Bearer <secret-value> or the control-plane-supported equivalent that produces that exact header upstream.
4. Attach the rule to the same agent/workload identity used by the running workload.
5. Wait for egress/Ziti rule propagation.
6. Start a real workload container through the normal runner/orchestrator path with Ziti interception enabled.
7. Ensure the workload command does not include the secret value and does not pass an Authorization header itself.
8. From inside the workload container, run an HTTPS request to:

https://postman-echo.com/get?egress_e2e=<uuid>

9. Parse the Postman Echo JSON response and assert:

headers.authorization == "Bearer <secret-value>"

10. Also assert the response args include the unique query value so the test proves it parsed the expected response.
11. Clean up rule attachment, rule, Secret, and workload resources.

Expected BDD definition

Add/update docs/e2e/suites/go-core.md with a new scenario:

• Given an authorized agent workload has no authorization token in its command or environment and an allow EgressRule references a platform Secret for postman-echo.com:443.
• When the workload sends an HTTPS request to Postman Echo without an Authorization header.
• Then the request is routed through Egress Gateway.
• And Postman Echo reports that the upstream destination received Authorization: Bearer <secret-value>.
• And the echoed query marker matches the test request.

Update traceability docs consistently if this repo requires it for new scenarios.

Acceptance criteria

• A new E2E test proves real data-plane secret injection from workload to external destination.
• The test fails if the gateway only has control-plane/wiring behavior but does not actually proxy/inject.
• The workload does not receive the secret value through env/command-line test setup.
• The test uses a unique token/query marker to avoid false positives.
• Existing egress gateway BDD docs are updated with this scenario.
• CI passes.