Elastic Beanstalk サービスロールを管理する - AWS Elastic Beanstalk

Elastic Beanstalk サービスロールを管理する

お客様の環境を管理し監視するために、AWS Elastic Beanstalk はお客様に代わって環境のリソースに対してアクションを実行します。Elastic Beanstalk はこれらのアクションを実行するために特定のアクセス許可を必要とし、これらのアクセス許可を取得するために AWS Identity and Access Management (IAM) サービスロールを引き受けます。

Elastic Beanstalk は、サービスロールを引き受けるときはいつでも一時的セキュリティ認証情報を使用する必要があります。これらの認証情報を取得するには、Elastic Beanstalk により、リージョン固有エンドポイントの AWS Security Token Service (AWS STS) にリクエストが送信されます。詳細については、IAM ユーザーガイドの「一時的セキュリティ認証情報」を参照してください。

注記

環境のリージョンの AWS STS エンドポイントが非アクティブ化されている場合、Elastic Beanstalk は、非アクティブ化できない代替エンドポイントでリクエストを送信します。このエンドポイントは別のリージョンに関連付けられているため、リクエストはクロスリージョンリクエストになります。詳細については、『IAM ユーザーガイド』の「AWS リージョンでの AWS STS のアクティブ化と非アクティブ化」を参照してください。

Elastic Beanstalk コンソールと EB CLI の使用によるサービスロールの管理

Elastic Beanstalk コンソールと EB CLI を使用すると、十分なアクセス許可セットで環境のサービスロールを簡単にセットアップできます。デフォルトのサービスロールが作成され、その中の管理ポリシーが使用されます。

マネージドサービスロールのポリシー

Elastic Beanstalk は拡張ヘルスモニタリング用の管理ポリシーと、管理プラットフォームの更新に必要な追加の権限を持つポリシーを提供します。コンソールと EB CLI は、デフォルトのサービスロールを作成する際に、これらのポリシーの両方を割り当てます。

このポリシーは、インスタンスおよび環境の正常性を監視するためのアクセス許可を Elastic Beanstalk に付与します。

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "elasticloadbalancing:DescribeInstanceHealth", "elasticloadbalancing:DescribeLoadBalancers", "elasticloadbalancing:DescribeTargetHealth", "ec2:DescribeInstances", "ec2:DescribeInstanceStatus", "ec2:GetConsoleOutput", "ec2:AssociateAddress", "ec2:DescribeAddresses", "ec2:DescribeSecurityGroups", "sqs:GetQueueAttributes", "sqs:GetQueueUrl", "autoscaling:DescribeAutoScalingGroups", "autoscaling:DescribeAutoScalingInstances", "autoscaling:DescribeScalingActivities", "autoscaling:DescribeNotificationConfigurations", "sns:Publish" ], "Resource": [ "*" ] } ] }

このポリシーは、環境を更新しマネージドプラットフォーム更新を実行するためのアクセス許可を Elastic Beanstalk に付与します。

