TLS/SSLおよびファイアウォールルールを使用してCoreOSクラスターを保護する方法

序章

共有データセンター内やパブリックインターネット全体など、制御外のネットワーク環境でCoreOSクラスターを実行することを計画している場合、etcdが暗号化されていないHTTP要求を行うことによって通信することに気付いたかもしれません。 クラスター内の各ノードにIPTablesファイアウォールを構成することで、その動作のリスクを軽減することは可能ですが、完全なソリューションでは、暗号化されたトランスポート層を使用するのが理想的です。

幸い、etcdはピアツーピアTLS/ SSL接続をサポートしているため、クラスターの各メンバーが認証され、すべての通信が暗号化されます。 このガイドでは、まず3つのメンバーで単純なクラスターをプロビジョニングし、次に各マシンでHTTPSエンドポイントと基本的なファイアウォールを構成します。

前提条件

このガイドは、このCoreOSシステムコンポーネントの概要およびこのガイドのDigitalOceanでのCoreOSクラスターのセットアップで説明されている概念に基づいています。

etcd、fleetctl、cloud-configファイルの基本と、検出URLの生成に精通している必要があります。

クラスタ内のマシンを作成してアクセスするには、DigitalOceanアカウントに関連付けられたSSH公開鍵が必要です。 DigitalOceanでのSSHキーの使用の詳細については、こちらを参照してください。

DigitalOcean APIを使用してCoreOSマシンを作成する場合は、書き込み権限を持つパーソナルアクセストークンを生成して使用する方法について、このチュートリアルを参照してください。 APIの使用はオプションですが、特に大規模なクラスターの構築が予想される場合は、長期的には時間を節約できる可能性があります。

新しい検出URLを生成する

ブラウザでhttps://discovery.etcd.io/new?size=3にアクセスし、表示されたURLをコピーして、Discovery.etcd.ioから新しい検出URLを取得します。 、またはローカルマシンの端末からcurlを使用して：

curl -w "\n" "https://discovery.etcd.io/new?size=3"

返されたURLを保存します。 間もなくcloud-configで使用します。

HTTPS構成を含むCloud-Configファイルを作成する

cloud-configを書くことから始めましょう。 cloud-configは、各サーバーを初期化するときにユーザーデータとして提供され、クラスターの重要な構成の詳細を定義します。 このファイルは長くなりますが、基本クラスターガイドのバージョンよりもはるかに複雑になることはありません。 fleetにHTTPSエンドポイントを使用するように明示的に指示し、ファイアウォールに対してiptables-restoreというサービスを有効にし、etcdとfleetに指示する構成ファイルを書き出します。 SSL証明書を検索します。

ローカルマシンでターミナルを開き、ホームディレクトリにいることを確認し、nano（またはお気に入りのテキストエディタ）を使用して~/cloud-config.ymlを作成して開きます。

cd ~
nano cloud-config.yml

以下を貼り付けてから、etcd2セクションのhttps://discovery.etcd.io/tokenを、前のセクションで要求した検出URLに変更します。

ファイアウォールを有効にしたくない場合は、iptables-restoreセクションを削除することもできます。

貼り付けるときはインデントに注意してください。 cloud-configは、空白に敏感なYAMLで記述されています。 特定の行に関する情報については、ファイル内のコメントを参照してください。その後、いくつかの重要なセクションについて詳しく説明します。

〜/ cloud-config.yml

#cloud-config

