あなたが役割を仮定するとき、何が起こりますか?


AWSセキュリティベストプラクティスのリストの多くの項目のうちの1つは、限られた期間の特定のリソースへの限られたアクセスを許可する役割を使用することです.ときに起動すると、役割を使用してのプロセスは、しばしば簡単ではない場合は、単に“これらのコマンドを実行し、それが動作する”と言われている状況で終了します(Gitを思い出させる).この記事では、カーテンの後ろを見て、役割を担うときに何が起こっているかを学びます.

基礎


プロセスに飛び込む前に、いくつかの用語を取得しましょう.あなたは、ほとんどのIAMのユーザーに精通しているでしょう.これらはAWSの両方のアイデンティティとプリンシパルの例です.アイデンティティは、アイデンティティとアクセス管理の中で実体を特定して、グループ化するのに用いられます.プリンシパルは、AWSアカウントでアクションを取り、APIを呼び出すことができます.これらは密接に関係しており、それはこれらの用語がしばしば交換可能に使用される理由です.しかし、違いがあります.

IAMのグループはプリンシパルではないので、AWSアカウントでアクションを取ることができません.この図では、ユーザとロールだけがアイデンティティとプリンシパルであることがわかります.これらは我々が焦点を当てるつもりです.他の君主は同じように働きます.プリンシパルは、API呼び出しで認証の面倒を見ます.実体は、彼らが彼らがそうであると主張する人であるということを証明しなければなりません.
次のステップはIAMのポリシーでカバーされている承認です.ポリシーは、特定のリソースのプリンシパルに一連のアクションを許可または拒否します.これらの政策は、2つの主要な多様性にあります:アイデンティティベースの、そして、リソースベースの方針.
アイデンティティベースのポリシーは、リソースに属するすべてのアイデンティティとリソースベースのポリシーに接続できます.これらは非常によく似ていますが、いくつかの重要な違いがあります.
  • 展望:アイデンティティベースの政策は、どのAPI呼び出しがこのアイデンティティをどのリソースに対して実行できるかという質問に答えますリソースベースのポリシーは質問に答えます.
  • 構文:リソースベースのポリシーには追加の必須パラメータがあります.この関数はPrincipalと呼ばれます.これは、このステートメントが参照するこのプリンシパルを定義します.
  • アイデンティティベースのポリシーの例
    {
        "Version": "2012-10-17",
        "Statement": [
            {
                "Action": "s3:PutObject",
                "Resource": "*",
                "Effect": "Allow"
            }
        ]
    }
    
    リソースベースのポリシーの例
    {
        "Version": "2012-10-17",
        "Statement": [
            {
                "Action": "s3:PutObject",
                "Principal": {
                    "AWS": "arn:aws:iam::<account-id>:root"
                },
                "Resource": "arn:aws:s3:::mybucket/*",
                "Effect": "Allow"
            }
        ]
    }
    
    認証(プリンシパル)と承認(ポリシー)のメカニズムをカバーしたので、ロールを見てみましょう.役割はAWSのプリンシパルとアイデンティティの両方であり、アカウントのAPI呼び出しを実行する一時的な許可を与える主な目的を持っています.役割を使用するためには、それを仮定しなければなりません.

    各ロールは、役割を仮定できるエンティティを決定する信頼関係を持ちます.また、特権エンティティがロールを仮定した後にどの権限エンティティを取得するかを定義します.それは多くのパーミッションについてであったが、私を信頼している.

    役割を仮定する


    役割を果たすために、我々は役割を使用するために一時的な資格証明書を与えるセキュリティトークンサービス(STS)を使用します.なぜ我々は別々の資格を必要としますか?ロールを仮定すると、APIの呼び出しを行うために使用できる資格情報を取得します.これらの資格情報は、彼らが期限が切れるまでの役割として行動させる.彼らはあなたの元の資格情報とは別ですので、簡単に両方の異なるAPI呼び出しの両方を使用することができます.一時的な資格情報も長期の資格情報とは異なります.

    私たちが役割を仮定するために必要とするAPI呼び出しは、sts:AssumeRoleアクションです.ここでは、セッション名と同様に仮定したいロールのarnを指定する必要があります.セッション名はCloudTrailで表示され、役割を想定した透明なものの一部です.必要に応じて、資格情報の有効期間を指定することもできます.IAMの上限は72時間ですが、各ロールに対してより低い境界を指定できます.
    これが働くために、役割を仮定するプリンシパルはそのアイデンティティ方針でその役割のためにsts:AssumeRole許可を必要とします、そして、プリンシパルは役割の信頼関係でリストされる必要があります.いずれかの呼び出しが失敗した場合は失敗します.許可が正しく設定されている場合、STS応答には4つの情報を持つ資格情報オブジェクトが含まれます.
  • アクセスキーID
  • 秘密のアクセスキー
  • セキュリティトークン
  • 有効期限-資格証明書が
  • を満了するとき、あなたに話すタイムスタンプ
    次に、最初の3つの情報を使用してAPIクライアントをインスタンス化し、ロールの許可を得てAPI呼び出しを行うことができます.今、我々はパズルのすべての作品を知っている、フル画像を可視化しましょう

    1)ユーザはsts:AssumeRoleを呼び出すことができる資格証明書を添付します.彼らはSTSにAPI呼び出しをして、彼らの長期のセキュリティ資格証明で要求に署名します.
    2 ) STSはAPI呼び出しを取得し、それを行う前に、IAMはユーザがこのAPI呼び出しをそのアイデンティティベースのパーミッション( 2 a )で許可する権限を持っているかどうかをチェックします.次に、STSは、ロールの信頼関係が、プリンシパルが(2 b)を仮定できるかどうかをチェックします.
    3 )これらのチェックの両方が成功した場合にのみ、一時的なセキュリティ資格情報がクライアントに返されます.
    4 )ユーザはその後、一時的なセキュリティ資格証明書を使用してAPI呼び出しを行います(例えば、S 3 ).
    私にとって、そのプロセスは私が最初に遭遇したとき、ちょっと混乱しているように見えました.今、私たちは、役割を仮定するか、一時的な資格証明書を使用するとき、いくつかの一般的な問題を見ます.

    トラブルシューティング


    役割を仮定するとき、アクセス拒否


    An error occurred (AccessDenied) when calling the AssumeRole operation: User: arn:aws:... is not authorized to perform: sts:AssumeRole on resource: arn:aws:iam:<account>::role/<rolename>


    これはおそらく最も一般的なエラーです.
  • 役のarnが正しいことを確認してください.
  • はSTSと呼ばれるアイデンティティを確認します.前提には、そのポリシーにアクセス許可があります.
  • 役割の信頼関係が役割を仮定する実体を参照することを確認してください.
  • 2つのポリシーのいずれかで明示的な否定がないことを確認します.
  • 期限切れの資格証明書


    An error occurred (ExpiredToken) when calling the ListBuckets operation: The provided token has expired.


    ロールを仮定すると、しばらく後に期限切れになる一時的な資格情報を取得できます.これはそのように見えます.フィックスはかなり簡単です、あなたは再び役割を仮定して、新しい一時的な資格情報を使用しなければなりません.

    役割を使用するとき、アクセス拒否


    ロールを使用する場合は、アクセスできないエラーが発生しない場合があります.エラーの主な原因は以下の通りです.

  • このパーミッションは実際には、ロールが
  • に付属しているポリシーを見て診断することはできません

  • 実際には、aws sts get-caller-identity API呼び出しを使用して診断することができるロールを使用することはできません.API呼び出しを行うエンティティのarnを指定できます.あなたはこの1つのAPI Docsのための特別な許可を必要としません.
  • 概要


    このポストでは、我々はあなたがAWSで役割を担うとき、舞台裏で行くものを見ました.我々は、アイデンティティ、プリンシパルと使用できる政策の異なる種類を見ました.役割を仮定するワークフローをカバーした後に、我々はまた、若干の一般的なエラーと彼らに対処する方法を見ました.
    うまくいけば、これはあなたにとって有用であり、私はあなたの質問、懸念またはあなたが持っている可能性のあるフィードバックをお待ちしております.あなたがタッチで取得したい場合は、私のバイオを見てください-それを行うにはいくつかの方法があります.
    -モリス