{ "Version": "2012-10-17", "Statement": [ { "Sid": "AllowCloudformationOperationsOnElasticBeanstalkStacks", "Effect": "Allow", "Action": [ "cloudformation:*" ], "Resource": [ "arn:aws:cloudformation:*:*:stack/awseb-*", "arn:aws:cloudformation:*:*:stack/eb-*" ] }, { "Sid": "AllowS3OperationsOnElasticBeanstalkBuckets", "Effect": "Allow", "Action": [ "s3:*" ], "Resource": [ "arn:aws:s3:::elasticbeanstalk-*", "arn:aws:s3:::elasticbeanstalk-*/*" ] }, { "Sid": "AllowOperations", "Effect": "Allow", "Action": [ "autoscaling:AttachInstances", "autoscaling:CreateAutoScalingGroup", "autoscaling:CreateLaunchConfiguration", "autoscaling:DeleteLaunchConfiguration", "autoscaling:DeleteAutoScalingGroup", "autoscaling:DeletePolicy", "autoscaling:DeleteScheduledAction", "autoscaling:DescribeAccountLimits", "autoscaling:DescribeAutoScalingGroups", "autoscaling:DescribeAutoScalingInstances", "autoscaling:DescribeLaunchConfigurations", "autoscaling:DescribeLoadBalancers", "autoscaling:DescribeNotificationConfigurations", "autoscaling:DescribeScalingActivities", "autoscaling:DescribeScheduledActions", "autoscaling:DetachInstances", "autoscaling:PutNotificationConfiguration", "autoscaling:PutScalingPolicy", "autoscaling:PutScheduledUpdateGroupAction", "autoscaling:ResumeProcesses", "autoscaling:SetDesiredCapacity", "autoscaling:SuspendProcesses", "autoscaling:TerminateInstanceInAutoScalingGroup", "autoscaling:UpdateAutoScalingGroup", "cloudwatch:PutMetricAlarm", "ec2:AuthorizeSecurityGroupEgress", "ec2:AuthorizeSecurityGroupIngress", "ec2:CreateLaunchTemplate", "ec2:CreateLaunchTemplateVersion", "ec2:CreateSecurityGroup", "ec2:DeleteLaunchTemplate", "ec2:DeleteLaunchTemplateVersions", "ec2:DeleteSecurityGroup", "ec2:DescribeAccountAttributes", "ec2:DescribeImages", "ec2:DescribeInstances", "ec2:DescribeKeyPairs", "ec2:DescribeLaunchTemplates", "ec2:DescribeLaunchTemplateVersions", "ec2:DescribeSecurityGroups", "ec2:DescribeSubnets", "ec2:DescribeVpcs", "ec2:RevokeSecurityGroupEgress", "ec2:RevokeSecurityGroupIngress", "ec2:RunInstances", "ec2:TerminateInstances", "ecs:CreateCluster", "ecs:DeleteCluster", "ecs:DescribeClusters", "ecs:RegisterTaskDefinition", "elasticbeanstalk:*", "elasticloadbalancing:ApplySecurityGroupsToLoadBalancer", "elasticloadbalancing:ConfigureHealthCheck", "elasticloadbalancing:CreateLoadBalancer", "elasticloadbalancing:DeleteLoadBalancer", "elasticloadbalancing:DeregisterInstancesFromLoadBalancer", "elasticloadbalancing:DescribeInstanceHealth", "elasticloadbalancing:DescribeLoadBalancers", "elasticloadbalancing:DescribeTargetHealth", "elasticloadbalancing:RegisterInstancesWithLoadBalancer", "iam:ListRoles", "iam:PassRole", "logs:CreateLogGroup", "logs:PutRetentionPolicy", "rds:DescribeDBInstances", "rds:DescribeOrderableDBInstanceOptions", "s3:CopyObject", "s3:GetObject", "s3:GetObjectAcl", "s3:GetObjectMetadata", "s3:ListBucket", "s3:listBuckets", "sns:CreateTopic", "sns:GetTopicAttributes", "sns:ListSubscriptionsByTopic", "sns:Subscribe", "sqs:GetQueueAttributes", "sqs:GetQueueUrl" ], "Resource": [ "*" ] } ] }

Elastic Beanstalk コンソールの使用

Elastic Beanstalk コンソールで環境を起動すると、「aws-elasticbeanstalk-service-role」という名前のデフォルトのサービスロールが作成され、デフォルトのアクセス許可を持つ管理ポリシーがアタッチされます。

Elastic Beanstalk が aws-elasticbeanstalk-service-role ロールを引き受けるように、サービスロールは信頼関係ポリシーで Elastic Beanstalk を信頼済みエンティティとして指定します。

{ "Version": "2012-10-17", "Statement": [ { "Sid": "", "Effect": "Allow", "Principal": { "Service": "elasticbeanstalk.amazonaws.com" }, "Action": "sts:AssumeRole", "Condition": { "StringEquals": { "sts:ExternalId": "elasticbeanstalk" } } } ] }

環境に対してマネージドプラットフォーム更新を有効にすると、Elastic Beanstalk では、マネージド更新を実行するために、独立したマネージド更新サービスロールが使用されます。Elastic Beanstalk コンソールのデフォルトでは、このマネージド更新サービスロールにも、生成された同じサービスロール (aws-elasticbeanstalk-service-role) が使用されます。デフォルトのサービスロールを変更すると、マネージド更新サービスにリンクされたロール (AWSServiceRoleForElasticBeanstalkManagedUpdates) を使用するように、コンソールによってマネージド更新サービスロールが設定されます。サービスにリンクされたロールの詳細については、「サービスにリンクされたロールの使用」を参照してください。