coreos:
  etcd2:
    # generate a new token for each unique cluster from https://discovery.etcd.io/new:
    discovery: https://discovery.etcd.io/token
    # multi-region deployments, multi-cloud deployments, and Droplets without
    # private networking need to use $public_ipv4:
    advertise-client-urls: https://$private_ipv4:2379,https://$private_ipv4:4001
    initial-advertise-peer-urls: https://$private_ipv4:2380
    # listen on the official ports 2379, 2380 and one legacy port 4001:
    listen-client-urls: https://0.0.0.0:2379,https://0.0.0.0:4001
    listen-peer-urls: https://$private_ipv4:2380
  fleet:
    # fleet defaults to plain HTTP - explicitly tell it to use HTTPS on port 4001:
    etcd_servers: https://$private_ipv4:4001
    public-ip: $private_ipv4   # used for fleetctl ssh command
  units:
    - name: etcd2.service
      command: start
    - name: fleet.service
      command: start
    # enable and start iptables-restore
    - name: iptables-restore.service
      enable: true
      command: start
write_files:
  # tell etcd2 and fleet where our certificates are going to live:
  - path: /run/systemd/system/etcd2.service.d/30-certificates.conf
    permissions: 0644
    content: |
      [Service]
      # client environment variables
      Environment=ETCD_CA_FILE=/home/core/ca.pem
      Environment=ETCD_CERT_FILE=/home/core/coreos.pem
      Environment=ETCD_KEY_FILE=/home/core/coreos-key.pem
      # peer environment variables
      Environment=ETCD_PEER_CA_FILE=/home/core/ca.pem
      Environment=ETCD_PEER_CERT_FILE=/home/core/coreos.pem
      Environment=ETCD_PEER_KEY_FILE=/home/core/coreos-key.pem
  - path: /run/systemd/system/fleet.service.d/30-certificates.conf
    permissions: 0644
    content: |
      [Service]
      # client auth certs
      Environment=FLEET_ETCD_CAFILE=/home/core/ca.pem
      Environment=FLEET_ETCD_CERTFILE=/home/core/coreos.pem
      Environment=FLEET_ETCD_KEYFILE=/home/core/coreos-key.pem

オプションの手順として、cloud-configを公式のCoreOSCloud Config Validator に貼り付け、 ValidateCloud-Configを押すことができます。

ファイルを保存して終了します。 nanoでは、 Ctrl-X を使用して終了し、 y を使用してファイルの書き込みを確認し、Enterを使用してファイル名を確認します。保存する。

cloud-init.ymlのいくつかの特定のブロックを見てみましょう。 まず、fleetの値は次のとおりです。

  fleet:
    # fleet defaults to plain HTTP - explicitly tell it to use HTTPS:
    etcd_servers: https://$private_ipv4:4001
    public-ip: $private_ipv4   # used for fleetctl ssh command

etcd_serversがhttpsURLに設定されていることに注意してください。 プレーンHTTP操作の場合、この値を設定する必要はありません。 ただし、明示的な構成がないと、HTTPSは失敗します。 （$private_ipv4は、CoreOS初期化プロセスによって理解される変数であり、変更する必要のある変数ではありません。）

次に、write_filesブロックに移動します。 値は、ファイルシステムpath、permissionsマスク、およびcontentに分割されます。このマスクには、ファイルの目的の内容が含まれています。 ここでは、etcd2およびfleetサービスのsystemdユニットファイルが、生成するTLS/SSL証明書を指す環境変数を設定する必要があることを指定します。

write_files:
  # tell etcd2 and fleet where our certificates are going to live:
  - path: /run/systemd/system/etcd2.service.d/30-certificates.conf
    permissions: 0644
    content: |
      [Service]
      # client environment variables
      Environment=ETCD_CA_FILE=/home/core/ca.pem
      ...
  - path: /run/systemd/system/fleet.service.d/30-certificates.conf
    permissions: 0644
    content: |
      [Service]
      # client auth certs
      Environment=FLEET_ETCD_CAFILE=/home/core/ca.pem
      ...

証明書ファイルの場所をサービスに通知しますが、ファイル自体を提供することはまだできません。 そのためには、各CoreOSマシンのプライベートIPアドレスを知る必要があります。これは、マシンが作成された後にのみ使用可能になります。

