125 Commits (52451cf846950804a7c541b113ba520fd8770011)

Author	SHA1	Message	Date
freddygv	768dbaa68d	Add session flag to cookie config	4 years ago
freddygv	9d2a9169fd	PR comments	4 years ago
freddygv	eab90ea9fa	Revert EnvoyConfig nesting	4 years ago
freddygv	403a180430	Set tgw filter router config name to cluster name	4 years ago
freddygv	959d9913b8	Add server receiver to routes and log tgw err	4 years ago
freddygv	00f2794bfa	Update golden files after default route fix for tgw	4 years ago
freddygv	318aa094fd	Fix http assertion in route creation	4 years ago
freddygv	30ba080d25	Add explicit protocol overrides in tgw xds test cases	4 years ago
freddygv	f81fe6a1a1	Remove LB infix and move injection to xds	4 years ago
freddygv	63f79e5f9b	Restructure structs and other PR comments	4 years ago
freddygv	28d0602fc1	Pass LB config to Envoy via xDS	4 years ago
freddygv	2bbbd9e1da	Log error as error	4 years ago
R.B. Boyer	74d5df7c7a	xds: use envoy's rbac filter to handle intentions entirely within envoy (#8569)	4 years ago
R.B. Boyer	fead4fc2a5	agent: expose the list of supported envoy versions on /v1/agent/self (#8545)	4 years ago
R.B. Boyer	e3cd4a8539	connect: use stronger validation that ingress gateways have compatible protocols defined for their upstreams (#8470) ... Fixes #8466 Since Consul 1.8.0 there was a bug in how ingress gateway protocol compatibility was enforced. At the point in time that an ingress-gateway config entry was modified the discovery chain for each upstream was checked to ensure the ingress gateway protocol matched. Unfortunately future modifications of other config entries were not validated against existing ingress-gateway definitions, such as: 1. create tcp ingress-gateway pointing to 'api' (ok) 2. create service-defaults for 'api' setting protocol=http (worked, but not ok) 3. create service-splitter or service-router for 'api' (worked, but caused an agent panic) If you were to do these in a different order, it would fail without a crash: 1. create service-defaults for 'api' setting protocol=http (ok) 2. create service-splitter or service-router for 'api' (ok) 3. create tcp ingress-gateway pointing to 'api' (fail with message about protocol mismatch) This PR introduces the missing validation. The two new behaviors are: 1. create tcp ingress-gateway pointing to 'api' (ok) 2. (NEW) create service-defaults for 'api' setting protocol=http ("ok" for back compat) 3. (NEW) create service-splitter or service-router for 'api' (fail with message about protocol mismatch) In consideration for any existing users that may be inadvertently be falling into item (2) above, that is now officiall a valid configuration to be in. For anyone falling into item (3) above while you cannot use the API to manufacture that scenario anymore, anyone that has old (now bad) data will still be able to have the agent use them just enough to generate a new agent/proxycfg error message rather than a panic. Unfortunately we just don't have enough information to properly fix the config entries.	4 years ago
R.B. Boyer	c599a2f5f4	xds: add support for envoy 1.15.0 and drop support for 1.11.x (#8424) ... Related changes: - hard-fail the xDS connection attempt if the envoy version is known to be too old to be supported - remove the RouterMatchSafeRegex proxy feature since all supported envoy versions have it - stop using --max-obj-name-len (due to: envoyproxy/envoy#11740)	4 years ago
Hans Hasselberg	496fb5fc5b	add support for envoy 1.14.4, 1.13.4, 1.12.6 (#8216)	4 years ago
R.B. Boyer	1eef096dfe	xds: version sniff envoy and switch regular expressions from 'regex' to 'safe_regex' on newer envoy versions (#8222) ... - cut down on extra node metadata transmission - split the golden file generation to compare all envoy version	4 years ago
Chris Piraino	735337b170	Append port number to ingress host domain (#8190) ... A port can be sent in the Host header as defined in the HTTP RFC, so we take any hosts that we want to match traffic to and also add another host with the listener port added. Also fix an issue with envoy integration tests not running the case-ingress-gateway-tls test.	4 years ago
Daniel Nephin	010a609912	Fix a bunch of unparam lint issues	4 years ago
R.B. Boyer	c63c994b04	connect: upgrade github.com/envoyproxy/go-control-plane to v0.9.5 (#8165)	4 years ago
Freddy	5baa7b1b04	Always return a gateway cluster (#8158)	4 years ago
Daniel Nephin	068b43df90	Enable gofmt simplify ... Code changes done automatically with 'gofmt -s -w'	5 years ago
Daniel Nephin	2eac5b8023	Merge pull request #8074 from hashicorp/dnephin/remove-references-to-PatchSliceOfMaps ... Update comments that reference PatchSliceOfMaps	5 years ago
freddygv	19e3954603	Move compound service names to use ServiceName type	5 years ago
Freddy	166a8b2a58	Only pass one hostname via EDS and prefer healthy ones (#8084) ... Co-authored-by: Matt Keeler <mkeeler@users.noreply.github.com> Currently when passing hostname clusters to Envoy, we set each service instance registered with Consul as an LbEndpoint for the cluster. However, Envoy can only handle one per cluster: [2020-06-04 18:32:34.094][1][warning][config] [source/common/config/grpc_subscription_impl.cc:87] gRPC config for type.googleapis.com/envoy.api.v2.Cluster rejected: Error adding/updating cluster(s) dc2.internal.ddd90499-9b47-91c5-4616-c0cbf0fc358a.consul: LOGICAL_DNS clusters must have a single locality_lb_endpoint and a single lb_endpoint, server.dc2.consul: LOGICAL_DNS clusters must have a single locality_lb_endpoint and a single lb_endpoint Envoy is currently handling this gracefully by only picking one of the endpoints. However, we should avoid passing multiple to avoid these warning logs. This PR: * Ensures we only pass one endpoint, which is tied to one service instance. * We prefer sending an endpoint which is marked as Healthy by Consul. * If no endpoints are healthy we emit a warning and skip the cluster. * If multiple unique hostnames are spread across service instances we emit a warning and let the user know which will be resolved.	5 years ago
Daniel Nephin	8ec029ae6a	Update comments that reference PatchSliceOfMaps ... To reference decode.HookWeakDecodeFromSlice instead. Also removes a step from the adding config fields checklist which is no longer necessary.	5 years ago
Daniel Nephin	c66c533d73	Merge pull request #7964 from hashicorp/dnephin/remove-patch-slice-of-maps-forward-compat ... config: Use HookWeakDecodeFromSlice in place of PatchSliceOfMaps	5 years ago
Daniel Nephin	75cbbe2702	config: add HookWeakDecodeFromSlice ... Currently opaque config blocks (config entries, and CA provider config) are modified by PatchSliceOfMaps, making it impossible for these opaque config sections to contain slices of maps. In order to fix this problem, any lazy-decoding of these blocks needs to support weak decoding of []map[string]interface{} to a struct type before PatchSliceOfMaps is replaces. This is necessary because these config blobs are persisted, and during an upgrade an older version of Consul could read one of the new configuration values, which would cause an error. To support the upgrade path, this commit first introduces the new hooks for weak decoding of []map[string]interface{} and uses them only in the lazy-decode paths. That way, in a future release, new style configuration will be supported by the older version of Consul. This decode hook has a number of advantages: 1. It no longer panics. It allows mapstructure to report the error 2. It no longer requires the user to declare which fields are slices of structs. It can deduce that information from the 'to' value. 3. It will make it possible to preserve opaque configuration, allowing for structured opaque config.	5 years ago
Chris Piraino	1a853fc954	Always require Host header values for http services (#7990) ... Previously, we did not require the 'service-name.*' host header value when on a single http service was exposed. However, this allows a user to get into a situation where, if they add another service to the listener, suddenly the previous service's traffic might not be routed correctly. Thus, we always require the Host header, even if there is only 1 service. Also, we add the make the default domain matching more restrictive by matching "service-name.ingress.*" by default. This lines up better with the namespace case and more accurately matches the Consul DNS value we expect people to use in this case.	5 years ago
Freddy	9ed325ba8b	Enable gateways to resolve hostnames to IPv4 addresses (#7999) ... The DNS resolution will be handled by Envoy and defaults to LOGICAL_DNS. This discovery type can be overridden on a per-gateway basis with the envoy_dns_discovery_type Gateway Option. If a service contains an instance with a hostname as an address we set the Envoy cluster to use DNS as the discovery type rather than EDS. Since both mesh gateways and terminating gateways route to clusters using SNI, whenever there is a mix of hostnames and IP addresses associated with a service we use the hostname + CDS rather than the IPs + EDS. Note that we detect hostnames by attempting to parse the service instance's address as an IP. If it is not a valid IP we assume it is a hostname.	5 years ago
Daniel Nephin	6a2d7d77c0	config: use the new HookTranslateKeys instead of lib.TranslateKeys ... With the exception of CA provider config, which will be migrated at some later time.	5 years ago
Daniel Nephin	8ced4300c8	Add alias struct tags for new decode hook	5 years ago
Raphaël Rondeau	0d2f178b7b	connect: fix endpoints clusterName when using cluster escape hatch (#7319) ... ```changelog * fix(connect): fix endpoints clusterName when using cluster escape hatch ```	5 years ago
Kyle Havlovitz	b14696e32a	Standardize support for Tagged and BindAddresses in Ingress Gateways (#7924) ... * Standardize support for Tagged and BindAddresses in Ingress Gateways This updates the TaggedAddresses and BindAddresses behavior for Ingress to match Mesh/Terminating gateways. The `consul connect envoy` command now also allows passing an address without a port for tagged/bind addresses. * Update command/connect/envoy/envoy.go Co-authored-by: Freddy <freddygv@users.noreply.github.com> * PR comments * Check to see if address is an actual IP address * Update agent/xds/listeners.go Co-authored-by: Freddy <freddygv@users.noreply.github.com> * fix whitespace Co-authored-by: Chris Piraino <cpiraino@hashicorp.com> Co-authored-by: Freddy <freddygv@users.noreply.github.com>	5 years ago
Daniel Nephin	9f27d61bee	Remove unused var ... The usage was removed in 8e22d80e35, however it seems there may be a bug here because the cluster name is not updated when the target changes.	5 years ago
Daniel Nephin	c662f0f0de	Fix a number of problems found by staticcheck ... Some of these problems are minor (unused vars), but others are real bugs (ignored errors). Co-authored-by: Matt Keeler <mkeeler@users.noreply.github.com>	5 years ago
Kyle Havlovitz	136549205c	Merge pull request #7759 from hashicorp/ingress/tls-hosts ... Add TLS option for Ingress Gateway listeners	5 years ago
Daniel Nephin	5655d7f34e	Add outlier_detection check to integration test ... Fix decoding of time.Duration types.	5 years ago
Daniel Nephin	eaa05d623a	xds: Add passive health check config for upstreams	5 years ago
Freddy	c32a4f1ece	Fix up enterprise compatibility for gateways (#7813)	5 years ago
Chris Piraino	f55e20a2f7	Allow ingress gateways to send empty clusters, routes, and listeners (#7795) ... This is useful when updating an config entry with no services, and the expected behavior is that envoy closes all listeners and clusters. We also allow empty routes because ingress gateways name route configurations based on the port of the listener, so it is important we remove any stale routes. Then, if a new listener with an old port is added, we will not have to deal with stale routes hanging around routing to the wrong place. Endpoints are associated with clusters, and thus by deleting the clusters we don't have to care about sending empty endpoint responses.	5 years ago
Kyle Havlovitz	f14c54e25e	Add TLS option and DNS SAN support to ingress config ... xds: Only set TLS context for ingress listener when requested	5 years ago
Chris Piraino	d498a0afc9	Correctly set a namespace label in the required domain for xds routes ... If an upstream is not in the default namespace, we expect DNS requests to be served over "<service-name>.ingress.<namespace>.*"	5 years ago
Chris Piraino	45e635286a	Re-add comment on connect-proxy virtual hosts	5 years ago
Chris Piraino	c44f877758	Comment why it is ok to expect upstreams slice to not be empty	5 years ago
Chris Piraino	881760f701	xds: Use only the port number as the configured route name ... This removes duplication of protocol from the stats_prefix	5 years ago
Chris Piraino	f40833d094	Allow Hosts field to be set on an ingress config entry ... - Validate that this cannot be set on a 'tcp' listener nor on a wildcard service. - Add Hosts field to api and test in consul config write CLI - xds: Configure envoy with user-provided hosts from ingress gateways	5 years ago
Kyle Havlovitz	711d1389aa	Support multiple listeners referencing the same service in gateway definitions	5 years ago
Kyle Havlovitz	247f9eaf13	Allow ingress gateways to route traffic based on Host header ... This commit adds the necessary changes to allow an ingress gateway to route traffic from a single defined port to multiple different upstream services in the Consul mesh. To do this, we now require all HTTP requests coming into the ingress gateway to specify a Host header that matches "<service-name>.*" in order to correctly route traffic to the correct service. - Differentiate multiple listener's route names by port - Adds a case in xds for allowing default discovery chains to create a route configuration when on an ingress gateway. This allows default services to easily use host header routing - ingress-gateways have a single route config for each listener that utilizes domain matching to route to different services.	5 years ago