ホームページ  >  に質問  >  本文

AWS 認証情報を Docker コンテナに渡す最良の方法は何ですか?

<p>Amazon EC2 で docker-container を実行しています。現在、AWS 認証情報を Dockerfile に追加しました。これを行うための最良の方法を教えていただけますか? </p>
P粉662361740P粉662361740442日前496

全員に返信(2)返信します

  • P粉399585024

    P粉3995850242023-08-28 11:42:57

    この質問がされてから Docker は大きく変更されたため、回答を更新する試みをここに示します。

    まず、特にクラウドで既に実行されているコンテナの AWS 認証情報の場合、Vor recommends のような IAM ロールを使用することは非常に良いアイデアです。それができる場合は、彼の答えに 1 を加えて、残りをスキップします。


    クラウドの外で何かを実行し始める場合、またはさまざまな種類のシークレットがある場合は、 シークレットを 2 つの重要な場所に保存しないことをお勧めします。

    1. 環境変数: これらの変数がコンテナー上で定義されている場合、コンテナー内のすべてのプロセスが変数にアクセスでき、/proc を通じて参照でき、アプリケーションはその環境を stdout にダンプしてログに保存できます。そして最も重要なことは、コンテナーを検査すると、コンテナーがクリア テキストで表示されることです。

    2. イメージ自体の場合: イメージは、多くのユーザーがプル アクセス権を持っているレジストリにプッシュされることが多く、場合によってはイメージをプルするために必要な認証情報が必要ありません。1 つのレイヤーからシークレットを削除した場合でも、イメージは次のコマンドで逆アセンブルできます。

      tar などの一般的な Linux ユーティリティとシークレットは、最初にイメージに追加されたステップから見つけることができます。


    それでは、Docker コンテナーのシークレットには他にどのようなオプションがあるのでしょうか?

    オプション 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

    に文書化されています。

    返事
    0
  • P粉523625080

    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 インスタンスからのみアクセスできます。

    最新の AWS クライアント ライブラリはすべて、そこから認証情報を取得、更新、使用する方法を「認識」しています。したがって、ほとんどの場合、それについて知る必要さえありません。正しい IAM ロールで ec2 を実行するだけです。

    オプションとして、実行時に環境変数として渡すことができます (つまり、

    docker run -e AWS_ACCESS_KEY_ID=xyz -e AWS_SECRET_ACCESS_KEY=aaa myimage)

    ターミナルで printenv を実行すると、これらの環境変数にアクセスできます。

    返事
    0
  • キャンセル返事