Puppetのセキュリティとネットワークトポロジ
背景：
私はついに21世紀に参加してPuppetを見る時間を取っています。
現在のところ、オフィスの内部に保持されているリポジトリ内のすべてのサーバー構成をバージョン管理しています。更新を行う必要がある場合、変更はリポジトリにチェックインされ、問題のマシンに手動でプッシュされます。これは通常、リモートマシンにSFTPを実行し、シェルからファイルを適切な権限で移動します。
ですから、Puppetが私たちがすでに持っているもののシンプルで驚くべき拡張になることを期待しています。
今、私は現在私たちが合理的に安全でなければならないプロセスを考えています。私たちの内部ネットワークは常に、データセンターのパブリックネットワークよりも比較的安全であると想定しています。
プロセスは常に一方向です。変更は、安全な環境から安全でない環境に移行し、その逆はありません。
マスターストアは可能な限り安全な場所にあります。設定を盗んだり、悪意のある変更を送信したりすることによる侵害のリスクは大幅に軽減されます。
質問：
Puppetサーバー/クライアントモデルについて私が理解していることから、クライアントはサーバーから直接更新をポーリングしてプルダウンします。トラフィックはSSLでラップされているため、傍受したりなりすましたりすることはできません。ただし、Puppetサーバーは公共の場所でホストする必要があるため、現在の方法とは異なります。一元的に、または維持するデータセンターサイトごとに1つ。
だから私は疑問に思っています：
プッシュからプルへの変更について、私は不必要に妄想していますか？
その情報すべてをパブリックネットワークに集中的に保存することについて、不必要に偏執的ですか？
他の人はどのように複数のネットワークを維持していますか？サイトごとに別々のサーバーですか？
更新30/07/09：
私の他のbigの懸念の1つが置かれていると思うので、単一のマシンを信頼する必要があります。 puppetmaster（s）はファイアウォールで保護され、保護されます。しかし、それでも、リスニングサービスを備えた公共のマシンには、特定のサイズの攻撃対象領域があります。
おそらく、マスターがpuppetクライアントのいずれかでファイルを更新する権限を持っている場合、その侵害は最終的にすべてのクライアントの侵害につながります。いわば「王国への王」。
その仮説は正しいですか？
それを軽減する方法はありますか？
モジュールの変数にパスワードを保存することがあるので、手動で構成を完了せずにアプリケーションをデプロイできるようにするため、パペットリポジトリをパブリックサーバーに適切に配置できません。そうすることは、puppetmasterを攻撃することで、すべてのサーバー上のすべての異なるアプリケーションの一部のアプリパスワードまたはdbパスワードを取得できることを意味します。
したがって、私のpuppetmasterはオフィスのプライベートネットワークにあり、サーバーでpuppetdデーモンを実行しません。デプロイする必要がある場合は、プライベートネットからサーバーにsshを使用してトンネルを作成し、リモートでpuppetdを呼び出します。
トリックは、リモートトンネルとパペットクライアントをパペットマスターに接続するように設定するのではなく、受け入れるプロキシに設定することです 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
各サイトの下のmodulesディレクトリは、最上位のmodulesディレクトリに戻るsvn：externalsディレクトリです。つまり、これらはまったく同じモジュールディレクトリを共有します。次に、作成するクラスの大部分がモジュールディレクトリの下にあり、両方のサイトで使用されていることを確認します。これには、クラスを特定のサイトに結び付けずに、一般的に考えるように強制するという素晴らしい利点があります。
セキュリティに関しては、ファイアウォールの背後でpuppetmaster（およびネットワークの残りの部分）をホストしているため、構成を一元的に保存することについてはそれほど心配していません。 puppetmasterは、信頼するホストにのみ構成を送信します。明らかに、そのサーバーを安全に保つ必要があります。
あなたのパラノイアがどれほど必要かは判断できません。それはあなたの環境に大きく依存します。ただし、既存の構成の2つの主要な点が引き続き適用できることは間違いありません。 puppetmasterがどこにあっても、変更が安全な環境（オフィスのリポジトリ）から安全性の低い環境に確実に移動するようにすることができます。プロセスをSFTP処理から多数のサーバーに変更し、手動でファイルを配置してpuppetmasterにSFTP処理し、Puppetにファイルを配布させて正しい場所に配置させます。マスターストアは引き続きリポジトリであり、リスクは軽減されます。
プッシュとプルのどちらも他のモデルより本質的に安全だとは思いません。 Puppetは、転送中の構成を保護するだけでなく、クライアントとサーバーの両方を認証して、双方向の信頼が確立されていることを確認するという優れた機能を果たします。
複数のネットワークについては-中央マスターのクライアントとして機能する各場所の衛星操り人形マスターを持つ中央「マスター」操り人形マスターでそれを処理します。
設計アプローチの1つは、システムの各サイトにローカルのpuppetmasterを配置し、展開ツールを使用して変更をpuppetmasterにプッシュすることです。 （gitフックとgitを併用することもできます）。
これにより、パペットネットワークトラフィックは内部のみであるため、パブリックネットワークでのリスニングサービスに関する懸念が維持されます。
マニフェストを各サーバーにプッシュして、puppetクライアントにマニフェストを解析させて関連する構成を適用させることもできます。
Cfengineの作者であり、大学の教授（その人形はその遺産を受け継いでいるようです）であるマークバージェスは、プッシュとプルについて多くのことを書いています。彼はプルが本質的により安全であると主張します。 cfengineのWebサイトを見ると、17年間でネットワークセキュリティインシデントが1件しか発生していません。バージェスは、それはプルデザインによるものだと主張しています。一点の妥協は避けられないと思います。その時点までの攻撃のルートについてもっと心配したい。
あなたは「外部」と言っていますが、恣意的な人々があなたの人形使いに接続する必要があるのではないかと私は本当に疑っています。 VPNはいつでも組み合わせることができます。ある友人が「接続が安全な場合、プロトコルのセキュリティについて心配する必要はありますか？」私はその態度に同意しませんが、追加のレイヤーは決して害を与えることはなく、確かに私の個人的なパラノイアに不思議に働きます。その上、トンネルをトンネルするのは楽しいです。
必要に応じて、中央マスターなしで人形を実行できます。私が見た1つの方法は、gitリポジトリを使用し、タグがgpgキーの事前設定リストの1つによって署名されている場合にのみ、更新をマージしてデプロイするスクリプトを使用することです。人々は、格納された構成を取得する方法も考え出しました（たとえば、別のサーバーで処理されたリソースから中央サーバーでnagios監視を設定するために使用されます）。
したがって、中央のgitサーバーが侵害された場合、他のサーバーはそれ以上の更新を適用しません。 gpgキーは、キーを取り消す何らかの方法とともに、システム管理者のラップトップなどにあります。
詳しくは http://current.workingdirectory.net/posts/2011/puppet-without-masters/ をご覧ください。