TOC

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

前書き

共有データセンター内や公共のインターネットなど、管理外のネットワーク環境でCoreOSクラスターを実行する予定の場合、「+ etcd +」は暗号化されていないHTTPリクエストを行うことで通信することに気づいたかもしれません。 クラスター内の各ノードでIPTablesファイアウォールを構成することで、この動作のリスクを軽減することは可能ですが、完全なソリューションでは理想的には暗号化されたトランスポートレイヤーを使用します。

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

前提条件

このガイドは、https：//www.digitalocean.com/community/tutorials/an-introduction-to-coreos-system-components [CoreOSシステムコンポーネントのこの紹介]およびhttps：//www.digitaloceanで説明されている概念に基づいて構築されています。 com / community / tutorials / how-to-set-up-a-coreos-cluster-on-digitalocean [このガイドは、DigitalOceanでCoreOSクラスターをセットアップするためのガイド]。

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

クラスター内のマシンを作成してアクセスするには、DigitalOceanアカウントに関連付けられたSSH公開キーが必要です。 DigitalOceanでSSHキーを使用する方法の詳細については、https：//www.digitalocean.com/community/tutorials/how-to-use-ssh-keys-with-digitalocean-dropletsを参照してください[こちらを参照]。

DigitalOcean APIを使用してCoreOSマシンを作成する場合は、https：//www.digitalocean.com/community/tutorials/how-to-use-the-digitalocean-api-v2#how-to-generate-を参照してください書き込み権限を持つパーソナルアクセストークンを生成および使用する方法については、a-personal-access-token [このチュートリアル]。 APIの使用はオプションですが、特に大きなクラスターの構築が予想される場合は、長期的には時間を節約できます。

新しいディスカバリーURLを生成する

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

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

返されたURLを保存します。すぐに「+ cloud-config +」で使用します。

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

まず、 `+ cloud-config`を作成します。 `+ cloud-config `は、各サーバーの初期化時に*ユーザーデータ*として提供され、クラスターの重要な設定の詳細を定義します。 このファイルは長くなりますが、https：//www.digitalocean.com/community/tutorials/how-to-set-up-a-coreos-cluster-on-のバージョンよりも複雑になることはありませんdigitalocean [基本クラスターガイド]。 HTTPSエンドポイントを使用するよう明示的に「 fleet 」に指示し、ファイアウォールで「 iptables-restore 」というサービスを有効にし、「 etcd 」および「 fleet +」にSSL証明書の場所を指示する設定ファイルを書き出します。

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

cd ~
nano cloud-config.yml

以下を貼り付けてから、「+ etcd2 」セクションの「+」を最後のセクションで要求したディスカバリー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:
   # 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




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 +`をhttps://coreos.com/validate/ [公式のCoreOS Cloud Config Validator]に貼り付け、* Validate Cloud-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」マスク、およびファイルの目的のコンテンツを含む「+ contents」に分割されます。 ここでは、 `+ 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アドレスを知る必要があります。これは、マシンが作成された後にのみ利用可能です。

ドロップレットのプロビジョニング

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

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

同じデータセンターリージョン内に3つの新しいCoreOSドロップレットを作成します。 必ず* Private Networking および Enable User Data *を必ず確認してください。

  • * coreos-1 *

  • * coreos-2 *

  • * coreos-3 *

  • User Data *フィールドに、上記の `+ cloud-config.yml `の内容を貼り付け、ファイルの上部にある ` discovery +`フィールドにディスカバリーURLが挿入されていることを確認します。

DigitalOcean APIを使用する

フィールドへの繰り返しの貼り付けを節約する別のアプローチとして、 + curl +`を使用してDigitalOcean APIからの新しいDropletを `+ cloud-config +`で要求し、各Dropletに対して1回呼び出す短い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":"","size":"","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 Personal Access Tokenに関連付けられたSSHキーのフィンガープリントに設定しましょう。

パーソナルアクセストークンの取得とAPIの使用については、https：//www.digitalocean.com/community/tutorials/how-to-use-the-digitalocean-api-v2 [このチュートリアル]を参照してください。

アカウントに関連付けられたキーのフィンガープリントを見つけるには、* SSHキー*でhttps://cloud.digitalocean.com/settings/security [アカウント設定の*セキュリティ*セクション]を確認します。 これは、https：//en.wikipedia.org/wiki/Public_key_fingerprint [公開キーの指紋]の形式になり、「+ 43：51：43：a1：b5：fc：8b：b7：0a：3a」のような形式になります：a9：b1：0f：66：73：a8 + `。

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

