web-dev-qa-db-ja.com

複数のDockerコンテナのIAMセキュリティ認証情報の管理

プレーンなEC2環境内では、他のAWSリソースへのアクセスの管理は、IAMロールと認証情報(インスタンスメタデータから自動的に取得される)を使用するとかなり簡単です。特定のアプリケーションロールをインスタンスに割り当てるときにその場でロールを作成できるCloudFormationを使用すると、さらに簡単になります。

Dockerに移行して、M台のマシンとN台のアプリケーションを実行している一種のM-to-Nデプロイメントを使用したい場合、アプリケーションごとのAWSリソースへのアクセスを制限するにはどうすればよいですか?インスタンスメタデータにはホスト上の誰でもアクセスできるので、すべてのアプリケーションが同じデプロイメント環境内の他のすべてのアプリケーションのデータを表示/変更できるようにします。

そのような環境で実行されているアプリケーションコンテナにセキュリティ資格情報を提供するためのベストプラクティスは何ですか?

11
Alex B

このプロジェクトがあります: https://github.com/dump247/docker-ec2-metadata

インスタンスメタデータエンドポイントへのプロキシとして機能し、コンテナに固有のロールを返します。私はこれまで使用したことがありませんが、あなたが説明しているユースケースを解決しているようです。

5
pbitty

特にCloudFormationを使用する場合は、AWSのEC2でロールとセキュリティグループを使用して最小特権を適用することは、どちらもホスティングアプリケーションに安全な環境を提供するためのベストプラクティスです。ただし、その上にマルチテナントDocker環境を階層化すると、状況が崩壊し始めます。

最小限の特権を適用しながらロールのメリットを引き続き享受するための現時点での最善の答えは、マルチテナントアプローチを使用しないことです。基本的に、EC2インスタンスとアプリケーションの間で1対1のマッピングを使用しますが、クラスター/ ASGを使用することもできます。 Dockerは、アプリケーションの管理とデプロイに使用できる非常に便利で強力なツールですが、現時点では、ロールはコンテナーではなくEC2インスタンスに適用されます。つまり、今のところ、アプリケーションごとに別々のVMを使用することを意味します。

マルチテナントであることがロールよりも重要である場合、答えはロールを使用せず、他の方法を使用してAWS認証情報をアプリケーションに配布することです。

残念ながら、これらのソリューションはどちらも非常に望ましいものではなく、主にコンテナの人気が高まっているため、この特定の問題点は将来AWSによって対処されると思います。

1
JaredHatfield