Ansible-プライベートgitリポジトリ-SSHエージェントの転送とプライベートSSHキーのコピー


7

私は最近、Ansibleをいじり始めました。DevOpsに関する経験はあまりなく、複雑なシナリオを処理する必要はまったくありませんでした。現在の展開ツールであるDeployer PHPを置き換えるために、Ansibleプレイブックの作成を開始しました。残念ながら、gitリポジトリのクローン作成に行き詰まっています。今、私はgitリポジトリへのアクセスを有効にするために公開鍵を追加する必要があることを知っています。

SSHエージェント転送を使用する必要がありますか(この方法でローカルSSHキーを使用できます)、またはプライベートSSHキー(暗号化、ソース管理に追加)をansibleプロジェクト内に保存し、Ansibleを使用してターゲットノードにコピーする必要がありますか?質問が非常に広範囲にわたる可能性があることを知っているので、私にとって興味深いのは、両方のアプローチのセキュリティへの影響です。

回答:



4

gitリポジトリがプライベートgithubの場合は、githubメソッドを使用できます(デプロイキーは非常に強力です)。

リポジトリがgithubでホストされていない場合、またはリポジトリが読み取り専用のデプロイキー機能を提供していない場合、前述の2つのオプションはどちらも価値があります。

単一のDevOpsの人

あなたがプロジェクトに取り組んでいる唯一の人であり、あなたのマシンがあなただけから実行できる唯一の場合(ジェンキンスや友人のようなCDツールはありません)あなたはエージェント転送オプションを使うのが良いでしょう:暗号化されていない秘密鍵を忘れてください。

小さなチーム

同じAnsibleプレイブックで作業しているチーム、またはプレイブックを実行している複数のチームの場合は、両方のオプションがあります。

  • エージェント転送オプションを維持します。すべてのチームメイトが自分のマシンからスクリプトを実行します。

  • ベルリンで提案されているように、デプロイヤーの鍵ペアを作成し、pub-keyをアップロードして、ボールトで秘密鍵を暗号化します。キーは暗号化されており、秘密キーの範囲は1つまたはいくつかのリポジトリに制限されています。このアプローチの問題は、チームメイトがチームを去るたびにボールトのパスワードをローテーションする必要があることです。

安全性が高いと思われる場所に、広い範囲の個人用秘密鍵を置くことは決してありません。ボールトの暗号化は、それを使用する人々と同じくらい優れており、クリアテキストのキー/パスワードがたくさんあります:)


2

SSHエージェント転送を使用する必要があります(この方法でローカルSSHキーを使用できます)

はい、それはオプションかもしれません

プライベートSSHキー(暗号化、ソース管理に追加)をansibleプロジェクトに保存し、Ansibleを使用してターゲットノードにコピーする必要がありますか?

番号

/server/823956/ansible-security-best-practices

サーバーの場合、sshを介したrootアクセスをまったく許可しないでください。多くの監査はこれを侮辱します。

念のため、すべての管理者が各ターゲットサーバーで独自の個人アカウントを使用できるようにし、パスワードでsudoできるようにします。この方法では、パスワードは2人の間で共有されません。各サーバーで誰が何をしたかを確認できます。個人アカウントがパスワード、sshキーのみ、または両方を必要とするログインを許可するかどうかは、あなた次第です。

要約すると、sshキーとパスワードを使用します。すべてのユーザーが自分のsshキーを使用できるようにします。sshによるsudoアクセスを許可しないでください。


うーん、これがコンテキストに当てはまるかどうかはわかりません。アプリをデプロイするときにリポジトリからコードを(読み取り専用で)プルするために使用されるSSHキーについて尋ねました。SSHエージェントでは、各公開鍵(各ユーザー)を配備鍵としてリポジトリに追加する必要があります。
pzaj 2017

0

ある特定のキーに対して読み取りアクセスのみを許可するようにリポジトリーを構成し、リポジトリーが公に読み取り可能であることを気にしない場合、1つの状況で秘密鍵をストーリー化できます。この場合、秘密鍵を簡単に保存できます。パスフレーズなしで使い捨ての鍵を作成できます。しかし、私が言ったように、あなたがそのリポジトリへのパブリックアクセスに問題がない場合のみ。

そうでない場合は、おそらくSSHエージェントに行き詰まっています。rootソケットを取ることができるので、それは理想的ではありませんが、ある種の慈悲深い環境(つまり、近くに攻撃可能なWebサーバーがない)であれば、問題ありません。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.