IAM 信頼ポリシーエラー「Failed to update trust policy. Invalid principal in policy.」を解決するにはどうすればよいですか?

所要時間2分
0

AWS マネジメントコンソールを使用してAWS Identity and Access Management (IAM) ロールの信頼ポリシーを編集しようとすると、「Failed to update trust policy. Invalid principal in policy.」というエラーが表示されます。

簡単な説明

このエラーメッセージは、IAM 信頼ポリシーの Principal 要素の値が無効であることを示しています。このエラーを解決するには、以下を確認します。

  • IAM ロールの信頼ポリシーで、Principal 要素に対してサポートされている値が正しい形式で使用されていること。
  • IAM ロールの信頼ポリシーで IAM アイデンティティ (ユーザー、ユーザーグループ、ロール) がプリンシパルとして使用されている場合は、ユーザーまたはロールが削除されていないこと。

注: 標準の AWS アカウントが AWS GovCloud (米国) のアカウント番号を追加しようとすると、AWS GovCloud (米国) アカウントでもこのエラーが表示される場合があります。AWS GovCloud (米国) アカウントと標準の AWS アカウントの間のアクセスを委任するロールを作成することはできません。詳細については、「How IAM Differs for AWS GovCloud (US)」を参照してください。

解決策

Principal 要素でサポートされる値の確認

ロールの IAM 信頼ポリシーの Principal 要素には、以下のサポートされている値が含まれている必要があります。

1.IAM ポリシーに、次のように正しい 12 桁の AWS アカウント ID が含まれていることを確認します。

"Principal": {
"AWS": "123456789012"
}

注: AWS アカウントは、ルートユーザーの Amazon リソースネーム (ARN) を使用して指定することもできます。例えば、arn:aws:iam::123456789012:root のように指定します。

2.IAM 信頼ポリシーのプリンシパルが IAM ユーザー、ロール、またはフェデレーションユーザーである場合は、次のように ARN 全体を指定する必要があります。

"Principal": {
  "AWS": [
    "arn:aws:iam::123456789012:user/user-name",
    "arn:aws:iam::123456789012:role/role-name",
    "arn:aws:sts::123456789012:assumed-role/role-name/role-session-name",
    "arn:aws:sts::123456789012:federated-user/user-name"
  ]
}

3.IAM 信頼ポリシーにワイルドカードが含まれている場合は、以下のガイドラインに従います。

注: プリンシパル名や ARN の一部に対応させるためにワイルドカード "*" を使用することはできません。

次の例では、IAM 信頼ポリシーでワイルドカードが誤って使用されています。

"Principal": {
  "AWS": "arn:aws:iam::123456789012:user/user-*"
}

ワイルドカードを使用してプリンシパル名の一部に対応させるには、Condition 要素とグローバル条件キー aws:PrincipalArn を使用します。 次に、ワイルドカードを使用して ARN を指定します。

すべての AWS アカウントのアイデンティティを指定するには、次のようにワイルドカードを使用します。

"Principal": {
  "AWS": "*"
}

重要: 信頼ポリシーでは、Principal 要素でワイルドカードを使用し、Allow 効果を指定することができます。ただし、これにより、同じパーティション内のすべての AWS アカウントの IAM ユーザー、引き受けられたロールセッション、またはフェデレーションユーザーがロールにアクセスできるようになります。AWS アカウント内の IAM ユーザーおよびロールプリンシパルには、他のアクセス許可は不要です。他の AWS アカウントのプリンシパルが IAM ロールを引き受けるには、アイデンティティベースのアクセス許可が必要です。

この方法では、ウェブ ID セッションプリンシパル、SAML セッションプリンシパル、またはサービスプリンシパルはリソースにアクセスできません。

ベストプラクティスとして、この方法は、Condition 要素と aws:PrincipalArn などの条件キーを使用してアクセス許可を制限する場合にのみ使用してください。例えば、ファイルは次のようになる場合があります。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "*"
      },
      "Action": "sts:AssumeRole",
      "Condition": {
        "StringLike": {
          "aws:PrincipalArn": "arn:aws:iam::123456789012:user/user-*"
        }
      }
    }
  ]
}

この信頼ポリシーの例では、aws:PrincipalArn 条件キーを使用して、一致するユーザー名を持つユーザーのみに対して IAM ロールの引き受けを許可しています。

4.IAM ロールが AWS サービスロールの場合は、サービスプリンシパル全体を次のように指定する必要があります。

"Principal": {
  "Service": "ec2.amazonaws.com"
}

5.SAML セッションプリンシパルと外部 SAML ID プロバイダーを使用して IAM ユーザーを認証できます。IAM ロールの信頼ポリシーには、次のような Principal 要素が必要です。

"Principal": {
  "Federated": "arn:aws:iam::123456789012:saml-provider/provider-name"
}

6.ウェブ ID セッションプリンシパルを使用して IAM ユーザーを認証できます。アクセスを提供する IAM ロールの信頼ポリシーには、次のような Principal 要素が必要です。

"Principal": {
  "Federated": "cognito-identity.amazonaws.com"
}

7.1 つのステートメント内で異なるプリンシパルタイプを使用する場合は、次のような形式で IAM 信頼ポリシーを指定します。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::123456789012:user/user-name",
        "Service": "ec2.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

IAM ユーザーまたはロールは既存の ID でなければならない

IAM ロールの信頼ポリシーで IAM ユーザーまたはロールがプリンシパルとして使用されている場合は、それらの IAM ID が削除されていないことを確認してください。IAM 信頼ポリシーを変更したときにプリンシパルが既に削除されていた場合、「Invalid principal in policy」というエラーが発生します。

注: プリンシパルが削除されていた場合は、ARN ではなく、IAM 信頼ポリシー内のプリンシパルの一意の ID を書き留めてください。

関連情報

IAM を使用してリソースへのユーザーアクセスを許可するにはどうすればよいですか?

AWS IAM を使用して他の AWS アカウントのリソースにアクセスするにはどうすればよいですか?

IAM リソースベースのポリシーに不明なプリンシパル形式が含まれているのはなぜですか?

コメントはありません

関連するコンテンツ