あなたの投稿には、主に信頼に関する複数の質問が含まれています。
トークンが静的に保持されている場合のSpring Vaultのポイントは何ですか？
認証機構は、少なくとも依存：
- セキュリティポリシー
- あなたはOPS側に費やすことをいとわない
- 努力を受け入れるために喜んでいるリスク。
一部の環境では、静的トークンを持つVaultは完全に細かいですが、他のシナリオでは複数の要素の認証が必要です。静的トークンを使用すると、すべてのアプリ/アプリインスタンスまたはアプリ/アプリインスタンスごとに異なるトークンで1つのトークンを使用できます。こうすることで、特定のトークンをロックアウトして残りのトークンを有効にすることができます。
多分別の観点から質問を表示すると、Vaultでどのような要件に取り組もうとしていますか？安全な導入問題にどれだけの努力を費やしていますか？
ボールトは一般的な認証メカニズムとしてトークンを使用しますが、これに限定されません。クライアント証明書、マルチファクタ認証、およびその他のいくつかのメカニズムを使用してセッショントークンを取得し、セッショントークンをメモリに保存することができます。
認証トークンはどのようにセキュリティ保護されていますか？
これは、使用する環境やリスクによって異なります。あなたは、少なくとも次の方法で任意のJavaアプリケーションに、一般的に、設定プロパティを話す静的トークンを、供給することができます：
- プロパティファイル
- 環境変数
- システムプロパティ
- コマンドライン引数
- アプリケーション開始時のプロンプト
それぞれの可能性は、 t。あなたのランタイム/コンテナが十分な（あなたが定義するレベルの）保護を持っているならば、プロパティファイルは完全にうまくいくかもしれません。セキュリティバーを高くする必要がある場合は、アプリケーションの起動時にプロンプトを表示してトークンを入力することができます。
Vaultが完全に自動化されたデプロイメントチェーンにどのように適合するかはわかりません。
これはまさに質問ではなく、おそらくあなたの投稿の中で最も興味深い文章です。
今日、JenkinsとSSHを使用して展開すると、Jenkinsマシンとオペレータが実際に展開を実行していることを信頼することになります。この配置では、実行時の認証がJenkinsの設定の一部であるため、Jenkinsを信頼することは許容可能なリスクのようです。ここから生じる問題は次のとおりです。ランタイムを信頼していますか？あなたはそれをどのレベルまで信じますか？ランタイムを信頼できない場合（つまり、ランタイム環境が秘密を漏らし、意図しない関係者が簡単にアクセスできるようになった場合）、静的トークンよりも大きな問題が生じる可能性があります。