注記

アクセス許可の問題により、サービスにリンクされたロールの作成に Elastic Beanstalk サービスが必ず成功するとは限りません。このため、明示的な作成がコンソールで試行されます。サービスにリンクされたロールがアカウントに確実に付与されるようにするには、コンソールを使用して 1 回以上は環境を作成します。環境を作成する前に、マネージド更新が有効になるように設定する必要があります。

EB CLI の使用

Elastic Beanstalk コマンドラインインターフェイス (EB CLI) の eb create コマンドを使用して環境を起動し、--service-role オプションでサービスロールを指定していない場合、Elastic Beanstalk はデフォルトのサービスロール (aws-elasticbeanstalk-service-role) を作成します。デフォルトのサービスロールが既に存在する場合、Elastic Beanstalk はそのサービスロールを新しい環境で使用します。これは、Elastic Beanstalk コンソールの動作に似ています。

ただし、このコンソールとは異なり、EB CLI コマンドオプションを使用してマネージド更新サービスロールを指定することはできません。環境のマネージド更新を有効にする場合は、設定オプションを使用してマネージド更新サービスロールを設定します。次の例では、マネージド更新を有効にし、デフォルトのサービスロールをマネージド更新サービスロールとして使用しています。

例 .ebextensions/managed-platform-update.config

option_settings: aws:elasticbeanstalk:managedactions: ManagedActionsEnabled: true PreferredStartTime: "Tue:09:00" ServiceRoleForManagedUpdates: "aws-elasticbeanstalk-service-role" aws:elasticbeanstalk:managedactions:platformupdate: UpdateLevel: patch InstanceRefreshEnabled: true

Elastic Beanstalk API の使用によるサービスロールの管理

Elastic Beanstalk API の CreateEnvironment アクションを使用して環境を作成する場合は、aws:elasticbeanstalk:environment 名前空間の ServiceRole 設定オプションを使用して、サービスロールを指定します。Elastic Beanstalk API で拡張ヘルスモニタリングを使用する方法の詳細については、「Elastic Beanstalk API での拡張ヘルスレポートの使用」を参照してください。

さらに、環境に対してマネージドプラットフォーム更新を有効にする場合は、aws:elasticbeanstalk:managedactions 名前空間の ServiceRoleForManagedUpdates オプションを使用してマネージド更新サービスロールを指定できます。

サービスにリンクされたロールの使用

サービスにリンクされたロールは、Elastic Beanstalk によって事前定義された一意のタイプのサービスロールであり、お客様の代わりにサービスから AWS の他のサービスを呼び出すために必要なアクセス権限がすべて含まれています。このサービスにリンクされたロールは、お客様のアカウントに関連付けられます。Elastic Beanstalk は、一度作成したロールを、追加の環境を作成する際に再利用します。Elastic Beanstalk 環境でサービスにリンクされたロールを使用する方法の詳細については、「Elastic Beanstalk のサービスにリンクされたロールの使用」を参照してください。

Elastic Beanstalk API を使用して環境を作成したときに、サービスロールを指定しなかった場合、Elastic Beanstalk では、モニタリングサービスにリンクされたロールがアカウント用に作成され (まだ存在していない場合)、そのロールが新しい環境で使用されます。IAM を使用して、アカウントのモニタリングサービスにリンクされたロールを事前に作成することもできます。モニタリングサービスにリンクされたロールがアカウントに設定されている場合は、これを使用して Elastic Beanstalk API、Elastic Beanstalk コンソール、または EB CLI で環境を作成できます。

さらに、環境に対してマネージドプラットフォーム更新を有効にし、aws:elasticbeanstalk:managedactions 名前空間の ServiceRoleForManagedUpdates オプションの値として AWSServiceRoleForElasticBeanstalkManagedUpdates を指定した場合は、アカウントに対してマネージド更新サービスにリンクされたロールが Elastic Beanstalk によって作成され (まだ存在していない場合)、それを使用して新しい環境のマネージド更新が実行されます。

注記

