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

Applications bound to localhost behind the Service are reachable when Kuma deployed #4630

Closed
lukidzi opened this issue Jul 18, 2022 · 0 comments · Fixed by #4750
Closed

Applications bound to localhost behind the Service are reachable when Kuma deployed #4630

lukidzi opened this issue Jul 18, 2022 · 0 comments · Fixed by #4750
Assignees
Labels
kind/bug A bug triage/accepted The issue was reviewed and is complete enough to start working on it

Comments

@lukidzi
Copy link
Contributor

lukidzi commented Jul 18, 2022

What happened?

When the application running within a Pod is bind to the localhost, has a Service that exposes it and we deploy Kuma, you can reach the application. But the request to the application bind to podIP is failing. We should be more consistent with migration for users and increase security by not exposing localhost bound applications.

Step to reproduce:

  1. Deploy Kuma
  2. Deploy demo application bound to localhost and expose it by the Service
  3. Install another pod with curl/wget
  4. Request CLUSTER_IP:PORT from the client pod
  5. request will pass

Step to reproduce case with pod IP:

  1. Deploy Kuma
  2. Deploy demo application bound to podIP and expose it by the Service
  3. Install another pod with curl/wget
  4. Request CLUSTER_IP:PORT from the client pod
  5. Request will fail

Deployment without the mesh has different behavior and request to application bound to localhost fail while to podIP its success.

@lukidzi lukidzi added triage/pending This issue will be looked at on the next triage meeting triage/accepted The issue was reviewed and is complete enough to start working on it kind/bug A bug labels Jul 18, 2022
@lukidzi lukidzi self-assigned this Jul 18, 2022
@lukidzi lukidzi removed the triage/pending This issue will be looked at on the next triage meeting label Jul 19, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/bug A bug triage/accepted The issue was reviewed and is complete enough to start working on it
Projects
None yet
1 participant