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
. 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
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
デモンストレーションの目的には問題ありませんが、実際のプロジェクトには別のリージョンまたはより大きなドロップレットが必要になる場合があります):
#!/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
署名を行います:
{
"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
エントリ、場所、組織名:
{
"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コントロールパネルに表示されます)。
{
"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の
コマンドを呼び出すたびに前の証明書ファイルのセットが上書きされることに注意して、残りのマシンごとにこのプロセスを繰り返します。
- 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...
このバージョンはデモンストレーションの目的でうまく機能するはずですが、クラスターから提供する予定の公共サービスを反映するためです。
- *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 の使用を開始する際に、このシリーズの残りの部分の手法を適用して、サービスを定義および管理できます。