注： CoreOSドロップレットでは、ドロップレットの作成後にcloud-configの内容を変更することはできず、ファイルは起動のたびに再実行されます。 クラスターの構築後に変更する予定の構成には、write-filesセクションを使用しないでください。これは、次にドロップレットが起動したときにリセットされるためです。

ドロップレットをプロビジョニングする

cloud-config.ymlが定義されたので、これを使用してクラスターの各メンバーをプロビジョニングします。 DigitalOceanでは、2つの基本的なアプローチをとることができます。Webベースのコントロールパネルを使用する方法と、コマンドラインからcURLを使用してDigitalOceanAPIを呼び出す方法です。

DigitalOceanコントロールパネルの使用

同じデータセンターリージョン内に3つの新しいCoreOSドロップレットを作成します。 毎回プライベートネットワークとユーザーデータを有効にするを確認してください。

• coreos-1
• coreos-2
• coreos-3

ユーザーデータフィールドに、上からcloud-config.ymlの内容を貼り付け、ファイルの上部にあるdiscoveryフィールドに検出URLを挿入したことを確認します。

DigitalOceanAPIの使用

フィールドへの繰り返しの貼り付けを節約できる代替アプローチとして、curlを使用してcloud-configを使用してDigitalOceanAPIから新しいドロップレットをリクエストする短いBashスクリプトを記述し、各液滴。 nano（または選択したテキストエディタ）を使用して、makecoreos.shという新しいファイルを開きます。

cd ~
nano makecoreos.sh

次のスクリプトを貼り付けて保存し、クラスターに必要なregionおよびsizeフィールドを調整します（デフォルトのnyc3および512mbはデモンストレーションに適しています目的ですが、実際のプロジェクトでは別の地域またはより大きなドロップレットが必要になる場合があります）：

〜/ makecoreos.sh

#!/usr/bin/env bash

# A basic Droplet create request.
curl -X POST "https://api.digitalocean.com/v2/droplets" \
     -d'{"name":"'"$1"'","region":"nyc3","size":"512mb","private_networking":true,"image":"coreos-stable","user_data":
"'"$(cat ~/cloud-config.yml)"'",
         "ssh_keys":[ "'$DO_SSH_KEY_FINGERPRINT'" ]}' \
     -H "Authorization: Bearer $TOKEN" \
     -H "Content-Type: application/json"

次に、環境変数$DO_SSH_KEY_FINGERPRINTと$TOKENを、それぞれDigitalOceanアカウントとAPIパーソナルアクセストークンに関連付けられたSSHキーのフィンガープリントに設定しましょう。

パーソナルアクセストークンの取得とAPIの使用については、このチュートリアルを参照してください。

アカウントに関連付けられているキーのフィンガープリントを見つけるには、SSHキーの下にあるアカウント設定のセキュリティセクションを確認してください。 これは、公開鍵指紋の形式になり、43:51:43:a1:b5:fc:8b:b7:0a:3a:a9:b1:0f:66:73:a8のようなものになります。

ここではexportを使用して、makecoreos.shなどのシェルの子プロセスが変数にアクセスできるようにします。 スクリプトを使用するときは常に、両方を現在のシェルに設定する必要があります。そうしないと、API呼び出しが失敗します。

export DO_SSH_KEY_FINGERPRINT="ssh_key_fingerprint"
export TOKEN="your_personal_access_token"

注： APIのパーソナルアクセストークンを生成したばかりの場合は、手元に置いて安全に保管することを忘れないでください。 最初の作成時に表示された後でそれを取得する方法はありません。トークンを持っている人は誰でも、DigitalOceanアカウントを制御できます。

必要なクレデンシャルごとに環境変数を設定したら、スクリプトを実行して目的の各ドロップレットを作成できます。 makecoreos.shは、最初のパラメーターを使用して、APIの呼び出しでnameフィールドに入力します。

bash makecoreos.sh coreos-1
bash makecoreos.sh coreos-2
bash makecoreos.sh coreos-3

