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

Document source components for required ports for master and worker nodes #770

Closed
seh opened this issue Apr 25, 2018 · 2 comments
Closed
Assignees
Labels
kind/documentation Categorizes issue or PR as related to documentation. priority/important-longterm Important over the long term, but may not be staffed and/or may need multiple releases to complete.
Milestone

Comments

@seh
Copy link

seh commented Apr 25, 2018

In the "Installing kubeadm" document, the "Check required ports" section indicates the inbound port ranges required for various components and purposes. However, it does not indicate which other components open connections on these ports.

When writing firewall rules for the cluster—such as with AWS security group rules—it's necessary to specify the source of the inbound traffic, whether with IP addresses or logical groups of client machines (security groups). It would help if these "required ports" tables had one more column that indicated from where we can expect the connections on each of these ports to originate.

For instance, I think—but am not sure—that the kubelets on worker nodes connect to the API server, and, conversely, the API server connects to them for kubectl exec and kubectl logs. What else connects to the "Kubelet API" port (10250) on the nodes? How about the "Read-only Kubelet API" port (10255). Does anything connect to the "etcd server client API" ports other than the API server?

I expect that I could resolve these questions after a long period of experimentation, incrementally relaxing the firewall's restrictions by diagnosing the logs, but we could save people that time and effort by documenting the source of this traffic in this table.

I concede that it's possible to write firewall rules that allow this inbound traffic to originate anywhere, but I'd prefer to be more specific.

What keywords did you search in kubeadm issues before filing this one?

install required ports source

Is this a BUG REPORT or FEATURE REQUEST?

FEATURE REQUEST

This is either a defect in the existing documentation or a request to improve the documentation as a feature; I could argue it either way.

What happened?

I studied the documentation, but found that it lacked details that I need in order to write proper firewall rules for my cluster.

What you expected to happen?

The two aforementioned tables would mention which components connect to which others on which ports.

Anything else we need to know?

If we're able to at least collect the facts in subsequent discussion here, I'm willing to submit a PR to update the tables, though the width might be a problem with a fifth column.

@timothysc
Copy link
Member

Agreed, we could definitely expand the docs here.
We have built tools that do this downstream and we should outline.
xref 1: https://github.com/heptiolabs/wardroom
xref 2: https://github.com/heptio/aws-quickstart

@timothysc timothysc added help wanted Denotes an issue that needs help from a contributor. Must meet "help wanted" guidelines. kind/documentation Categorizes issue or PR as related to documentation. priority/important-longterm Important over the long term, but may not be staffed and/or may need multiple releases to complete. labels Apr 25, 2018
@seh
Copy link
Author

seh commented Apr 25, 2018

Thanks. I think I found the pertinent portion of the AWS Quickstart template here.

My current set of rules are narrower and more specific than those, but I have no confidence yet that they're correct. I was trying to express what's in those tables, using a security group for each of the following categories, anticipating that some machines will adopt more than one group:

  • load balancer
  • API server
  • other master components
  • etcd
  • node

@luxas luxas added this to the v1.11 milestone May 15, 2018
@luxas luxas removed the help wanted Denotes an issue that needs help from a contributor. Must meet "help wanted" guidelines. label May 15, 2018
@timothysc timothysc modified the milestones: v1.11, v1.12 Jun 13, 2018
@timothysc timothysc self-assigned this Jul 3, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/documentation Categorizes issue or PR as related to documentation. priority/important-longterm Important over the long term, but may not be staffed and/or may need multiple releases to complete.
Projects
None yet
Development

No branches or pull requests

4 participants