Bug 1231127 - Router stats port will be rejected by iptables on ose
Summary: Router stats port will be rejected by iptables on ose
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Networking
Version: 3.2.0
Hardware: All
OS: All
medium
low
Target Milestone: ---
: 4.1.0
Assignee: Dan Mace
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-06-12 08:21 UTC by zhaozhanqi
Modified: 2022-08-04 22:20 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-01-30 18:39:31 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description zhaozhanqi 2015-06-12 08:21:50 UTC
Description of problem:
Create router on ose env, the router stats page cannot be accessed.

Version-Release number of selected component (if applicable):


How reproducible:
always

Steps to Reproduce:
1. Create router with default stats port
   oadm router --credentials=/etc/openshift/master/openshift-router.kubeconfig --images=registry.access.redhat.com/openshift3/ose-haproxy-router:v0.6.0.1
2. the default stats-port is 1936, so access the stats page
   http://$nodeip:1936
3.

Actual results:
The page can not be accessed

Expected results:
The page can be accessed

Additional info:

Checked the iptables, seems it will be rejected with INPUT chain

14   REJECT     all  --  0.0.0.0/0            0.0.0.0/0            reject-with icmp-host-prohibited

When I deleted this chain, the page will be accessed.

Comment 2 Paul Weil 2015-06-12 15:09:18 UTC
Discussed in libra:

<pweil> sdodson, who is the right person to look at ose iptables issues?  https://bugzilla.redhat.com/show_bug.cgi?id=1231127
<sdodson> pweil: I sort of saw that as a one-off thing that admins would enable or disable on their own.
<sdodson> pweil: I think if we want to automate it, we want to default to blocking.
<pweil> sdodson, you ok with me putting it to ON_QA with that comment?
<sdodson> bleanhar: You ok with us not adding iptables rules for haproxy stats port by default?
<sdodson> pweil: Perhaps only from localhost?
<bleanhar> only from localhost sounds ok
<sdodson> pweil: assign it to me, i'll work on having ansible open the port on all hosts that have label infra
<pweil> ok

Comment 3 Scott Dodson 2015-06-12 15:10:36 UTC
We'll look at implementing this in ansible post GA, leaving bug as NEW.

Comment 4 Scott Dodson 2016-01-28 15:57:42 UTC

*** This bug has been marked as a duplicate of bug 1293578 ***

Comment 5 zhaozhanqi 2016-02-22 08:08:38 UTC
since bug 1293578 has been verified, and it can be access using 1936 using 'localhost'

-bash-4.2# curl localhost:1936
<html><body><h1>401 Unauthorized</h1>
You need a valid user and password to access this content.
</body></html>

I'm wondering how to access stats page by public ip since we cannot access it using 'localhost' or internal ip from outside.

-bash-4.2# curl openshift-143.lab.sjc.redhat.com:1936
curl: (7) Failed connect to openshift-143.lab.sjc.redhat.com:1936; No route to host

so we still need to add the following rule to solve the issue:
iptables -I OS_FIREWALL_ALLOW -p tcp -m state --state NEW -m tcp --dport 1936 -j ACCEPT

or do we have another way to resolve this issue?

Comment 6 Scott Dodson 2016-02-22 14:03:30 UTC
Zhao,

I don't think we'll open up port 1936 by default as we'd have to either figure out which hosts are running the router or open it up on all nodes which is undesirable. I think the usefulness of opening 1936 externally is nearly zero. If someone were to write monitoring scripts they'd probably run those scripts on the hosts where the router is running.

I can make sure that we have docs that explain the need to open up port 1936 if you want access to the stats from outside the host.

Do you think that's sufficient?

Brenton, your thoughts on if we should open 1936 by default now that the liveness probe no longer requires it?

Comment 7 Brenton Leanhardt 2016-02-22 14:13:09 UTC
I don't think we should open it up.  Admins will know best if this is secure in their environment.  Like you mentioned the focus of our bug fixes was to ensure the liveness probes could function securely.  I'm find with someone adding a note to our documentation on how to access this page.

Comment 8 Evgheni Dereveanchin 2016-04-01 08:02:17 UTC
There are some use cases when opening port 1936 is needed: for example in cases when there's a load balancer in front of HA routers, which has to monitor health of the actual router. In this case port 1936 will not be accessible from the Internet, yet it has to be open on nodes. 

I think there has to be an option, or at least documentation on how to do this with Ansible to ensure all newly added hosts have the port open, as well as ensuring updates don't close this port.

Comment 9 Josep 'Pep' Turro Mauri 2016-04-01 12:47:10 UTC
For special needs it should be fine to have custom firewall rules, but these would be added/managed outside of the OpenShift installer. The installer can't (and probably shouldn't) aim to cover all potential customizations.

The requirement here would be that the installer does not interfere with them, but this should already be the case.

Will create a kbase entry to document how to open that port for that purpose and link it here. Let me know if that's not enough.

Comment 10 Ben Bennett 2017-06-22 20:53:49 UTC
Closing because this is the admin's responsibility to open.

Comment 11 Robert Bost 2018-10-08 16:09:20 UTC
> I think the usefulness of opening 1936 externally is nearly zero. If someone were to write monitoring scripts they'd probably run those scripts on the hosts where the router is running.

I'd like to reopen this bug for reconsideration since the addition of Prometheus monitoring to OpenShift. The Prometheus installation playbook configures monitoring via router.default.svc:1936. This requires port 1936 to be opened on the node where the router is running. 

It is awkard to have the completely automated Prometheus installation playbook and then one manual step of opening the port. Can the iptables rule be included in the playbook?


Note You need to log in before you can comment on or make changes to this bug.