新しい各ドロップレットを説明するJSON出力が表示され、3つすべてがコントロールパネルのドロップレットのリストに表示されます。 起動が完了するまでに数秒かかる場合があります。

coreos-1にログインします

コントロールパネルとAPIのどちらを使用した場合でも、3つのドロップレットが実行されているはずです。 ここで、パブリックIPとプライベートIPをメモしてください。これらは、コントロールパネルの個々のドロップレットをクリックしてから、設定リンクをクリックすることで利用できます。 証明書を生成してファイアウォールを構成するときに、各ドロップレットのプライベートIPアドレスが必要になります。

ドロップレットをテストしてみましょう。 SSHキーがローカルSSHエージェントに追加されていることを確認してください。

eval $(ssh-agent)
ssh-add

DigitalOceanコントロールパネルでcoreos-1のパブリックIPアドレスを見つけ、SSHエージェント転送をオンにして接続します。

ssh -A core@coreos-1_public_ip

クラスタのいずれかのメンバーに最初にログインすると、systemdからエラーメッセージが表示される可能性があります。

OutputCoreOS stable (766.5.0)
Failed Units: 1
  iptables-restore.service

これは、ファイアウォールがまだ構成されていないことを示しています。 今のところ、このメッセージは無視しても問題ありません。 （cloud-configでファイアウォールを有効にしないことを選択した場合、エラーメッセージは表示されません。 iptables-restoreサービスは後でいつでも有効にできます。）

ファイアウォールについて心配する前に、クラスターの各メンバーのetcd2インスタンスが相互に通信できるようにしましょう。

CFSSLを使用して自己署名証明書を生成する

CFSSL は、CloudFlareによって公開されているTLS/SSL証明書を操作するためのツールキットです。 この記事の執筆時点では、OpenSSLや現在は廃止されているetcd-caよりも、自己署名証明書を生成するためにCoreOSメンテナーが選択したツールです。

ローカルマシンにCFSSLをインストールする

CFSSLをソースからインストールするには、Goのインストールが機能している必要があります。 Goをインストールするためのこのガイドを参照してください。

$GOPATHが正しく設定され、$PATHに追加されていることを確認してから、go getを使用してcfsslコマンドをインストールします。

export GOPATH=~/gocode
export PATH=$PATH:$GOPATH/bin
go get -u github.com/cloudflare/cfssl/cmd/cfssl
go get -u github.com/cloudflare/cfssl/...

別のアプローチとして、事前に作成されたバイナリをpkg.cfssl.orgから取得できます。 まず、~/binが存在し、パス内にあることを確認します。

mkdir -p ~/bin
export PATH=$PATH:~/bin

次に、curlを使用して、プラットフォームのcfsslおよびcfssljsonの最新バージョンを取得します。

curl -s -L -o ~/bin/cfssl https://pkg.cfssl.org/R1.1/cfssl_linux-amd64
curl -s -L -o ~/bin/cfssljson https://pkg.cfssl.org/R1.1/cfssljson_linux-amd64

cfsslバイナリが実行可能であることを確認してください。

chmod +x ~/bin/cfssl
chmod +x ~/bin/cfssljson

認証局を生成する

cfsslコマンドがインストールされたので、それらを使用して、各CoreOSマシンの証明書に署名するために使用するカスタム認証局を生成できます。 これらのファイルを次の場所に格納するための新しいディレクトリを作成して入力することから始めましょう。

mkdir ~/coreos_certs
cd ~/coreos_certs

次に、nano（またはお気に入りのテキストエディタ）でca-config.jsonを作成して開きます。

nano ca-config.json

cfsslが署名を行う方法を構成する以下を貼り付けて保存します。

〜/ coreos_certs / ca-config.json

{
    "signing": {
        "default": {
            "expiry": "43800h"
        },
        "profiles": {
            "client-server": {
                "expiry": "43800h",
                "usages": [
                    "signing",
                    "key encipherment",
                    "server auth",
                    "client auth"
                ]
            }
        }
    }
}

