consul

Commit Graph

Author	SHA1	Message	Date
DanStough	2e2c71d2f2	fix: multiple grpc/http2 services for ingress listeners	3 years ago
Paul Banks	2281d883b9	Fix some more Enterprise Normalization issues affecting tests	3 years ago
Paul Banks	4e39f03d5b	Add ingress-gateway config for SDS	3 years ago
Paul Banks	9e4e204e96	Fix enterprise test failures caused by differences in normalizing EnterpriseMeta	3 years ago
Paul Banks	f439dfc04f	Ingress gateway header manip plumbing	3 years ago
Paul Banks	46e4041283	Header manip and validation added for ingress-gateway entries	3 years ago
R.B. Boyer	188e8dc51f	agent/structs: add a bunch more EnterpriseMeta helper functions to help with partitioning (#10669 )	3 years ago
R.B. Boyer	ac50db9087	structs: add some missing config entry validation and clean up tests (#10465 ) Affects kinds: service-defaults, ingress-gateway, terminating-gateway	3 years ago
John Cowen	5892e75452	ui: Remove any trailing fullstop/period DNS characters from Gateways UI API (#9752 ) Previous to this commit, the API response would include Gateway Addresses in the form `domain.name.:8080`, which due to the addition of the port is probably not the expected response. This commit rightTrims any `.` characters from the end of the domain before formatting the address to include the port resulting in `domain.name:8080`	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	f213d3592a	remove obsolete comments about test parallelization	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
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	47238a693d	Merge pull request #7819 from hashicorp/dnephin/remove-t.Parallel-1 test: Remove t.Parallel() from agent/structs tests	5 years ago
Daniel Nephin	e60bb9f102	test: Remove t.Parallel() from agent/structs tests go test will only run tests in parallel within a single package. In this case the package test run time is exactly the same with or without t.Parallel() (~0.7s). In generally we should avoid t.Parallel() as it causes a number of problems with `go test` not reporting failure messages correctly. I encountered one of these problems, which is what prompted this change. Since `t.Parallel` is not providing any benefit in this package, this commit removes it. The change was automated with: git grep -l 't.Parallel' \| xargs sed -i -e '/t.Parallel/d'	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
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
Freddy	137a2c32c6	TLS Origination for Terminating Gateways (#7671 )	5 years ago
Chris Piraino	115d2d5db5	Expect default enterprise metadata in gateway tests (#7664 ) This makes it so that both OSS and enterprise tests pass correctly In the api tests, explicitly set namespace to empty string so that tests can be shared.	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	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

23 Commits (f7b7f5d4b6eba208be422078f4db1165a3dfc13c)