26 Commits (a33c50ef0dd6f72e1f9c2047be919bb2ded0cd30)

Author	SHA1	Message	Date
R.B. Boyer	119e945c3e	connect: all config entries pick up a meta field (#8596) ... Fixes #8595	4 years ago
Jack	9e1c6727f9	Add http2 and grpc support to ingress gateways (#8458)	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
Chris Piraino	b3db907bdf	Update gateway-services-nodes API endpoint to allow multiple addresses ... Previously, we were only returning a single ListenerPort for a single service. However, we actually allow a single service to be serviced over multiple ports, as well as allow users to define what hostnames they expect their services to be contacted over. When no hosts are defined, we return the default ingress domain for any configured DNS domain. To show this in the UI, we modify the gateway-services-nodes API to return a GatewayConfig.Addresses field, which is a list of addresses over which the specific service can be contacted.	4 years ago
freddygv	19e3954603	Move compound service names to use ServiceName type	5 years ago
Chris Piraino	6fa48c9512	Allow users to set hosts to the wildcard specifier when TLS is disabled (#8083) ... This allows easier demoing/testing of ingress gateways, while still preserving the validation we have for DNSSANs	5 years ago
Daniel Nephin	4f2bff174d	Merge pull request #7963 from hashicorp/dnephin/replace-lib-translate-keys ... Replace lib.TranslateKeys with a mapstructure decode hook	5 years ago
Daniel Nephin	8ced4300c8	Add alias struct tags for new decode hook	5 years ago
R.B. Boyer	77f2e54618	create lib/stringslice package (#7934)	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
Kyle Havlovitz	8d140ce9af	Disallow the blanket wildcard prefix from being used as custom host	5 years ago
Freddy	c32a4f1ece	Fix up enterprise compatibility for gateways (#7813)	5 years ago
Chris Piraino	0c22eacca8	Add TLS field to ingress API structs ... - Adds test in api and command/config/write packages	5 years ago
Chris Piraino	0b9ba9660d	Validate hosts input in ingress gateway config entry ... We can only allow host names that are valid domain names because we put these hosts into a DNSSAN. In addition, we validate that the wildcard specifier '*' is only present as the leftmost label to allow for a wildcard DNSSAN and associated wildcard Host routing in the ingress gateway proxy.	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	d8517bd6fd	Better document wildcard specifier interactions	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
Chris Piraino	b73a13fc9e	Remove service_subset field from ingress config entry ... We decided that this was not a useful MVP feature, and just added unnecessary complexity	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
Freddy	137a2c32c6	TLS Origination for Terminating Gateways (#7671)	5 years ago
freddygv	915db10903	Avoid deleting mappings for services linked to other gateways on dereg	5 years ago
freddygv	c9385129ae	Require service:read to read terminating-gateway config	5 years ago
Kyle Havlovitz	e9e8c0e730	Ingress Gateways for TCP services (#7509) ... * Implements a simple, tcp ingress gateway workflow This adds a new type of gateway for allowing Ingress traffic into Connect from external services. Co-authored-by: Chris Piraino <cpiraino@hashicorp.com>	5 years ago
Freddy	9eb1867fbb	Terminating gateway discovery (#7571) ... * Enable discovering terminating gateways * Add TerminatingGatewayServices to state store * Use GatewayServices RPC endpoint for ingress/terminating	5 years ago
Freddy	90576060bc	Add config entry for terminating gateways (#7545) ... This config entry will be used to configure terminating gateways. It accepts the name of the gateway and a list of services the gateway will represent. For each service users will be able to specify: its name, namespace, and additional options for TLS origination. Co-authored-by: Kyle Havlovitz <kylehav@gmail.com> Co-authored-by: Chris Piraino <cpiraino@hashicorp.com>	5 years ago
Kyle Havlovitz	c911174327	Add config entry/state for Ingress Gateways (#7483) ... * Add Ingress gateway config entry and other relevant structs * Add api package tests for ingress gateways * Embed EnterpriseMeta into ingress service struct * Add namespace fields to api module and test consul config write decoding * Don't require a port for ingress gateways * Add snakeJSON and camelJSON cases in command test * Run Normalize on service's ent metadata Sadly cannot think of a way to test this in OSS. * Every protocol requires at least 1 service * Validate ingress protocols * Update agent/structs/config_entry_gateways.go Co-authored-by: Chris Piraino <cpiraino@hashicorp.com> Co-authored-by: Freddy <freddygv@users.noreply.github.com>	5 years ago