ここで注目すべきは、現在43800時間（または5年）に設定されているexpiryと、server authとclient authの両方の使用法を含むclient-serverプロファイルです。 。 ピアツーピアTLSには、これらの両方が必要です。

次に、ca-csr.jsonを作成して開きます。

nano ca-csr.json

以下を貼り付けて、場所と組織に合わせてCNとnamesアレイを調整します。 hostsエントリ、場所、組織名には架空の値を使用しても安全です。

〜/ coreos_certs / ca-csr.json

{
    "CN": "My Fake CA",
    "hosts": [
        "example.net",
        "www.example.net"
    ],
    "key": {
        "algo": "rsa",
        "size": 2048
    },
    "names": [
        {
            "C": "US",
            "L": "CO",
            "O": "My Company",
            "ST": "Lyons",
            "OU": "Some Org Unit"
        }
    ]
}

これらをca-config.jsonおよびca-csr.jsonのデフォルト値と比較する場合は、cfsslを使用してデフォルトを印刷できます。 ca-config.jsonには、次を使用します。

cfssl print-defaults config

ca-csr.jsonには、次を使用します。

cfssl print-defaults csr

ca-csr.jsonとca-config.jsonを配置して、認証局を生成します。

cfssl gencert -initca ca-csr.json | cfssljson -bare ca -

CoreOSマシンの証明書を生成して署名する

認証局ができたので、CoreOSマシンのデフォルトを記述できます。

coreos-1.jsonを作成して開きます：

nano coreos-1.json

以下を貼り付けて保存し、 coreos-1 のプライベートIPアドレスに合わせて調整します（個々のドロップレットをクリックすると、DigitalOceanコントロールパネルに表示されます）。

〜/ coreos_certs / coreos-1.json

{
    "CN": "coreos-1",
    "hosts": [
        "coreos-1",
        "coreos-1.local",
        "127.0.0.1",
        "coreos-1_private_ip"
    ],
    "key": {
        "algo": "rsa",
        "size": 2048
    },
    "names": [
        {
            "C": "US",
            "L": "Lyons",
            "ST": "Colorado"
        }
    ]
}

最も重要な部分は、ホスト名であるCNと、次のすべてを含む必要があるhostsアレイです。

• ローカルホスト名
• 127.0.0.1
• CoreOSマシンのプライベートIPアドレス（公開IPではない）

これらは、subjectAltNamesとして結果の証明書に追加されます。 etcd接続（127.0.0.1のローカルループバックデバイスへの接続を含む）では、証明書に接続ホスト名と一致するSANが必要です。

必要に応じて、names配列を変更して現在地を反映することもできます。 繰り返しになりますが、地名には架空の値を使用しても安全です。

残りのマシンごとにこのプロセスを繰り返し、適切なhostsエントリを使用して一致するcoreos-2.jsonおよびcoreos-3.jsonを作成します。

注： coreos-1.jsonのデフォルト値を確認したい場合は、cfsslを使用できます。

cfssl print-defaults csr

次に、CoreOSマシンごとに、署名付き証明書を生成し、正しいマシンにアップロードします。

cfssl gencert -ca=ca.pem -ca-key=ca-key.pem -config=ca-config.json -profile=client-server coreos-1.json | cfssljson -bare coreos
chmod 0644 coreos-key.pem
scp ca.pem coreos-key.pem coreos.pem core@coreos-1_public_ip:

これにより、3つのファイル（ca.pem、coreos-key.pem、およびcoreos.pem）が作成され、キーファイルのアクセス許可が正しいことを確認し、scpを介して[ coreos-1上のX149X]coreのホームディレクトリ。

コマンドを呼び出すたびに前の証明書ファイルのセットが上書きされることに注意して、残りのマシンごとにこのプロセスを繰り返します。