環境の作成時に Elastic Beanstalk でモニタリングサービスおよびマネージド更新サービスにリンクされたロールをアカウントに作成する場合は、iam:CreateServiceLinkedRole アクセス許可が必要です。このアクセス許可がない場合、環境の作成は失敗し、問題を説明するメッセージが表示されます。

別の方法として、サービスにリンクされたロールを作成する権限を持つ別のユーザーが IAM を使用して、サービスにリンクされたロールを事前に作成できます。この場合は、iam:CreateServiceLinkedRole アクセス許可がなくても、環境を作成できます。

デフォルトのサービスロールのアクセス許可を確認する

デフォルトのサービスロールに付与されるアクセス権限は、作成日時、最後に環境を起動した日時、使用したクライアントにより異なります。デフォルトのサービスロールに付与されるアクセス権限は IAM コンソールで確認できます。

デフォルトのサービスロールのアクセス権限を確認する

  1. IAM コンソールの [ロール] ページを開きます。

  2. [aws-elasticbeanstalk-service-role] を選択します。

  3. [Permissions (アクセス許可)] タブで、ロールにアタッチされたポリシーのリストを確認します。

  4. ポリシーにより付与されるアクセス権限を表示するには、ポリシーを選択します。

古くなったデフォルトのサービスロールを更新する

必要なアクセス権限がデフォルトのサービスロールに付与されていない場合は、Elastic Beanstalk 環境マネジメントコンソールで新しい環境を作成し、権限を更新します。

あるいは、デフォルトのサービスロールに管理ポリシーを手動で追加しても構いません。

デフォルトのサービスロールに管理ポリシーを追加する

  1. IAM コンソールの [ロール] ページを開きます。

  2. [aws-elasticbeanstalk-service-role] を選択します。

  3. [Permissions (アクセス許可)] タブで、[Attach policy (ポリシーのアタッチ)] を選択します。

  4. ポリシーをフィルタリングするには、「AWSElasticBeanstalk」と入力します。

  5. 次のポリシーを指定し、[Attach policy (ポリシーのアタッチ)] を選択します。

    • AWSElasticBeanstalkEnhancedHealth

    • AWSElasticBeanstalkService

デフォルトのサービスロールにアクセス許可を付与する

アプリケーションに含まれている設定ファイルがデフォルトのサービスロールでアクセス権限の含まれていない AWS リソースを参照する場合、マネージド更新での設定ファイル処理時にこのリファレンスが解決できるよう Elastic Beanstalk でその他のアクセス権限が必要となることがあります。アクセス権限がない場合、更新は失敗し Elastic Beanstalk からアクセス権限が必要であるというメッセージが返されます。IAM コンソールで、デフォルトのサービスロールにその他のサービスのアクセス権限を追加します。

デフォルトのサービスロールにその他のポリシーを追加する

  1. IAM コンソールの [ロール] ページを開きます。

  2. [aws-elasticbeanstalk-service-role] を選択します。

  3. [Permissions (アクセス許可)] タブで、[Attach policy (ポリシーのアタッチ)] を選択します。

  4. アプリケーションで使用する追加サービスの管理ポリシーを選択します。例えば、AmazonAPIGatewayAdministratorAmazonElasticFileSystemFullAccess などです。

  5. [Attach policy] を選択します。

サービスロールの作成

デフォルトのサービスロールを使用できない場合は別途サービスロールを作成します。

サービスロールを作成する

  1. IAM コンソールの [ロール] ページを開きます。

  2. [Create role] を選択します。

  3. [AWS service (AWS のサービス)] で、[AWS Elastic Beanstalk]、ユースケースの順に選択します。

  4. [Next: Permissions (次へ: アクセス許可)] を選択します。

  5. AWSElasticBeanstalkServiceAWSElasticBeanstalkEnhancedHealth の管理ポリシー、ならびにアプリケーションで必要なアクセス権限を付与するその他のポリシーがあればそれらもアタッチします。

  6. [Next: Tags (次の手順: タグ)] を選択します。

  7. (オプション) ロールにタグを追加します。

  8. [Next: Review] を選択します。

  9. ロールの名前を入力します。

  10. [Create role] を選択します。

環境を、環境の作成ウィザード、または --service-role オプション eb create コマンドで作成すると、カスタムサービスロールを適用できます。