export DO_SSH_KEY_FINGERPRINT=""
export TOKEN=""

必要な資格情報のそれぞれに環境変数を設定したら、スクリプトを実行して目的の各ドロップレットを作成できます。 `+ 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@

クラスターのメンバーへの最初のログイン時に、 `+ 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/...

別の方法として、事前に構築されたバイナリをhttps://pkg.cfssl.org/[pkg.cfssl.org]から取得できます。 最初に、 `+〜/ bin +`が存在し、パスにあることを確認します。

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

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

curl -s -L -o ~/bin/cfssl https://pkg.cfssl.org/
curl -s -L -o ~/bin/cfssljson https://pkg.cfssl.org/

`+ 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-csr.json`と + ca-config.json`を配置して、認証局を生成します：

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

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

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

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

nano coreos-1.json

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

〜/ coreos_certs / coreos-1.json

{
   "CN": "",
   "hosts": [
       "",
       ".local",
       "127.0.0.1",
       ""
   ],
   "key": {
       "algo": "rsa",
       "size": 2048
   },
   "names": [
       {
           "C": "",
           "L": "",
           "ST": ""
       }
   ]
}

最も重要な部分は、ホスト名である「+ CN 」と、次のすべてを含む必要がある「 hosts +」配列です。

  • あなたのローカルホスト名

  • + 127.0.0.1 +

  • CoreOSマシンのプライベートIPアドレス（公開IPではありません）

これらは、結果の証明書に* https：//en.wikipedia.org/wiki/SubjectAltName [subjectAltNames] *として追加されます。 `+ etcd `接続（ ` 127.0.0.1 +`のローカルループバックデバイスへの接続を含む）では、接続ホスト名に一致するSANを持つ証明書が必要です。

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

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

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

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

これにより、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  | cfssljson -bare coreos
chmod 0644 coreos-key.pem
scp ca.pem coreos-key.pem coreos.pem core@:
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-1のetcd2機能を確認します

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

ssh -A core@

次に、クラスター内のすべてのマシンをリストしてみます。

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を使用して、各CoreOSマシンに「+ reboot +」コマンドを送信します。

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 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 +」を有効にしたものの、目的のルールを含むファイルをまだ提供していないため、復元に失敗しました。 Dropletを作成する前にこれを行うこともできましたが、作成前にDropletにどのIPアドレスが割り当てられるかを知る方法はありません。 各プライベートIPがわかったので、ルールセットを作成できます。

エディターで新しいファイルを開き、以下を貼り付けて、「」、「」、および「++」を各CoreOSマシンのプライベートIPアドレスに置き換えます。 また、クラスターから提供する予定のパブリックサービスを反映するために、「+すべてのTCP / IPトラフィックを受け入れる…​ +」の下のセクションを調整する必要がある場合がありますが、このバージョンはデモの目的には適しています。

/ var / lib / iptables / rules-save

*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  -j ACCEPT
-A INPUT -i eth1 -p tcp -s  -j ACCEPT
-A INPUT -i eth1 -p tcp -s  -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:




# 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 *にログインして、https：//www.digitalocean.com/community/tutorials/installing-and-using-the-vim-textを使用して `+ rules-save +`を開きます-editor-on-a-cloud-server [Vim]、CoreOSのデフォルトのテキストエディター：

ssh -A core@
sudo vim /var/lib/iptables/rules-save

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

最後に、ファイルに適切なアクセス許可があることを確認します（ユーザーの読み取りと書き込み、グループとワールドの読み取り専用）：

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証明書を提供し、ファイアウォールを使用してローカルデータセンターネットワーク上の他のDropletからの接続をブロックしました。 これは、共有ネットワークでCoreOSを使用する際に伴う基本的なセキュリティ上の懸念の多くを軽減するのに役立ちます。

ここから、残りのhttps://www.digitalocean.com/community/tutorial_series/getting-started-with-coreos-2 [CoreOSの使用に関するこのシリーズ]のテクニックを適用して、サービスを定義および管理できます。

Related