cfssl gencert -ca=ca.pem -ca-key=ca-key.pem -config=ca-config.json -profile=client-server coreos-2.json | cfssljson -bare coreos
chmod 0644 coreos-key.pem
scp ca.pem coreos-key.pem coreos.pem core@coreos-2_public_ip:

cfssl gencert -ca=ca.pem -ca-key=ca-key.pem -config=ca-config.json -profile=client-server coreos-3.json | cfssljson -bare coreos
chmod 0644 coreos-key.pem
scp ca.pem coreos-key.pem coreos.pem core@coreos-3_public_ip:

coreos-1のetcd2機能を確認してください

証明書があれば、coreos-1でfleetctlを実行できるはずです。 まず、SSH経由でログインします。

ssh -A core@coreos-1_public_ip

次に、クラスター内のすべてのマシンを一覧表示してみてください。

fleetctl list-machines

プライベートIPアドレスとともにリストされた各マシンの識別子が表示されます。

OutputMACHINE     IP      METADATA
7cb57440... 10.132.130.187  -
d91381d4... 10.132.87.87    -
eeb8726f... 10.132.32.222   -

fleetctlが無期限にハングする場合は、クラスターを再起動する必要がある場合があります。 ローカルマシンに戻ります。

exit

SSHを使用して、rebootコマンドを各CoreOSマシンに送信します。

ssh core@coreos-1_public_ip 'sudo reboot'
ssh core@coreos-2_public_ip 'sudo reboot'
ssh core@coreos-3_public_ip 'sudo reboot'

しばらく待ってから、 coreos-1 に再接続して、fleetctlを再試行してください。

クラスターメンバーにIPTablesファイアウォールを構成する

証明書が設定されていると、ローカルネットワーク上の他のマシンがクラスターを制御したり、etcd2から値を抽出したりすることは不可能になります。 それでも、可能であれば、利用可能な攻撃対象領域を減らすことをお勧めします。 ネットワークの露出を制限するために、各マシンにいくつかの単純なファイアウォールルールを追加して、クラスター内のピア以外のソースからのほとんどのローカルネットワークトラフィックをブロックできます。

cloud-configでiptables-restoreサービスを有効にした場合、CoreOSマシンに最初にログインしたときにsystemdエラーメッセージが表示されることに注意してください。

OutputCoreOS stable (766.5.0)
Failed Units: 1
  iptables-restore.service

これにより、サービスは有効になっているのに、iptables-restoreが正しくロードされなかったことがわかります。 systemctlを使用してこれを診断できます。

systemctl status -l iptables-restore

Output● iptables-restore.service - Restore iptables firewall rules
   Loaded: loaded (/usr/lib64/systemd/system/iptables-restore.service; enabled; vendor preset: disabled)
   Active: failed (Result: exit-code) since Wed 2015-11-25 00:01:24 UTC; 27min ago
  Process: 689 ExecStart=/sbin/iptables-restore /var/lib/iptables/rules-save (code=exited, status=1/FAILURE)
 Main PID: 689 (code=exited, status=1/FAILURE)

Nov 25 00:01:24 coreos-2 systemd[1]: Starting Restore iptables firewall rules...
Nov 25 00:01:24 coreos-2 systemd[1]: iptables-restore.service: Main process exited, code=exited, status=1/FAILURE
Nov 25 00:01:24 coreos-2 systemd[1]: Failed to start Restore iptables firewall rules.
Nov 25 00:01:24 coreos-2 iptables-restore[689]: Can't open /var/lib/iptables/rules-save: No such file or directory
Nov 25 00:01:24 coreos-2 systemd[1]: iptables-restore.service: Unit entered failed state.
Nov 25 00:01:24 coreos-2 systemd[1]: iptables-restore.service: Failed with result 'exit-code'.

ここには多くの情報がありますが、最も有用な行はiptables-restore[689]を含む行です。これは、プロセスIDとともに実行しようとしたプロセスsystemdの名前です。 これは、失敗したサービスの実際のエラー出力をよく見つける場所です。

