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

getdocs

4年前

序章

共有データセンター内やパブリックインターネット全体など、制御できないネットワーク環境で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. The cloud-config 各サーバーを初期化するときにユーザーデータとして提供され、クラスターの重要な構成の詳細を定義します。このファイルは長くなりますが、基本クラスターガイドのバージョンよりもはるかに複雑になることはありません。教えてあげる fleet HTTPSエンドポイントを明示的に使用するには、 iptables-restore 私たちのファイアウォールのために、そして設定ファイルを書き出す etcd と fleet SSL証明書の場所。

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

cd ~
nano cloud-config.yml

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

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

貼り付けるときはインデントに注意してください。 The 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 公式のCoreOSCloudConfig 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 に設定されています https URL。プレーンHTTP操作の場合、この値を設定する必要はありません。ただし、明示的な構成がないと、HTTPSは失敗します。 ($private_ipv4 はCoreOS初期化プロセスによって理解される変数であり、変更する必要のある変数ではありません。）

次に、 write_files ブロック。値はファイルシステムに分割されます path, permissions マスク、そして content、ファイルの目的の内容が含まれています。ここでは、 systemd のユニットファイル etcd2 と fleet サービスは、生成する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 次回Dropletの起動時にリセットされるため、クラスターの構築後に変更する予定の構成のセクション。

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

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

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

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

coreos-1
coreos-2
coreos-3

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

DigitalOceanAPIの使用

フィールドへの繰り返しの貼り付けを節約できる代替アプローチとして、次を使用する短いBashスクリプトを作成できます。 curl DigitalOceanAPIから新しいドロップレットをリクエストするには cloud-config、ドロップレットごとに1回呼び出します。と呼ばれる新しいファイルを開きます makecoreos.sh と nano （または選択したテキストエディタ）：

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 最初のパラメータを使用して、 name APIの呼び出しのフィールド：

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や現在は非推奨になっているものよりも、自己署名証明書を生成するためにCoreOSメンテナが選択したツールです。 etcd-ca.

ローカルマシンに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

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

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"
                ]
            }
        }
    }
}

ここで注目すべきは expiry、現在43800時間（または5年）に設定されており、 client-server 両方を含むプロファイル server auth と client auth 使用法。ピアツーピア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 必要に応じて、現在地を反映する配列。繰り返しになりますが、地名には架空の値を使用しても安全です。

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

注：のデフォルト値を確認したい場合 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の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機能を確認してください

証明書があれば、実行できるはずです fleetctl coreos-1で。まず、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. それでも、可能であれば、利用可能な攻撃対象領域を減らすことをお勧めします。ネットワークの露出を制限するために、各マシンにいくつかの単純なファイアウォールルールを追加して、クラスター内のピア以外のソースからのほとんどのローカルネットワークトラフィックをブロックできます。

を有効にした場合は、 iptables-restore でのサービス cloud-config、 systemd CoreOSマシンに最初にログインしたときのエラーメッセージ：

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]、これはプロセスの名前です systemd プロセスIDと一緒に実行しようとしました。これは、失敗したサービスの実際のエラー出力をよく見つける場所です。

ファイアウォールを有効にしたが、 iptables-restore の cloud-config、必要なルールを含むファイルはまだ提供されていません。ドロップレットを作成する前にこれを行うこともできますが、ドロップレットを作成する前に、どの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 にログインして、開きます rules-save CoreOSのデフォルトのテキストエディタであるVimを使用します。

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 の使用を開始する際に、このシリーズの残りの部分の手法を適用して、サービスを定義および管理できます。