AWS OpsWorks CM と IAM の連携方法

IAM を使用して AWS OpsWorks CM へのアクセスを管理する前に、 AWS OpsWorks CM で使用できる IAM 機能を理解しておく必要があります。 AWS OpsWorks CM およびその他の AWS のサービスが IAM と連携する方法の概要を把握するには、「IAM ユーザーガイド」の「IAM AWS と連携する のサービス」を参照してください。

AWS OpsWorks CM アイデンティティベースのポリシー

IAM アイデンティティベースのポリシーでは、許可または拒否されたアクションとリソース、およびアクションを許可または拒否する条件を指定できます。 AWS OpsWorks CM は、特定のアクション、リソース、および条件キーをサポートします。JSON ポリシーで使用するすべての要素については、『IAM ユーザーガイド』の「IAM JSON policy elements reference (IAM JSON ポリシーエレメントのリファレンス)」を参照してください。

AWS OpsWorks CM では、カスタムポリシーステートメントをユーザー、ロール、またはグループにアタッチできます。

アクション

IAM アイデンティティベースのポリシーの Action エレメントは、そのポリシーにより許可または拒否される特定のアクションについて説明します。ポリシーアクションの名前は通常、関連付けられた AWS API オペレーションと同じです。このアクションは、関連付けられたオペレーションを実行するためのアクセス許可を付与するポリシーで使用されます。

AWS OpsWorks CM のポリシーアクションは、アクションの前にプレフィックス を使用しますopsworks-cm:。たとえば、API オペレーションを使用して AWS OpsWorks CM サーバーを作成するためのアクセス許可を付与するには、ポリシーに opsworks-cm:CreateServer アクションを含めます。ポリシーステートメントには、 Actionまたは NotAction要素を含める必要があります。 AWS OpsWorks CM は、このサービスで実行できるタスクを説明する独自の一連のアクションを定義します。

単一ステートメントに複数アクションを指定するには、次のようにカンマで区切ります:

