プレーンなEC2環境内では、IAMロールと認証情報（インスタンスのメタデータから自動的に取得される）を使用して、他のAWSリソースへのアクセスを管理するのは非常に簡単です。CloudFormationを使用するとさらに簡単になり、特定のアプリケーションロールをインスタンスに割り当てると、その場でロールを作成できます。
Dockerに移行し、Mマシンとその上で実行されるNアプリケーションがあるようなM-to-N展開を行う場合、アプリケーションごとのAWSリソースへのアクセスを制限するにはどうすればよいですか？インスタンスのメタデータにはホスト上の誰でもアクセスできるため、すべてのアプリケーションが同じデプロイメント環境内の他のすべてのアプリケーションのデータを表示/変更できるようにします。
そのような環境で実行されているアプリケーションコンテナにセキュリティ資格情報を提供するためのベストプラクティスは何ですか？
回答:
このプロジェクトがあります：https : //github.com/dump247/docker-ec2-metadata
インスタンスメタデータエンドポイントのプロキシとして機能し、コンテナ固有のロールを返します。私はそれを使用したことがありませんが、それはあなたが説明しているユースケースを解決するようです。
特にCloudFormationを使用している場合、EC2を使用するAWSでロールとセキュリティグループを使用して最小限の特権を適用することは（言及していなくても）両方ともベストプラクティスです。ただし、その上にマルチテナントDocker環境を重ねると、物事がバラバラになり始めます。
最小限の特権を適用しながらロールの利点を引き続き得るための現時点での最良の答えは、マルチテナントアプローチを使用しないことです。基本的に、EC2インスタンスとアプリケーションの間で1対1のマッピングを使用しますが、クラスター/ ASGを引き続き使用できます。Dockerは、アプリケーションの管理とデプロイに使用できる非常に便利で強力なツールですが、現時点では、ロールはコンテナではなくEC2インスタンスに適用されます。それは、今のところ各アプリケーションに別々のVMを使用することを意味します。
マルチテナントであることがロールよりも重要な場合、答えはロールを使用せず、他の方法を使用してアプリケーションにAWS認証情報を配布することです。
残念ながら、これらのソリューションはどちらも非常に望ましくなく、主にコンテナの人気が高まっているため、この特定の問題点は今後AWSによって対処されると予想しています。