ansible-vaultパスワードを置く場所

私たちは、gitでパスワードやキーの漏洩を防ぐために、プロジェクトでansible vaultを使用することを計画しています。

考えは、すべての機密データをプレーンファイルに入れ、パスワードを使用してansible-vaultでこのファイルを暗号化してからgitにプッシュすることです。

ファイルを復号化するには、ボールトのパスワードをansibleに渡す必要があります。3つの可能性について考えています。

• サーバー環境変数内に保存します
• ansible-playbookコマンドのオプションとして渡します
• バージョン非対応のファイルに保存します。

ansible-vaultパスワードを保存するための最良の（そして安全な）方法である他のオプションはありますか？

考えは、すべての機密データを置くことです[...]

この文の「すべて」の意味は、計画するソリューションを実装する前に非常に慎重に分析する必要があります。

Ansible vaultは非常に便利なツールですが、次の秘密を保存するためにのみ使用する必要があります。

1. ansibleデプロイメントに特に必要
2. 気付かないはずの所有者には簡単に役に立たないが、それは違法にそれらを「記憶」する可能性がある（通常、社外の従業員）

2番目のポイントは重要です。

多くの人々、場合によってはDevOpsチーム全体が、ansible vaultパスワード、したがってすべての秘密にアクセスできます。

したがって、ボールトに保存されているすべてのシークレットについて、それらへの不正アクセスを許可された人またはマシンが必要に応じてそれらを使用できない条件を保持する必要があります。

具体的には、ansibleを使用してデータベースとそのユーザーを展開する場合、パスワードをボールトに保存できますが、そのサービスをインターネットから利用できるようにする場合は非常に注意する必要があります（ほとんどの場合、別のソリューションを検討してください）そして、VPN認証を必要とせずに！

秘密にさらされたユーザー（DevOps）は、1つのセキュリティバリアが課されている場合（VPNアクセスが取り消された場合など）、「記憶された」パスワードを使用できないようにする必要があります。これに加えて、パスワードが変更される前に、ソースコードリポジトリ（ボールトが保存されている場所）へのアクセスも無効にする必要があります。

これらの条件下では、ansible vaultは非常に便利なツールです。

代わりに、インターネット上の任意の人またはマシンが使用できる秘密をボールトに保存しようとすると、間違いになります（たとえば、ユーザーのVPN資格情報）。

ansible-vaultパスワードを保存するための最良の（そして安全な）方法である他のオプションはありますか

前の段落の条件の下では、次のようにすることをお勧めします。

1. ボールトパスワードを外部の安全なボールト（HashiCorpのVaultや資格情報管理用のSaaSなど）に保存する
2. DevOps（テストにはパスワードが必要）およびCI / CDシステムまたはansibleコントローラーへの外部Vaultアイテムへのアクセスを許可します

3. 秘密を使用する規則を守ってください！シークレットへの変更を確認することはできず、シークレットファイル内の不可解な変数をgrepすることもできません！ですから、最初から徹底してください。良い慣習は、ansible vaultに保存されているすべての変数にsecret_プレフィックスを付けることです。次のようなものが表示されたら：

   postgres.yml：

   postgres_password: "{{ secret_postgres_password }}"
   

   値がansible vaultに保存されていることがわかります。

私たちは、gitでパスワードやキーの漏洩を防ぐために、プロジェクトでansible vaultを使用することを計画しています。

まだ何も実装していないので、これを再考するかもしれません。Ansible vaultのようなシステムを使用すると、セキュリティ上の欠点がいくつかあります。

• アクセスした人の監査証跡はありません
• 従業員が退職するとき、彼らは彼らと一緒に秘密の店を取るのは簡単です
• 従業員が退職した場合、アクセス権を削除すると、パスワードが変更され、他の全員に再配布されます。
• 侵害されたAnsibleボールトパスワードは、バージョン管理に保存されている古いバージョンのボールトで永久に使用される可能性があります
• 秘密は静的でなければなりません

これらの欠点を持たない、潜在的にはるかに安全で、より複雑なシステムは、Hashicorp Vaultを使用して秘密を保存することです。その後、https://github.com/jhaals/ansible-vaultを使用して、Ansible vaultとほぼ同じくらい簡単に値をプルできます。

ただし、その後はHashicorp Vaultへの認証を管理する必要があります。それが亀の質問です。人間にとって、最善の解決策は定期的にパスワードを要求し、短時間後にトークンを期限切れにすることだと思います。マシンの場合、AWS認証バックエンドなどを使用します。どこかで認証の必要性を完全になくすことはできませんが、攻撃者が認証にアクセスするのを難しくすることができます。

これで、シークレットサーバーのセットアップと管理があまりにも多すぎる場合は、Ansible vaultを使用できます。ただし、個々のマシンにパスワードを保存するのはなぜですか？インタラクティブに使用するために、パスワードの入力を要求するだけで、ユーザーは選択したパスワードマネージャーにパスワードを保存できます。OS X上のiTermには、Keychain.appと統合するパスワードマネージャーがあり、そこでは特に簡単です。

これは、機密データの処理に関してどのような内部ポリシーを持っているかという点に大きく影響します。

これに対する私のアプローチをお話しし、私が賛否両論するものを説明したいと思います。Ansible Vaultのパスワードを制御マシン上のファイルに保存し、それを指す環境変数を持っています：

export ANSIBLE_VAULT_PASSWORD_FILE=/deep/dark/place

プレイブックをテストおよび開発する必要があるため、ワークステーションにそれを持っていますが、一部の同僚もそれを持っています。もちろん、メインのAnsibleコントロールマシンにもあります。

長所：

• 共有の場所/リポジトリではありません（あなたが言うように、それはバージョン管理されていないファイルです）
• プレイを実行するためにAnsible vaultのパスワードを知る必要はありません（これは、プレイブックを簡単に起動できるJenkinsなどのCIツールがあるという条件の下にあります）

短所：

• パスワードを変更するのは簡単ではありません
• あなたのプレイブックで働くすべての人は、彼のワークステーションでそれを持っている必要があります

短所には緩和策がありますが、これも日常業務で採用したポリシーとルール次第です。

パスワードを暗号化するansible vaultを管理するには、このプロジェクトをご覧くださいhttps://github.com/Smile-SA/ansible-vault-manager

プラグインで複数のキーリングストレージプラットフォームを処理します（現在はAWS SSMのみが実装されています）。さらに、現在のAnsibleプロジェクトとの統合は非常に簡単です...