-
Notifications
You must be signed in to change notification settings - Fork 469
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Http connect proxy #4358
Http connect proxy #4358
Conversation
Issues linked to changelog: |
@@ -169,7 +169,7 @@ Note: the destination spec and subsets are not supported in this context and wil | |||
| `single` | [.gloo.solo.io.Destination](../proxy.proto.sk/#destination) | Use SingleDestination to route to a single upstream. Only one of `single`, `multi`, or `forwardSniClusterName` can be set. | | |||
| `multi` | [.gloo.solo.io.MultiDestination](../proxy.proto.sk/#multidestination) | Use MultiDestination to load balance requests between multiple upstreams (by weight). Only one of `multi`, `single`, or `forwardSniClusterName` can be set. | | |||
| `upstreamGroup` | [.core.solo.io.ResourceRef](../../../../../../solo-kit/api/v1/ref.proto.sk/#resourceref) | Use a reference to an upstream group for routing. Only one of `upstreamGroup`, `single`, or `forwardSniClusterName` can be set. | | |||
| `forwardSniClusterName` | [.google.protobuf.Empty](https://developers.google.com/protocol-buffers/docs/reference/csharp/class/google/protobuf/well-known-types/empty) | Forwards the SNI name into the destination cluster https://www.envoyproxy.io/docs/envoy/latest/api-v2/config/filter/network/sni_cluster/empty/sni_cluster Note: This filter will only work properly with TLS connections in which the upstream SNI domain is specified. Only one of `forwardSniClusterName`, `single`, or `upstreamGroup` can be set. | | |||
| `forwardSniClusterName` | [.google.protobuf.Empty](https://developers.google.com/protocol-buffers/docs/reference/csharp/class/google/protobuf/well-known-types/empty) | Forwards the request to a cluster name matching the TLS SNI name https://www.envoyproxy.io/docs/envoy/latest/api-v2/config/filter/network/sni_cluster/empty/sni_cluster Note: This filter will only work properly with TLS connections in which the upstream SNI domain is specified. Only one of `forwardSniClusterName`, `single`, or `upstreamGroup` can be set. | |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can forwardSniClusterName
and multi
be set?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
no they cannot be set at the same time https://github.com/solo-io/gloo/blob/245ca47bc977c9c3121f7e7b77d7b5b64bb7702b/projects/gloo/api/v1/proxy.proto#L121-L136
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we update the comment with that or is it autogenerated? It makes it seem only forwardSniClusterName
, single
, or upstreamGroup
can't be set at the same time.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
bizarre, this is auto-generated and appears to be a solo-kit bug: solo-io/solo-kit#407
continue | ||
} | ||
|
||
selfCluster := "solo_io_generated_self_cluster_" + cluster |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it fine hard coding the self cluster name here like this? It's going to be used anywhere else other than updating the route to the generated cluster in the tunneling plugin?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should be fine to hard-code, so long as there are no collisions or clusters by the same name. It is only used when we update the existing route to route to the new generated cluster.
}, | ||
ConnectTimeout: &duration.Duration{Seconds: 5}, | ||
Name: selfCluster, | ||
TransportSocket: originalTransportSocket, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks like it's only copying over the TransportSocket? Should TransportSocketMatches also be copied over?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we only use transport socket matches to allow different SNI for each endpoint in a static upstream https://github.com/solo-io/gloo/blob/ef4e92117a1f20e403bb7ba74fdcb47f7de5138d/projects/gloo/pkg/plugins/static/plugin.go#L153
in this case, the new generated cluster has only one endpoint (the self pipe), so there's no need for transport socket matches to pick which SNI to use with the endpoint (as there's only one)
this does mean the current implementation cannot use different SNI for each endpoint behind our final routing destination, but since the request bytes are encrypted before the endpoint is selected for tunneling I'm not sure there's much we can do to get around that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
further, the TLS context is actually for the tunneling target rather than the endpoints behind the HTTP proxy
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good!
* Fix some comments * Expose some needed APIs * Don't expose low level envoy API * Put new API in right file * Simplify tunneling config * Identify where cluster duplication/modification logic should live * Identify where listener duplication/modification logic should live * Update plugin interface * Begin tunneling plugin * Get e2e working with SSL * Cleanup * Get both e2es working * Cleanup * Improve docs * Cleanup * Fix unit test * Cleanup * Merge branch 'master' into http_connect_proxy * Add changelog * Change to stringvalue * Merge refs/heads/master into http_connect_proxy * Merge refs/heads/master into http_connect_proxy * Fix e2e tests on local; still fail in ci * Merge branch 'http_connect_proxy' of github.com:solo-io/gloo into http_connect_proxy * Check ok * timeout * Merge refs/heads/master into http_connect_proxy * Adding changelog file to new location * Deleting changelog file from old location * connect proxy according to docs * only hijack when done with errors * Cleanup * Merge branch 'master' into http_connect_proxy * Improve comments * Merge refs/heads/master into http_connect_proxy * Add another test * Unfocus test * TCP proxy unit tests * Namespaced generated resources unit test * Cleanup * Fix comment * Add more comments * Merge refs/heads/master into http_connect_proxy * PR comments
* Http connect proxy (#4358) * Fix some comments * Expose some needed APIs * Don't expose low level envoy API * Put new API in right file * Simplify tunneling config * Identify where cluster duplication/modification logic should live * Identify where listener duplication/modification logic should live * Update plugin interface * Begin tunneling plugin * Get e2e working with SSL * Cleanup * Get both e2es working * Cleanup * Improve docs * Cleanup * Fix unit test * Cleanup * Merge branch 'master' into http_connect_proxy * Add changelog * Change to stringvalue * Merge refs/heads/master into http_connect_proxy * Merge refs/heads/master into http_connect_proxy * Fix e2e tests on local; still fail in ci * Merge branch 'http_connect_proxy' of github.com:solo-io/gloo into http_connect_proxy * Check ok * timeout * Merge refs/heads/master into http_connect_proxy * Adding changelog file to new location * Deleting changelog file from old location * connect proxy according to docs * only hijack when done with errors * Cleanup * Merge branch 'master' into http_connect_proxy * Improve comments * Merge refs/heads/master into http_connect_proxy * Add another test * Unfocus test * TCP proxy unit tests * Namespaced generated resources unit test * Cleanup * Fix comment * Add more comments * Merge refs/heads/master into http_connect_proxy * PR comments * Codegen * Move changelog
Description
Adds support for HTTP Connect upstreams by setting tunneling config on the upstream. This can be used to route to other proxies (such as ones in a DMZ).
Context
Users desired route-level routing ability from envoy to HTTP-Connect enabled proxies for security reasons within their environments.
Checklist:
make install-go-tools generated-code
to ensure there will be no code diffBOT NOTES:
resolves [Migrated] support HTTP/1.1 CONNECT for proxied upstreams solo-io/gloo#3664