P粉3995850242023-08-28 11:42:57
この質問がされてから Docker は大きく変更されたため、回答を更新する試みをここに示します。
まず、特にクラウドで既に実行されているコンテナの AWS 認証情報の場合、Vor recommends のような IAM ロールを使用することは非常に良いアイデアです。それができる場合は、彼の答えに 1 を加えて、残りをスキップします。
クラウドの外で何かを実行し始める場合、またはさまざまな種類のシークレットがある場合は、 シークレットを 2 つの重要な場所に保存しないことをお勧めします。
tar などの一般的な Linux ユーティリティとシークレットは、最初にイメージに追加されたステップから見つけることができます。
オプション A: このキーがイメージのビルド中にのみ必要で、ビルドが開始されるまで使用できず、まだ BuildKit にアクセスできない場合、マルチステージ ビルド最悪の選択です。ビルドの初期ステージにシークレットを追加してそこで使用し、シークレットを含まないそのステージの出力をリリース ステージにコピーし、そのリリース ステージのみをレジストリ サーバーにプッシュできます。シークレットはまだビルド サーバーのイメージ キャッシュにあるため、私はそれを最後の手段としてのみ使用する傾向があります。
オプション B: また、ビルド中に BuildKit の 18.09 リリースを使用できる場合は、現在、単一のボリューム マウントとしてシークレット インジェクションを可能にする 実験的な機能 があります。走行ライン。マウントはイメージ レイヤーに書き込まないため、パブリック レジストリ サーバーにプッシュされることを心配することなく、ビルド中にシークレットにアクセスできます。生成された Dockerfile は次のようになります: リーリー
18.09 以降のコマンドを使用してビルドできます。例:リーリー
オプション C: Swarm モードやその他のオーケストレーションを使用せずに単一ノードで実行する場合、資格情報を読み取り専用ボリュームとしてマウントできます。この資格情報にアクセスするには、docker の外部で同じ資格情報ファイルにアクセスするのと同じアクセスが必要であるため、docker を使用しない状況と比べて良いことも悪いこともありません。肝心なのは、コンテナーを検査したり、ログを表示したり、イメージをレジストリ サーバーにプッシュしたりするときに、このファイルの内容が表示されるべきではないということです。いずれの場合もファイルはボリュームの外部にあるためです。これには、コンテナーのデプロイメントとは別に、Docker ホスト上の資格情報をコピーする必要があります。 (Docker API へのアクセスはホスト上の root であり、root は任意のユーザーのファイルを表示できるため、そのホスト上でコンテナを実行できる権限を持つ人は誰でも資格情報を表示できることに注意してください。ホスト root 上の誰も信頼していない場合は、ユーザーに docker API アクセスを与えないでください。)
docker run の場合、これは次のようになります:
リーリー
または、構成ファイルの場合は、次のものが必要です:
オプション D: Swarm モードと Kubernetes などのオーケストレーション ツールにより、ボリュームよりもシークレットのサポートが強化されました。 Swarm モードでは、ファイルはマネージャーのファイル システム上で暗号化されます (ただし、通常は復号化キーも存在するため、管理者が復号化キーを入力しなくてもマネージャーを再起動できます)。さらに、シークレットは、シークレットを必要とするワーカー (そのシークレットを使用してコンテナーを実行するため) にのみ送信され、ディスクではなくワーカーのメモリにのみ保存され、tmpfs を使用してコンテナーにファイルとして挿入されます。 swarm の外部のホスト上のユーザーは、シークレットを自分のコンテナーに直接マウントすることはできませんが、Docker API へのオープン アクセスにより、ノード上で実行中のコンテナーからシークレットを抽出できるため、シークレットにアクセスできるユーザーが再び制限されます。 API。 Compose からは、このシークレット インジェクションは次のようになります:
リーリー単一ノードに対して docker swarm init
を使用して swarm モードをオンにし、追加ノードを追加するための指示に従います。docker secret create aws_creds $HOME/ を使用して外部にシークレットを作成できます。 aws/credentials
. そして、docker stackdeploy -c docker-compose.yml stack_name
.
私はよく次のスクリプトを使用してシークレットのバージョンを管理します: https://github.com/sudo-bmitch/docker-config-update
オプション E: シークレットを管理するためのツールは他にもありますが、私のお気に入りは Vault です。これは、自動的に期限切れになる期限付きのシークレットを作成できるためです。各アプリケーションは、シークレットを要求するための独自のトークン セットを取得します。これにより、Vault サーバーに到達できれば、これらの時間制限のあるシークレットを要求できるようになります。これにより、シークレットが機能しなくなるか、すぐに期限切れになってしまうため、シークレットがネットワークから持ち出された場合のリスクが軽減されます。 AWS for Vault の具体的な機能については、https://www.vaultproject.io /docs/secrets/aws/index.html
に文書化されています。P粉5236250802023-08-28 10:29:34
最良のアプローチは、IAM ロールを使用し、認証情報をまったく処理しないことです。 ( http://docs.aws .amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html を参照してください)
認証情報は http://169.254.169.254....
から取得できます。これはプライベート IP アドレスであるため、EC2 インスタンスからのみアクセスできます。
オプションとして、実行時に環境変数として渡すことができます (つまり、
docker run -e AWS_ACCESS_KEY_ID=xyz -e AWS_SECRET_ACCESS_KEY=aaa myimage)