cloud-configでiptables-restoreを有効にしましたが、目的のルールを含むファイルがまだ提供されていないため、ファイアウォールを復元できませんでした。 ドロップレットを作成する前にこれを行うこともできますが、ドロップレットを作成する前に、どのIPアドレスがドロップレットに割り当てられるかを知る方法がありません。 各プライベートIPがわかったので、ルールセットを作成できます。

エディターで新しいファイルを開き、以下を貼り付けて、coreos-1_private_ip、coreos-2_private_ip、およびcoreos-3_private_ipを各CoreOSマシンのプライベートIPアドレスに置き換えます。 Accept all TCP/IP traffic...の下のセクションを調整して、クラスターから提供する予定の公共サービスを反映する必要がある場合もありますが、このバージョンはデモンストレーション目的でうまく機能するはずです。

/ var / lib / iptables/rules-保存

*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]

# Accept all loopback (local) traffic:
-A INPUT -i lo -j ACCEPT

# Accept all traffic on the local network from other members of
# our CoreOS cluster:
-A INPUT -i eth1 -p tcp -s coreos-1_private_ip -j ACCEPT
-A INPUT -i eth1 -p tcp -s coreos-2_private_ip -j ACCEPT
-A INPUT -i eth1 -p tcp -s coreos-3_private_ip -j ACCEPT

# Keep existing connections (like our SSH session) alive:
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

# Accept all TCP/IP traffic to SSH, HTTP, and HTTPS ports - this should
# be customized  for your application:
-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 443 -j ACCEPT

# Accept pings:
-A INPUT -p icmp -m icmp --icmp-type 0 -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 3 -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 11 -j ACCEPT
COMMIT

上記をクリップボードにコピーし、 coreos-1 にログインし、CoreOSのデフォルトのテキストエディターであるVimを使用してrules-saveを開きます。

ssh -A core@coreos-1_public_ip

sudo vim /var/lib/iptables/rules-save

エディター内に入ると、:set pasteと入力し、 Enter を押して自動インデントがオフになっていることを確認してから、 i を押して挿入モードに入り、ファイアウォールルールを貼り付けます。 Esc を押して挿入モードを終了し、：wqを押してファイルを書き込んで終了します。

警告：ファイルの最後の行に末尾の改行があることを確認してください。そうしないと、ファイル内のすべてのコマンドが正しいように見えても、IPTablesが混乱する構文エラーで失敗する可能性があります。

最後に、ファイルに適切な権限（ユーザーの場合は読み取りと書き込み、グループとワールドの場合は読み取り専用）があることを確認してください。

sudo chmod 0644 /var/lib/iptables/rules-save

これで、サービスを再試行する準備ができました。

sudo systemctl start iptables-restore

成功すると、systemctlはサイレントに終了します。 ファイアウォールのステータスは2つの方法で確認できます。 まず、systemctl statusを使用して：

sudo systemctl status -l iptables-restore

次に、現在のiptablesルール自体を一覧表示します。

sudo iptables -v -L

-vオプションを使用して詳細な出力を取得します。これにより、特定のルールがどのインターフェイスに適用されるかがわかります。

coreos-1 のファイアウォールが構成されていることを確認したら、ログアウトします。

exit

次に、このプロセスを繰り返して、/var/lib/iptables/rules-saveをcoreos-2およびcoreos-3にインストールします。

結論

このガイドでは、3つのメンバーで基本的なCoreOSクラスターを定義し、それぞれに認証とトランスポートセキュリティ用のTLS / SSL証明書を提供し、ファイアウォールを使用してローカルデータセンターネットワーク上の他のドロップレットからの接続をブロックしました。 これは、共有ネットワークでのCoreOSの使用に伴う基本的なセキュリティ上の懸念の多くを軽減するのに役立ちます。

ここから、CoreOS の使用を開始する際に、このシリーズの残りの部分の手法を適用して、サービスを定義および管理できます。