Skip to content

atenet-router: reach atunnel through mTLS CONNECT tunnels by default - #2618

Merged
Bowei Du (bowei) merged 1 commit into
agent-substrate:mainfrom
LiorLieberman:upstream-connect-default
Oct 14, 2026
Merged

atenet-router: reach atunnel through mTLS CONNECT tunnels by default#2618
Bowei Du (bowei) merged 1 commit into
agent-substrate:mainfrom
LiorLieberman:upstream-connect-default

Conversation

@LiorLieberman

@LiorLieberman Lior Lieberman (LiorLieberman) commented Oct 13, 2026

Copy link
Copy Markdown
Collaborator
  • Follow-up to add support for connect from atenet (envoy) to atunnel  #2531: --upstream-connect now defaults to true, so the Envoy router reaches atunnel through mTLS CONNECT tunnels on 8443. --upstream-connect=false goes back to HTTPS on 443.
  • An empty --upstream-credential-bundle now needs --upstream-connect=false, and the startup error says so. The check only applies to the Envoy ingress router; the egress gateway and agentgateway don't use the flag (agentgateway always uses CONNECT).
  • Split xDS server setup out of startEnvoyDataplane so a new test can parse real flags and check the built snapshot for both settings.
  • The e2e gRPC downgrade test now expects only gRPC Unavailable, so it fails if the router falls back to the HTTPS path.
  • Updated architecture.md, threat-model.md and the router manifest comment.

Related: #1208

It's a good idea to open an issue first for discussion.

  • Tests pass
  • Appropriate changes to documentation are included in the PR

ahmedtd
Taahir Ahmed (ahmedtd) reviewed Oct 14, 2026
View reviewed changes
Comment thread manifests/ate-install/atenet-router.yaml
# server on :443, and validates that server against the trust bundle.
# mTLS. Envoy presents this credential bundle as its client cert when
# opening CONNECT tunnels to the worker's atunnel on :8443, and
# validates that server against the trust bundle.

@ahmedtd Taahir Ahmed (ahmedtd) Oct 14, 2026 •
edited
Loading

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't see this logic anywhere in the PR?

It's not sufficient to just check the server certificate against this root certificate --- these certificates can be issued to any pod in the cluster.

Additionally, to uphold the node isolation security principle, atenet ingress needs to know which specific ateom/atunnel pod it is connecting to, and check that against the pod information in the server certificate.

That doesn't have to be a GA blocker, but if we land something less secure, we need to track the followup.

@LiorLieberman Lior Lieberman (LiorLieberman) Oct 14, 2026

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

right, its not in this PR, its related to #2078 issue. Which we discussed a bit offline.

I will followup on this today/tomorrow (for GA, I think) but its a separate fix

yanavlasov
yanavlasov approved these changes Oct 14, 2026
View reviewed changes

@yanavlasov yanavlasov left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM from me.

@bowei Bowei Du (bowei) added area/network area/security Security related issue/pr kind/feature An enhancement / feature request or implementation labels Oct 14, 2026
@bowei
Bowei Du (bowei) added this pull request to the merge queue Oct 14, 2026
Merged via the queue into agent-substrate:main with commit fa07840 Oct 14, 2026
14 checks passed
@feifeigood feifeigood (feifeigood) mentioned this pull request Oct 15, 2026
Closed
1 of 2 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@ahmedtd Taahir Ahmed (ahmedtd) ahmedtd left review comments
@bowei Bowei Du (bowei) bowei approved these changes
+1 more reviewer
@yanavlasov yanavlasov yanavlasov approved these changes
Reviewers whose approvals may not affect merge requirements

Assignees

No one assigned

Labels

area/network area/security Security related issue/pr kind/feature An enhancement / feature request or implementation

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

4 participants

@LiorLieberman @bowei @ahmedtd @yanavlasov