PuppetとChefを使用した自動システムのセキュリティ
Puppet Camp Londonでの 非常に興味深いプレゼンテーション で、Tomas Doranは、Puppetで大量のDockerコンテナーを管理することですべてを自動化するためのかなり過激なアプローチを提案しました。
セキュリティを重視する人として、すべてが独自のLXCで実行され、すべてのサービスを非rootユーザーとして実行するように構成するため、Dockerのアイデアが気に入っています。
システム管理を意識する人としては、すべての構成をGitリポジトリーに保持し、さまざまな環境をすべてバージョン管理で維持できるため、Puppet管理のアイデアが気に入っています。利点は、手作業による介入なしに理論的にゼロから再構築できる、分解可能な（つまり、一言ですか？）環境があることです。
ただし、Gitリポジトリに保持したくないもの、つまりSSL証明書、データベースパスワードなどがあります。
大量のマシン（CERNなど）を管理する組織は、セキュリティを維持しながら、PuppetやChefなどのプロビジョニングサービスをどのように使用しますか？ファイルへのアクセス許可の適用など、特定のことは簡単に見えますが、SSLキーやSSHホストキーのインストールなど、手動による介入が必要なものは難しいようです。
以前は人形劇のインストールを行っていたので、そのときの話をします。
SSHホストキーは一時的なものです。そのため、新しいシステムを構築したり、既存のシステムを再構築したりするときは、最初にSSHDを起動したときに、新しい鍵が生成されるようにします。これらのマシンにSSHで接続する人は比較的少なく、マシンを再構築するときに、内部wikiにホストキーのフィンガープリントを公開しました。そのため、攻撃者はwikiのホストとMITMのSSH接続を危険にさらし、マシンが構築された直後にそれを実行する必要があります。
マシンの再インストール時にalwaysが新しいSSLキーを生成しました。 SSLを含むサービスを再構築するための人間のステップの1つは、キーであるCSRを生成し、CAによって署名されてから、証明書をインストールすることでした。人形テンプレートによって事前に入力されたスクリプトを使用して、CNと他のフィールドを適切に設定しました。
CERNにSSL証明書が含まれるホストがたくさんあるとは思いません。あるいは、彼らはそうするかもしれませんが、人形の要求で証明書に署名するための自動化されたCAを持っています。
また、適切に制御されたgitリポジトリに証明書とキーを保存することは必ずしも悪いとは考えていません。システムを再構築する時点を、鍵をローテーションする絶好の機会と捉えました。