Puppetセキュリティとネットワークトポロジ

バックグラウンド：

私はついに、21世紀に参加してPuppetを見る時間を取っておきます。

現在、私たちはオフィスで内部的に保持されているリポジトリ内のすべてのサーバー構成をバージョン管理しています。更新を行う必要がある場合、変更はリポジトリにチェックインされ、問題のマシンに手動でプッシュされます。これは通常、リモートマシンにSFTPを実行し、関連する権限でシェルからファイルを所定の場所に移動することを意味します。

ですから、Puppetが私たちが既に持っているもののシンプルでありながら驚くべき拡張になることを期待しています。

今、私たちは現在、合理的に安全でなければならないプロセスを検討します。私たちの内部ネットワークは、データセンターのパブリックネットワークよりも常に比較的安全であるという前提で。

• プロセスは常に一方向です。変更は安全な環境から安全でない環境へと行き来し、その逆はありません。

• マスターストアは可能な限り安全な場所にあります。構成を盗んだり、悪意のある変更を送信したりすることによる侵害のリスクが大幅に削減されます。

質問：

私がPuppetサーバー/クライアントモデルについて理解しているのは、クライアントがサーバーから更新を直接ポーリングしてプルするということです。トラフィックはSSLでラップされているため、傍受やなりすましはできません。ただし、Puppetサーバーは公共の場所でホストする必要があるため、現在の処理とは異なります。中央、または当社が管理する各データセンターサイトに1つ。

だから私は疑問に思っています：

• プッシュからプルへの変更について不必要に偏執的ですか？

• その情報のすべてをパブリックネットワークに一元的に保存することについて、私は不必要に妄想的ですか？

• 他の人はどのように複数のネットワークを維持していますか？各サイトに別々のサーバー？

更新日30/07/09：

私の他の大きな懸念の1つが置かれていると思うので、単一のマシンを信頼する必要があります。操り人形師は、ファイアウォールで保護され、保護されます。それでも、リスニングサービスを備えたパブリックマシンには、特定のサイズの攻撃対象領域があります。

おそらく、マスターがパペットクライアントのいずれかのファイルを更新する権限を持っている場合、その侵害は最終的にすべてのクライアントの侵害につながります。いわば「王国への王」。

• その仮説は正しいですか？

• 軽減できる方法はありますか？

私は時々モジュールの変数にパスワードを保存するため、手動で設定を完了することなくアプリケーションをデプロイできるようにするため、パペットリポジトリを公開サーバーに適切に配置できないことを意味します。そうすることは、操り人形マスターを攻撃することで、すべてのサーバー上のすべての異なるアプリケーションのアプリまたはデータベースのパスワードを取得できることを意味します。

したがって、私のpuppetmasterはオフィスのプライベートネットワークにあり、サーバーでpuppetdデーモンを実行していません。デプロイする必要がある場合、プライベートネットからサーバーにsshを使用して、トンネルを作成し、puppetdをリモートで呼び出します。
秘Theは、リモートトンネルとpuppetクライアントをpuppetmasterに接続するのではなく、http接続を受け入れ、プライベートネットワーク上のpuppetmasterサーバーに到達できるプロキシに設定することです。そうしないと、証明書とのホスト名の競合のために、Puppetはプルを拒否します。

# From a machine inside privatenet.net :
ssh -R 3128:httpconnectproxy.privatenet.net:3128 \
    -t remoteclient.publicnetwork.net \
    sudo /usr/sbin/puppetd --server puppetmaster.privatenet.net \
    --http_proxy_host localhost --http_proxy_port 3128 \
    --waitforcert 60 --test –-verbose

それは私のために働く、それがあなたを助けることを願っています

事務所とコロの2つのサイトがあります。各サイトには独自のパペットマスターがいます。次の構造を持つsvnリポジトリを設定します。

root/office
root/office/manifests/site.pp
root/office/modules
root/colo
root/colo/manifests/site.pp
root/colo/modules
root/modules

