OpenShift Origin 3.11集群安全加固咨询及iptables规则疑问

Hey Francesco, great question—let’s walk through how to harden your OpenShift Origin 3.11 cluster properly, since those DDoS reflection issues are a clear sign we need to tighten things up.

Short answer: Avoid directly editing the KUBE- or OPENSHIFT- chains**—OpenShift’s network components (like kube-proxy) will overwrite these rules whenever the node restarts or the service reloads. Instead, use OpenShift’s built-in mechanisms to add custom, persistent rules:

• Use the OPENSHIFT-FIREWALL-ALLOW or OS_FIREWALL_ALLOW chains (these are reserved for user-defined rules and won’t be overwritten by OpenShift).
• For node-level firewall management, use firewalld (preferred for RHEL/CentOS-based nodes) or edit /etc/sysconfig/iptables (if using the legacy iptables service) to add your rules before the OpenShift-managed chains are loaded.

Let’s break down actionable steps to fix your current issues and harden the cluster long-term:

a. Lock Down Node Firewalls (Starting with Compute Nodes) #

Changing the INPUT chain default policy to DROP on compute nodes is a smart move—just make sure you explicitly allow all necessary traffic first to avoid breaking cluster communication. Here’s what you need to keep:

• Cluster internal traffic: Your existing rules allowing traffic from node1, node2, and master are critical—keep these.
• OpenShift core ports: Ensure rules for 10250 (kubelet), 4789 (VXLAN), 2379/2380 (etcd, master-only), and NodePort ranges (default 30000-32767) are allowed.
• Permanent port blocks: For the Dnsmasq/portmapper issues, make your port blocks persistent (instead of temporary iptables rules):

  # Block public access to 53 (DNS) and 111 (portmapper)
  firewall-cmd --add-rich-rule='rule family="ipv4" source address="0.0.0.0/0" port port="53" protocol="udp" reject' --permanent
  firewall-cmd --add-rich-rule='rule family="ipv4" source address="0.0.0.0/0" port port="111" protocol="tcp" reject' --permanent
  firewall-cmd --add-rich-rule='rule family="ipv4" source address="0.0.0.0/0" port port="111" protocol="udp" reject' --permanent
  firewall-cmd --reload
  

b. Secure Dnsmasq and Portmapper Services #

• Dnsmasq: OpenShift uses this for internal DNS—ensure it only listens on your cluster’s private IP range (e.g., 10.128.0.0/14) instead of all interfaces. Check the dnsmasq config at /etc/origin/node/dnsmasq.conf and set listen-address to your node’s private IP, not 0.0.0.0.
• Portmapper (rpcbind): If you aren’t using NFS or other RPC-based services, disable it entirely:

  systemctl disable --now rpcbind
  systemctl disable --now rpcbind.socket
  

  If you need it, configure it to only listen on cluster internal IPs by editing /etc/sysconfig/rpcbind and adding OPTIONS="-h <your-private-node-ip>".

c. Clean Up Unnecessary Open Ports #

Looking at your iptables -L output, the OS_FIREWALL_ALLOW chain opens a lot of unused ports (like 24007, iscsi-target, senomix02). Remove any rules for services you aren’t running—this reduces your attack surface significantly. You can do this via firewalld’s remove-rich-rule command or by editing the iptables config file directly.

d. Add Cluster-Level Network Isolation #

Enable OpenShift NetworkPolicies to control traffic between pods. Even if node firewalls are open, NetworkPolicies let you restrict which pods can communicate with each other (e.g., only allow app pods to access DNS pods). For example, a basic policy to restrict DNS access to internal pods:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: restrict-dns-access
  namespace: default
spec:
  podSelector:
    matchLabels:
      k8s-app: dns
  ingress:
  - from:
    - podSelector: {} # Allow all pods in the same namespace; adjust as needed

e. Additional Hardening Tips #

• Update regularly: Even though 3.11 is an older release, apply security patches for OpenShift and your underlying OS to fix known vulnerabilities.
• Monitor traffic: Use tools like tcpdump, iftop, or Prometheus+Grafana to watch for unusual traffic patterns (like unexpected DNS/portmapper requests from the public internet).
• Limit public exposure: Only expose critical services (OpenShift console, your apps) to the internet. Keep internal services (etcd, kubelet) restricted to cluster IPs.

Before rolling out changes to all nodes:

1. Test on a single compute node first.
2. Verify node health with oc get nodes—ensure the node stays in Ready state.
3. Test pod-to-pod communication and external access to your exposed services.
4. Double-check iptables rules with iptables -L -n to confirm your custom rules are active.

内容的提问来源于stack exchange，提问作者FrancescoM