
SaltStack を使用して柔軟な iptables 管理ソリューションを構成しようとしていますが、思ったよりも難しいと感じています。
私の主な要件は、すべてのミニオンの SSH アクセス用にホワイトリストに登録する必要がある IP のリストを保持するピラーを作成できるようにすることです。この IP リストは、もちろん時々変更されます。一部の IP は追加され、一部の IP は削除されます。私が直面している問題は、削除された IP に関するものです。ピラー ファイルから IP を削除しても、SaltStack はミニオンから実際のホワイトリストを削除しません。
私が見つけた唯一の回避策は、「removed-ips」という名前の新しいキーを作成し、IP を削除したいときはいつでもそこに追加することでした。2 番目の for ループで IP が削除されます。もちろん、これは本当に厄介な回避策ですが、もっと良い方法はないでしょうか?
/srv/pillar/iptables-default.sls:
iptables-default:
whitelisted-ips:
- '55.55.55.55'
- '66.66.66.66'
- '77.77.77.77'
removed-ips:
- '88.88.88.88'
/srv/salt/iptables-default.sls:
{% for ip in salt['pillar.get']('iptables-default:whitelisted-ips') %}
Whitelist OSF IP {{ip}} for SSH access:
iptables.append:
- table: filter
- family: ipv4
- chain: INPUT
- jump: ACCEPT
- match: state
- connstate: NEW
- source: '{{ ip }}'
- dport: 22
- proto: tcp
- save: True
{% endfor %}
{% for ip in salt['pillar.get']('iptables-default:removed-ips') %}
Remove old IPs that are not needed anymore:
iptables.delete:
- table: filter
- family: ipv4
- chain: INPUT
- jump: ACCEPT
- match: state
- connstate: NEW
- source: {{ ip }}
- dport: 22
- proto: tcp
- save: True
{% endfor %}
答え1
Saltでさまざまなiptables設定を管理する最良の方法を見つけるのに数時間を費やしましたが、最良の解決策は、
- フラットな iptables 設定ファイル (jinja テンプレートとして)
- フラットファイルが変更された場合のみ、salt に iptables のフラッシュと復元を実行させる
これは私の環境でのやり方で、非常にうまく機能しています。Iptablesのsaltステートを使ってみましたが、非常に面倒で管理しにくく、iptables.flush
highstateを実行するたびに強制的に行う必要があります。
以下は、柱の使用を完全に回避する、よりシンプルで管理しやすいアプローチです。
{{ grains.id }}.j2 をレイアウトとして使用して各ホストのフラットファイルを作成します。
cat /srv/salt/state/iptables/files/nycweb1.j2
##############################################################
## This file is managed by SALTSTACK - Do not modify manually
##############################################################
*filter
:INPUT ACCEPT
:FORWARD ACCEPT
:OUTPUT ACCEPT
## Allow all loopback (lo0) traffic
-A INPUT -i lo -j ACCEPT
## Drop all traffic to 127/8 that doesn't use lo0
-A INPUT ! -i lo -d 127.0.0.0/8 -j DROP
## Accept inbound traffic for already established connections.
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
## Effectively allow all outbound traffic.
-A OUTPUT -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
## Allow ping
-A INPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT
## Blacklist
-A INPUT -s 0.0.0.0/32 -p tcp -m tcp --dport 22 -j REJECT --reject-with icmp-port-unreachable
## Whitelist
-A INPUT -s 121.236.129.235/32 -p tcp -m tcp --dport 22 -j ACCEPT {# NY office pub #}
-A INPUT -s 192.168.10.0/24 -p tcp -m tcp --dport 22 -j ACCEPT {# NY office priv #}
COMMIT
*nat
:PREROUTING ACCEPT
:INPUT ACCEPT
:OUTPUT ACCEPT
:POSTROUTING ACCEPT
-A PREROUTING -p tcp -m tcp --dport 27015 -j DNAT --to-destination 192.168.38.20
-A OUTPUT -p tcp -m addrtype --src-type LOCAL --dst-type LOCAL -m tcp --dport 1266 -j DNAT --to-destination 169.254.1.1:443
-A POSTROUTING -s 192.168.1.2/32 -d 10.3.4.65/32 -p tcp -m tcp --dport 48854 -j MASQUERADE
-A POSTROUTING -d 10.0.2.15/24 -p tcp -m tcp --dport 27045 -j SNAT --to-source 192.168.99.11 {# description #}
COMMIT
{# EOF #}
状態ファイルを作成する
cat /srv/salt/state/iptables/init.sls
# STATE - IPTABLES
{% set iptables_file = '/etc/sysconfig/iptables' %}
iptables_pkg:
pkg.installed:
- name: iptables
{{ iptables_file }}:
file.managed:
- user: root
- group: root
- mode: 644
- source: salt://{{ slspath }}/files/{{ grains.id }}.j2
- template: jinja
flush_tables:
iptables.flush:
- table: filter
- family: ipv4
- onchanges:
- file: "{{ iptables_file }}"
restore_tables:
cmd.run:
- name: "/usr/sbin/iptables-restore < {{ iptables_file }}"
- onchanges:
- file: "{{ iptables_file }}"
ターゲットでhighstateを実行すると、フラットファイルが変更されたときにのみflush+restoreが実行されます。設定はネイティブiptables形式であり、ピラー形式ではありません。
状態を適用するか、ハイステートに追加します
salt nycweb01 state.sls iptables
答え2
このような場合、iptables で使用する IP アドレスのリストを保持するために、「ipset」構成ファイルをテンプレート化し、許可リストまたは拒否リストでそれらを参照する iptables ルールを使用します。ipset は大規模なセットに効果があり、このように管理することで「アドレスの削除」の問題が解消されます。何かが変更されるたびに、セットが完全に再ロードされます。
私たちは、厳格なメンバーシップとアクセス要件を持つ何千ものサーバーのネットワークを集中管理しているので、salt と jinja テンプレートを使用して /etc/sysconfig/ipset をレンダリングすることは理にかなっています。