"Action": [
      "opsworks-cm:action1",
      "opsworks-cm:action2"

ワイルドカード (*) を使用して複数アクションを指定できます。例えば、Describe という単語で始まるすべてのアクションを指定するには、次のアクションを含めます。

"Action": "opsworks-cm:Describe*"

ワイルドカードを使用して複数のアクションをポリシーステートメントで許可する場合は、これらのアクションを許可する先が承認済みのサービスまたは承認済みのユーザーであることを確認してください。

AWS OpsWorks CM アクションのリストを確認するには、「IAM ユーザーガイド」の「AWS のアクション、リソース、および条件キー OpsWorks」を参照してください。

リソース

Resource エレメントは、アクションが適用されるオブジェクトを指定します。ステートメントには、Resource または NotResource エレメントを含める必要があります。ARN を使用して、またはステートメントがすべてのリソースに適用されることを示すワイルドカード *を使用して、リソースを指定します。

AWS OpsWorks CM サーバーまたはバックアップの Amazon リソースナンバー (ARN) を取得するには、 DescribeServers または DescribeBackups API オペレーションを実行し、それらのリソースに基づいてリソースレベルのポリシーを作成します。

AWS OpsWorks CM サーバーリソースには、次の形式の ARN があります。

arn:aws:opsworks-cm:{Region}:${Account}:server/${ServerName}/${UniqueId}

AWS OpsWorks CM バックアップリソースには、次の形式の ARN があります。

arn:aws:opsworks-cm:{Region}:${Account}:backup/${ServerName}-{Date-and-Time-Stamp-of-Backup}

ARN の形式の詳細については、「Amazon リソースネーム (ARNs AWS 「サービス名前空間」を参照してください。

たとえば、ステートメントで test-chef-automate Chef Automate サーバーを指定するには、次の ARN を使用します。

"Resource": "arn:aws:opsworks-cm:us-west-2:123456789012:server/test-chef-automate/EXAMPLE-d1a2bEXAMPLE"

特定のアカウントに属するすべての AWS OpsWorks CM サーバーを指定するには、ワイルドカード (*) を使用します。

"Resource": "arn:aws:opsworks-cm:us-west-2:123456789012:server/*"

次の例では、 AWS OpsWorks CM サーバーのバックアップをリソースとして指定します。

"Resource": "arn:aws:opsworks-cm:us-west-2:123456789012:backup/test-chef-automate-server-2018-05-20T19:06:12.399Z"

リソースを作成するためのアクションなど、一部の AWS OpsWorks CM アクションは、特定のリソースで実行できません。このような場合は、ワイルドカード *を使用する必要があります。

"Resource": "*"

API アクションの多くが複数のリソースと関連します。複数リソースを単一ステートメントで指定するには、ARN をカンマで区切ります。

"Resource": [
      "resource1",
      "resource2"

AWS OpsWorks CM リソースタイプとその ARNs「AWS OpsWorks CM のアクション、リソース、および条件キー」を参照してください。 各リソースの ARN を指定できるアクションについては、IAM ユーザーガイドの「AWS OpsWorks CM のアクション、リソース、および条件キー」を参照してください。

条件キー

AWS OpsWorks CM には、ポリシーステートメントの Condition要素で使用できるサービス固有のコンテキストキーはありません。すべてのサービスで使用できるグローバルな条件コンテキストキーのリストについては、IAM ポリシーのリファレンスの「AWS グローバル条件コンテキスト キー」を参照してください。すべての AWS グローバル条件キーを確認するには、「IAM ユーザーガイド」のAWS 「 グローバル条件コンテキストキー」を参照してください。

Condition 要素 (または Condition ブロック) を使用すると、ステートメントが有効な条件を指定できます。Condition エレメントはオプションです。イコールや以下などの条件演算子を使用する条件表現を構築して、リクエスト内に値のあるポリシーの条件に一致させることができます。

1 つのステートメントに複数の Condition エレメントを指定する場合、または 1 つの Condition エレメントに複数のキーを指定する場合、 AWS が論理 AND 演算を使用してそれらを評価します。1 つの条件キーに複数の値を指定すると、 は論理ORオペレーションを使用して条件 AWS を評価します。ステートメントの権限が付与される前にすべての条件が満たされる必要があります。

条件を指定する際にプレースホルダー変数も使用できます。たとえば、 ユーザー名でタグ付けされている場合のみ、リソースにアクセスする ユーザーアクセス許可を付与できます。詳細については、「IAM ユーザーガイド」の「IAM ポリシーエレメント。可変およびタグ」を参照してください。

例

AWS OpsWorks CM アイデンティティベースのポリシーの例を表示するには、「」を参照してくださいAWS OpsWorks CM アイデンティティベースのポリシーの例。

AWS OpsWorks CM およびリソースベースのポリシー

AWS OpsWorks CM はリソースベースのポリシーをサポートしていません。

リソースベースのポリシーとは、リソース上で指定するプリンシパルとしてのどのアクションをどの条件で実行できるかを指定する JSON ポリシードキュメントです。

AWS OpsWorks CM タグに基づく認可

AWS OpsWorks CM リソースにタグをアタッチしたり、 AWS OpsWorks CM へのリクエストでタグを渡すことができます。タグに基づいてアクセスを制御するには、aws:RequestTag/key-name、または aws:TagKeys の条件キーを使用して、ポリシーの条件要素でタグ情報を指定します。 AWS OpsWorks CM リソースのタグ付けの詳細については、AWS OpsWorks for Puppet Enterprise リソースでのタグの使用このガイドのAWS OpsWorks for Chef Automate リソースでのタグの使用「」または「」を参照してください。

AWS OpsWorks CM IAM ロール

IAM ロールは、特定のアクセス許可を持つ AWS アカウント内のエンティティです。

AWS OpsWorks CM は 2 つのロールを使用します。

• ユーザーの AWS アカウント内で作業するためのアクセス許可を AWS OpsWorks CM サービスに付与するサービスロール。 OpsWorks CM が提供するデフォルトのサービスロールを使用する場合、このロールの名前は ですaws-opsworks-cm-service-role。

• AWS OpsWorks CM サービスが CM OpsWorks API を呼び出すことを許可するインスタンスプロファイルロール。このロールは、バックアップ用のサーバーと Amazon S3 バケットを作成 AWS CloudFormation するための Amazon S3 および へのアクセスを許可します。 OpsWorks CM が提供するデフォルトのインスタンスプロファイルを使用する場合、このインスタンスプロファイルロールの名前は ですaws-opsworks-cm-ec2-role。

AWS OpsWorks CM は、サービスにリンクされたロールを使用しません。

AWS OpsWorks CM による一時的な認証情報の使用

AWS OpsWorks CM は一時的な認証情報の使用をサポートし、その機能を から継承します AWS Security Token Service。

一時的な認証情報を使用して、フェデレーションでサインインする、IAM ロールを引き受ける、またはクロスアカウントロールを引き受けることができます。一時的なセキュリティ認証情報を取得するには、 AssumeRoleや などの AWS STS API オペレーションを呼び出しますGetFederationToken。

サービスリンクロール

AWS OpsWorks CM は、サービスにリンクされたロールを使用しません。

サービスにリンクされたロールを使用すると、 AWS サービスは他の サービスのリソースにアクセスして、ユーザーに代わってアクションを実行できます。サービスリンクロールは IAM アカウント内に表示され、サービスによって所有されます。IAM 管理者は、サービスリンクロールの許可を表示できますが、編集することはできません。

サービスロール

この機能により、ユーザーに代わってサービスがサービスロールを引き受けることが許可されます。このロールにより、サービスがお客様に代わって他のサービスのリソースにアクセスし、アクションを完了することが許可されます。サービスロールは、IAM アカウントに表示され、アカウントによって所有されます。つまり、IAM 管理者は、このロールの権限を変更できます。ただし、それにより、サービスの機能が損なわれる場合があります。

AWS OpsWorks CM は 2 つのロールを使用します。

• ユーザーの AWS アカウント内で作業するためのアクセス許可を AWS OpsWorks CM サービスに付与するサービスロール。 OpsWorks CM が提供するデフォルトのサービスロールを使用する場合、このロールの名前は ですaws-opsworks-cm-service-role。

• AWS OpsWorks CM サービスが CM OpsWorks API を呼び出せるようにするインスタンスプロファイルロール。このロールは、バックアップ用のサーバーと Amazon S3 バケットを作成 AWS CloudFormation するための Amazon S3 および へのアクセスを許可します。 OpsWorks CM が提供するデフォルトのインスタンスプロファイルを使用する場合、このインスタンスプロファイルロールの名前は ですaws-opsworks-cm-ec2-role。

AWS OpsWorks CM で IAM ロールを選択

AWS OpsWorks CM でサーバーを作成するときは、ユーザーに代わって AWS OpsWorks CM が Amazon EC2 にアクセスすることを許可するロールを選択する必要があります。サービスロールを既に作成している場合 AWS OpsWorks 、CM は選択するロールのリストを提供します。 OpsWorks CM は、ロールを指定しない場合、自動的にロールを作成できます。Amazon EC2 インスタンスの起動と停止のためのアクセスを、許可するロールを選択することが重要です。詳細については、Chef Automate サーバーの作成またはPuppet Enterprise マスターの作成を参照してください。