IAMロールとIAMユーザーの違いは何ですか? IAM FAQ にはそれを説明するエントリがありますが、あいまいで、あまり明確ではありません。
IAMユーザーは永続的な長期資格情報を持ち、AWSサービスと直接対話するために使用されます。 IAMロールには認証情報がなく、AWSサービスに直接リクエストすることはできません。 IAMロールは、IAMユーザー、アプリケーションなどの許可されたエンティティ、またはEC2などのAWSサービスによって引き継がれます。
IAMロールはフェデレーションログインに使用され(たとえばSAMLトークンでIdPを使用)、通常のIAMユーザーのようにダウンロードできる永続的なアクセスキーがないと思います(「IAMロールには何もありません資格情報」の部分)。
IAMロールがAWSサービスに直接リクエストを送信できないと言うとき、彼らはどういう意味ですか? AWSコンソール(ウェブコンソール)にログインしてスタックなどを作成できるので、それはできません。
IAMロールがAWSサービスに直接リクエストを送信できないと言うとき、彼らはどういう意味ですか? AWSコンソール(ウェブコンソール)にログインしてスタックなどを作成できるので、それはできません。
あなたはIAMユーザーです(一部のIAMロールがアタッチされています)。
IAMロールをcapabilitiesと考えてください。
IAMユーザー機能を指定します(例:「はLambda関数を作成できます」、「はS3にアップロードできます ")。
フェデレーションユーザーに関する注意:
http://docs.aws.Amazon.com/IAM/latest/UserGuide/id.html から:
IAMの代わりに外部IDプロバイダーを使用してサインインするフェデレーションユーザーにロールを割り当てることができます。 AWSは、IDプロバイダーから渡された詳細を使用して、フェデレーションユーザーにマッピングされるロールを決定します。
したがって、フェデレーションユーザーは、IAMロールをアタッチできるIAMユーザーに似ています。外部IDプロバイダーがあることを除きます。
技術的には、AWSコンソールにログインするときに、IDとしてロールを使用していません。フェデレーションユーザーアカウント(独自のロールが割り当てられている)をIDとして使用しています。
違いを理解するために、IAMの基礎知識を見てみましょう
IAMコントロール:AWSアカウントで誰(認証)が何を(認証)できるか。 IAMでの認証(誰)はユーザー/グループおよびロールで行われ、承認(何)はポリシーで行われます。
ここで用語
グループ-1つの許可セット(ポリシー)の下のユーザーセット
役割-一定期間、特定のアクターに特定の許可を与えるために使用されます。これらのアクターは、AWSまたは信頼できる外部システムによって認証を受けることができます。
ユーザーとロールは、許可にポリシーを使用します。ポリシーで特定のアクションを許可するまで、ユーザーとロールは何もできないことに注意してください。
ユーザーとロールを区別する次の質問に答えますか?
AWSはさまざまなシナリオで3つのロールタイプをサポートしています
ロールが何であるかを理解するには、そのユースケースを読む必要があります。車輪を再発明したくないので、次のAWSドキュメントをお読みください: https://aws.Amazon.com/blogs/security/how -to-use-a-single-iam-user-to-easily-access-all-your-accounts-by-using-the-aws-cli /
https://docs.aws.Amazon.com/IAM/latest/UserGuide/id_roles_providers_saml.html
それが役に立てば幸い。
IAMの主なアクターはsers、groups、rolesおよびpoliciesです。そして、AWSについて理解する必要があり、決して忘れないことは
AWSのすべてはAPIです
APIまたはそのメソッドを実行するには、まず特定のユーザー/グループ/ロールを認証してから承認する必要があります。
例:オペレーターがS3バケットにオブジェクトを配置したいと考えています。このプロセスは、AWS内の一連のAPI呼び出しを通じて行われます。基本的に、S3 APIとそのメソッドを呼び出して、オブジェクトを特定のバケットに配置します(メソッドput_object_in_s3
など)。そのために、バケット、オブジェクトの名前を提供することができます。最も重要なのは、AWS APIエンジンにこのユーザー/グループ/役割です。
API Engineが最初に行うことは、APIで送信される資格情報を確認することです。次に、このリクエストが実際の有効なユーザー、グループ、またはロールからのものであることを示す、これらの資格情報(それらが正しいかどうか)を検証します。次に、APIエンジンが行うことは(このAPIリクエストの送信者を知っているため)、特定のオペレーター(ユーザーまたはロール)に関連付けられたポリシードキュメントを取得し、単一のビューとして評価します。つまり、APIで呼び出されたアクションがそのオペレーターに対して許可されているかどうかを確認します。
IAMユーザー-IAMのコンテキストでは、ユーザーは「永続的な」名前付きオペレーター(人間またはマシン)です。重要なのは、資格情報(資格情報はユーザー名、パスワード、アクセスキー、シークレットキーなど)が永続的であり、その指定ユーザーにとどまることです。そのため、AWSは、このユーザーの認証方法(ユーザー名、パスワード、認証方法、シークレットキーなど)が何であるかを(その永続的なものとしてユーザーに留まります)知っています。
IAMグループ-上の画像のように、グループはユーザーのコレクションです。また、ユーザーは多くのグループにも所属できることに注意してください。
IAMロール-ロールはパーミッションではありません!!!。ロールは、IAMユーザーおよびグループと同様に認証方法でもあります。ユーザーとしての役割は、オペレーターでもあります(人間の場合もあれば、マシンの場合もあります)。違いは、役割を持つ資格情報が一時的なものであることです。
ポリシードキュメント-前述のように、ロールはアクセス許可ではありません。 AWSのアクセス許可は、Policy Documents
というオブジェクトによって完全に処理されます。ポリシードキュメントはJSONドキュメントです。ポリシードキュメントは、ユーザー、グループ、またはロールに直接添付できます。ポリシー文書が上記の演算子のいずれかに添付されると、権限を取得するものだけが処理を行います。ポリシードキュメントには、次のようなものがリストされます:特定のAPIまたはリソースのホワイトリストに登録されるAPIのワイルドカードグループ、およびそれらのAPI実行の条件(ホームネットワーク内のこのユーザー、グループまたは役割、または任意の場所から許可する場合のみ許可、許可する場合のみ特定の時間帯など)
最後になりましたが、AWSでの認証は(IAMユーザー、グループ、ロール)を介して行われますが、承認はポリシーによって行われます。
IAMユーザーは、個人またはアプリケーションが使用できるアカウントです。ユーザーは、ログインしてそのアカウントに割り当てられた権限でアクションを実行するための資格情報を持っています。
IAMロールは、リソースが引き受けることができる仮想的なものです。たとえば、EC2インスタンスはロールを引き受け、割り当てられた権限でAWSコマンドを実行できます。 APIゲートウェイ、Lambda、Kinesis、RDSなどの他のサービスについても同じことが言えます。
IAMロールがAWSサービスに直接リクエストを送信できないと言うとき、彼らはどういう意味ですか?
ロール自体は、誰かまたは何かが引き受ける必要があるため、タスクを実行できません。誰かがIDフェデレーションを介してログインし、役割を引き受けることもできます。
IAMユーザー-AWSリソースにアクセスするユーザー/アプリケーションIAMロール-ユーザーまたはリソースに適用できるアクセス許可/ポリシーのセット。
IAMユーザーとAWSリソースにもロールを適用できます。たとえば、IAMロールをLambda関数に適用します。機能はそのIAMロールでのみ可能です。