各サイトの下のモジュールディレクトリは、トップレベルのモジュールディレクトリに戻るsvn：externalsディレクトリです。これは、それらがまったく同じモジュールディレクトリを共有することを意味します。次に、作成するクラスの大部分がモジュールディレクトリの下にあり、両方のサイトで使用されていることを確認します。これには、クラスを特定のサイトに結び付けずに、一般的に考えることを強いるという素晴らしい利点があります。

セキュリティに関しては、Puppetmaster（およびネットワークの残りの部分）をファイアウォールの背後にホストしているため、設定を中央に保存することについては心配していません。puppetmasterは、信頼できるホストにのみ構成を送信します。明らかに、そのサーバーを安全に保つ必要があります。

あなたのパラノイアがどれほど必要かについて判断することはできません。それはあなたの環境に大きく依存します。ただし、既存の構成の2つの主要な点を引き続き適用できると自信を持って言えます。puppetmasterがどこにいても、変更が安全な環境（オフィスのリポジトリ）から安全性の低い環境に確実に移動できるようにします。プロセスをSFTPから多数のサーバーに変更し、手動でファイルを配置してpuppetmasterにSFTPを実行し、Puppetにファイルを配布して正しい場所に配置させます。マスターストアは引き続きリポジトリであり、リスクは軽減されます。

プッシュまたはプルのどちらかが他のモデルより本質的に安全だとは思わない。Puppetは、転送中の構成を保護し、クライアントとサーバーの両方を認証して双方向の信頼が確立されていることを確認するという素晴らしい仕事をしています。

複数のネットワークについては、中央のマスターのクライアントとして機能する各場所にあるサテライトの操り人形マスターを持つ中央の「マスター」操り人形マスターで処理します。

設計アプローチの1つは、システムの各サイトにローカルなpuppetmasterを持ち、展開ツールを使用してpuppetmasterに変更をプッシュすることです。（gitフックをgitフックとともに使用することもできます）。

これは、パペットネットワークトラフィックが内部のみであるため、パブリックネットワークでのサービスのリッスンに関する懸念を保持します。

マニフェストを各サーバーにプッシュし、パペットクライアントにマニフェストを解析させ、関連する構成を適用することもできます。

あなたは「外部」と言いますが、私はpeople意的な人々があなたの操り人形マスターに接続する必要があることを本当に疑います。いつでもVPNを混在させることができます。友人から「接続が安全な場合、プロトコルのセキュリティについて心配する必要がありますか？」私はその態度に同意しませんが、余分なレイヤーは決して傷つけず、私の個人的なパラノイアに驚くほど働きます。その上、トンネルをトンネルするのが楽しい。

cfengineの著者であり、大学教授（その人形はその遺産を受け継いでいるようだ）であるMark Burgessが、プッシュとプルについて多くのことを書いています。彼は、プルは本質的に安全だと主張しています。cfengineのWebサイトを見ると、17年間でたった1つのネットワークセキュリティインシデントしかありません。バージェスは、それがプル設計によるものだと主張しています。単一の妥協点は避けられないと思います。その点までの攻撃のルートについてもっと心配するでしょう。

必要に応じて、中央マスターなしでパペットを実行できます。私が見た1つの方法は、gitリポジトリを使用し、gpgキーの事前設定リストのいずれかによってタグが署名されている場合にのみ更新をマージおよびデプロイするスクリプトを使用することです。人々は、保存された構成を取得する方法を考え出しました（たとえば、別のサーバーで処理されたリソースから中央サーバーでnagios監視を設定するために使用されます）。

そのため、中央のgitサーバーが危険にさらされた場合、他のサーバーはそれから更新を適用しません。gpgキーは、システム管理者のラップトップなどにあり、キーを無効にする方法もあります。

詳細については、http：//current.workingdirectory.net/posts/2011/puppet-without-masters/をご覧ください。