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

enhancement: add tunnel server internal service in order to prevent x-tunnel-server-svc attached SLB to listen unsecure port #284

Merged
merged 1 commit into from
Apr 28, 2021

Conversation

rambohe-ch
Copy link
Member

@rambohe-ch rambohe-ch commented Apr 27, 2021

Ⅰ. Describe what this PR does

  • background:

    1. In order to deploy promtheus(also metrics-server) and yurt-tunnel-server on different cloud nodes, prometheus need to use {hostname:port} (take port=9100 as a example) to access edge node through yurt-tunnel-server and yurt-tunnel-agent and resolve hostname to service ip of yurt-tunnel-server. on the same time, we need to add 9100:10264 mapping info in yurt-tunnel-server service for redirect port.
    2. the original yurt-tunnel-server service(x-tunnel-server-svc) is used by yurt-tunnel-agent to connect yurt-tunnel-server. and x-tunnel-server-svc service may be configured as NodePort type or LoadBalancer type for public network access.
    3. If x-tunnel-server-svc service type is LoadBalancer, the proxy ports in x-tunnel-service-svc service will be listened by corresponding SLB(in public cloud. but listen internal port(9100) on public network will cause security risks.
  • solution:
    we can add a new service(type=ClusterIP) named x-tunnel-server-internal-svc for yurt-tunnel-server, so x-tunnel-server-svc service is used for public network access, and newly added service is used for internal component(like prometheus/metrics server) access. and internal port mapping(like above 9100:10264) will only be added in x-tunnel-server-internal-svc svc. so security risk can be solved.

Ⅱ. Does this pull request fix one issue?

Ⅲ. List the added test cases (unit test/integration test) if any, please explain if no tests are needed.

Ⅳ. Describe how to verify it

make all
and make sure the yurt-tunnel can work with dns

Ⅴ. Special notes for reviews

…-tunnel-server-svc

attached SLB to listen unsecure port.
Copy link
Member

@SataQiu SataQiu left a comment

Choose a reason for hiding this comment

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

LGTM
defer @Fei-Guo for more reviews

@Fei-Guo
Copy link
Member

Fei-Guo commented Apr 28, 2021

The major use case of keeping the x-tunnel-server-svc is to allow the tunnel-agent (sit in edge node) to find the tunnel-server (sit in cloud) through the public IP (i.e., the node public IP) + nodeport. It seems that this change does not incur user experience changes.

LGTM.

@Fei-Guo Fei-Guo merged commit ebca595 into openyurtio:master Apr 28, 2021
@rambohe-ch rambohe-ch deleted the add-internal-tunnel-svc branch May 27, 2021 06:26
MrGirl pushed a commit to MrGirl/openyurt that referenced this pull request Mar 29, 2022
…-tunnel-server-svc (openyurtio#284)

attached SLB to listen unsecure port.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants