fix(egress): require enforced credential destinations

[hellomypastor]

Summary

• Require Credential Vault to use dns+nft enforcement so credential-bound destinations cannot bypass network policy through direct IP connections.
• Keep defaultAction: allow backward compatible, but emit security warnings and recommend defaultAction: deny.
• Respect explicit deny rules when validating credential-bound destinations.
• Update documentation, specifications, SDK fixtures, and tests for the hardened behavior.

Testing

• Not run (explain why)
• Unit tests
• Integration tests
• e2e / manual verification

Validation performed:

• components/egress: go test ./...
• Credential Vault trusted/untrusted proxy tests
• Go E2E sources compilation check

Full E2E was not run because it requires a matching OpenSandbox server and Credential Vault target environment.

Breaking Changes

• None
• Yes (describe impact and migration path)

Credential Proxy now requires an explicit network policy and dns+nft enforcement. Existing deployments using DNS-only enforcement must migrate to:

[egress]
mode = "dns+nft"

defaultAction: allow remains accepted for backward compatibility, but is deprecated for Credential Vault usage and emits a security warning. defaultAction: deny with explicit destination allow rules is recommended.

Checklist

• Linked Issue or clearly described motivation
• Added/updated docs (if needed)
• Added/updated tests (if needed)
• Security impact considered
• Backward compatibility considered

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: a5cbcc7faf

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[Pangjiping]

LGTM

[Pangjiping]

Breaking Change concern: mandatory defaultAction: deny

Security hardening direction makes sense, but forcing defaultAction: deny as a hard constraint is a breaking change that's difficult to accept.

Issues

1. All existing integrations break — every user currently running Credential Vault with defaultAction: allow gets a 400 on upgrade. The E2E fixture churn (all 6 SDKs touched) shows the blast radius.

2. defaultAction: deny puts heavy burden on callers — users must enumerate every destination host, including credential-bound targets AND their IP addresses (the new targetIp rules in E2E are a direct example). Maintaining a complete allowlist is expensive for sandboxes that talk to multiple services.

Suggestion

• Make defaultAction: deny recommended — guide users with docs and warning logs, don't hard-reject
• If the security model truly requires deny-default, use a deprecation cycle: warn → reject

[Pangjiping]

LGTM. @jwx0925 ptal

[jwx0925]

LGTM