Skip to content
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

service-mesh: blackhole traffic destined for the TPROXY port #1171

Open
wants to merge 3 commits into
base: main
Choose a base branch
from

Conversation

3u13r
Copy link
Member

@3u13r 3u13r commented Jan 21, 2025

  • blackhole traffic that would cause the envoy to infinitely connect to itself
  • add tests for the envoy config

@3u13r 3u13r force-pushed the euler/fix/service-mesh/blackhole-direct-tproxy-traffic branch from ac085b5 to 47b9850 Compare January 21, 2025 03:56
@3u13r 3u13r changed the title service-mesh: blackhole traffic destined for the TROXY port service-mesh: blackhole traffic destined for the TPROXY port Jan 21, 2025
@3u13r 3u13r force-pushed the euler/fix/service-mesh/blackhole-direct-tproxy-traffic branch from 47b9850 to b62d878 Compare January 21, 2025 03:56
Traffic to the TPROXY port (15006/15007) led to a traffic storm as envoy used the original destination to forward the traffic to, therefore forwarding it again to the TPROXY port where envoy listens.

This commit introduces a Blackhole cluster where we send traffic to, that arrives on the TPROXY listeners and which original destination port is the TPROXY.
@3u13r 3u13r force-pushed the euler/fix/service-mesh/blackhole-direct-tproxy-traffic branch from b62d878 to 85a7740 Compare January 21, 2025 12:51
@3u13r 3u13r added the bug fix Fixing a user facing bug label Jan 21, 2025
With increasing envoy config complexity it gets more difficult to parse the final envoy config.
Therefore we introduce tests which compare the envoy config for specific scenarios with golden JSON representations of the expected output.
@3u13r 3u13r force-pushed the euler/fix/service-mesh/blackhole-direct-tproxy-traffic branch from 85a7740 to 5a6afdd Compare January 21, 2025 12:53
@katexochen katexochen added this to the v1.4.0 milestone Jan 21, 2025
@3u13r 3u13r marked this pull request as ready for review January 21, 2025 13:10
@3u13r 3u13r requested a review from katexochen as a code owner January 21, 2025 13:10
@burgerdev burgerdev self-requested a review January 21, 2025 13:55
service-mesh/config.go Show resolved Hide resolved
continue
}
if len(listener.FilterChains) != 1 {
return fmt.Errorf("listener %s doesn't has exactly one existing listener", listener.Name)
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
return fmt.Errorf("listener %s doesn't has exactly one existing listener", listener.Name)
return fmt.Errorf("listener %s doesn't have exactly one existing listener", listener.Name)

if listenPort == 0 {
return fmt.Errorf("listener %s listens on port 0", listener.Name)
}
if listenPort != 15006 && listenPort != 15007 {
Copy link
Contributor

Choose a reason for hiding this comment

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

Can we make these arguments and use constants where we're calling addBlackHoleToConfig? That'd allow easier customization later on - I've been wondering lately when we'll have the first user that wants these ports for their app :)

Comment on lines +451 to +455
// Blackhole traffic that arrives on the original destination listerners,
// which original port is the envoy itself, i.e. traffic that was not redirected
// to the envoy via the TROXY iptables rule. Such traffic would lead to a
// traffic storm since envoy would connect to the original destination
// i.e. itself again.
Copy link
Contributor

Choose a reason for hiding this comment

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

Please add a sentence that explains how the traffic is blackholed - is it because there is no upstream in the cluster?

Comment on lines +44 to +46
func TestMain(m *testing.M) {
goleak.VerifyTestMain(m)
}
Copy link
Contributor

Choose a reason for hiding this comment

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

Did you introduce this for a specific reason? This binary looks pretty serial...

Copy link
Member Author

Choose a reason for hiding this comment

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

No, I thought we would just add this per convention for new tests, since e.g.,

func TestMain(m *testing.M) {
also looks pretty serial. It looks like at least Malte was of the same opinion, since all the times where this was also "unnecessarily" included are tests he wrote. But I don't have any (strong) opinion about this, does anyone else?

Copy link
Contributor

Choose a reason for hiding this comment

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

I don't, was just curious.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug fix Fixing a user facing bug
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants