翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
AWS Systems Manager を使用して no-ingress EC2 インスタンスにアクセスする
EC2 環境用に作成された「no-ingress EC2 インスタンス」により、AWS Cloud9 がそのインスタンスのインバウンドポートを開かなくても、その Amazon EC2 インスタンスへの接続が有効になります。コンソール、コマンドラインインターフェイス、またはAWS CloudFormation スタックを使って、EC2 環境を作成するときに、no-ingress オプションを選択できます。
重要
Systems Manager Session Manager 使って EC2 インスタンスへの接続を管理する場合、追加料金は発生しません。
コンソールの [Create environment] (環境の作成) ページで環境タイプを選択するときに、インバウンド接続を必要とする新しい EC2 インスタンスを選択するか、次を必要としない新しい no-ingress EC2 インスタンスを選択できます。
-
新しい EC2 インスタンス — この設定の場合、インスタンスのセキュリティグループには、着信ネットワークトラフィックを許可するルールがあります。着信ネットワークトラフィックはAWS Cloud9 接続のため承認された IP アドレスに制限されています。受信ポートが開いていると、AWS Cloud9 が有効になり、SSH 経由でインスタンスに 接続します。AWS Systems Manager Session Manager を使用すると、インバウンドポートを開くことなく (no ingress)、SSM 経由で Amazon EC2 インスタンスにアクセスできます。この方法は、新しい Amazon EC2 インスタンスでのみ使用できます。詳細については、「EC2 環境でSystems Manager を使用する利点」を参照してください。
-
既存のコンピューティング — この設定の場合、SSH ログインの詳細を必要とする既存の Amazon EC2 インスタンスにアクセスします。このインスタンスにはインバウンドセキュリティグループルールが必要です。このオプションを使用する場合は、サービスロールが自動的に作成されます。サービスロールの名前は、設定画面の下部にある注記で確認できます。
AWS CLI を使用して環境を作成する場合、create-environment-ec2 コマンドを呼び出す時に、--connection-type CONNECT_SSM オプションを設定して、no-ingress EC2 インスタンスを設定できます。必要なサービスロールとインスタンスプロファイルの作成に関する詳細については、「AWS CLI を使ったSystems Manager のインスタンスプロファイルの管理」を参照してください。
no-ingress EC2 インスタンスを使用する環境の作成が完了したら、以下を確認します。
-
Systems Manager Session Manager には、ユーザーに代わって EC2 インスタンスでアクションを実行する許可がおりています。詳細については、「Systems Manager 許可の管理」を参照してください。
-
AWS Cloud9 ユーザーは、Session Manager によって管理されるインスタンスにアクセスできます。詳細については、「Session Manager によって管理されているインスタンスへのアクセスをユーザーに与える」を参照してください。
EC2 環境でSystems Manager を使用する利点
Session Manager に、AWS Cloud9 とその EC2 インスタンスの間でセキュアな接続を処理する許可を与えると、次の 2 つのキーとなる利点が生まれます。
-
インスタンスのインバウンドポートを開く必要がない
-
パブリックサブネットまたはプライベートサブネットでインスタンスを起動するオプション
Systems Manager 許可の管理
デフォルトでは、Systems Manager には、EC2 インスタンス上でアクションを実行する許可がありません。アクセスは AWS Identity and Access Management (IAM) インスタンスプロファイルを通じて提供されます。(インスタンスプロファイルは、起動時に EC2 インスタンスに IAM ロール情報を渡すコンテナです。)
AWS Cloud9 コンソールを使って no-ingress EC2 インスタンスを作成する時に、サービスロール (AWSCloud9SSMAccessRole) とIAM インスタンスプロファイル (AWSCloud9SSMInstanceProfile) の両方がユーザーのため、自動的に作成されます。(IAM マネジメントコンソールで AWSCloud9SSMAccessRole を表示できます。 インスタンスプロファイルは IAM コンソールに表示されません)。
重要
AWS CLI を使って no-ingress EC2 環境を初めて作成するのであれば、必要なサービスロールとインスタンスプロファイルを明示的に定義する必要があります。詳細については、「AWS CLI を使ったSystems Manager のインスタンスプロファイルの管理」を参照してください。
重要
AWS Cloud9 環境を作成し、AWSCloud9Administrator ポリシーまたは AWSCloud9User ポリシーをアタッチした Amazon EC2 Systems Manager を使用する場合、特定の IAM アクセス許可を持つカスタムポリシーもアタッチする必要があります。「SSM 環境作成用のカスタム IAM ポリシー」を参照してください。これは、AWSCloud9Administrator ポリシーと AWSCloud9User ポリシーに伴うアクセス許可の問題が原因です。
セキュリティ保護を強化するために、AWS Cloud9 サービスにリンクされたロール、AWSServiceRoleforAWSCloud9は、AWSCloud9ServiceRolePolicy ポリシーにある PassRole 制限を特徴としています。IAM ロールをサービスにPass (適用) すると、そのサービスがロールを引き受け、ユーザーに代わってアクションを実行できる許可がでます。この場合は、PassRole 許可により、AWS Cloud9 が AWSCloud9SSMAccessRole ロール (およびその許可)を適用できるのは、 EC2 インスタンスだけになります。これにより、EC2 インスタンスで実行できるアクションは、AWS Cloud9 が必要とするもののみに限定されます。
注記
Systems Manager を使用してインスタンスにアクセスする必要がなくなった場合は、AWSCloud9SSMAccessRole サービスロールを削除できます。詳細については、IAM ユーザーガイドの「ロールまたはインスタンスプロファイルを削除する」を参照してください。
AWS CLI を使ったSystems Manager のインスタンスプロファイルの管理
また、AWS CLI を使って no-ingress EC2 環境を作成できます。create-environment-ec2 を呼び出すとき、--connection-typeオプションをCONNECT_SSM に設定します。
このオプションを使用する場合、AWSCloud9SSMAccessRole サービスロールと AWSCloud9SSMInstanceProfile は自動的に作成されません。そのため、必要なサービスプロファイルとインスタンスプロファイルを作成するには、次のいずれかを行います。
-
コンソールを使って EC2 環境を作成すると、その後は自動的に
AWSCloud9SSMAccessRoleサービスロールとAWSCloud9SSMInstanceProfileが自動的に作成されます。作成後、サービスロールとインスタンスプロファイルは、AWS CLI を使って作成した追加 EC2 環境で利用できます。 -
次の AWS CLI コマンドを実行して、サービスロールとインスタンスプロファイルを作成します。
aws iam create-role --role-name AWSCloud9SSMAccessRole --path /service-role/ --assume-role-policy-document '{"Version": "2012-10-17","Statement": [{"Effect": "Allow","Principal": {"Service": ["ec2.amazonaws.com","cloud9.amazonaws.com"] },"Action": "sts:AssumeRole"}]}' aws iam attach-role-policy --role-name AWSCloud9SSMAccessRole --policy-arn arn:aws:iam::aws:policy/AWSCloud9SSMInstanceProfile aws iam create-instance-profile --instance-profile-name AWSCloud9SSMInstanceProfile --path /cloud9/ aws iam add-role-to-instance-profile --instance-profile-name AWSCloud9SSMInstanceProfile --role-name AWSCloud9SSMAccessRole
Session Manager によって管理されているインスタンスへのアクセスをユーザーに与える
Systems Manager を介して EC2 インスタンスに接続しているAWS Cloud9 環境を開くには、ユーザーに API オペレーションの許可である StartSession がおりている必要があります。このオペレーションにより、Session Manager セッション用マネージド EC2 インスタンスへの接続が開始されます。AWS Cloud9 特定のマネージドポリシー (推奨) を使用するか、IAM ポリシーを編集して必要なアクセス権限を追加して、ユーザーにアクセス権を付与します。
| [Method] (メソッド) | 説明 |
|---|---|
|
AWS Cloud9 固有のマネージドポリシーを使用する |
以下を使用することをお勧めします。AWS マネージドポリシーを使用して、Systems Manager が管理する EC2 インスタンスへのユーザーのアクセスを許可します。マネージドポリシーは、スタンダード AWS Cloud9 ユースケースを使用しており、IAM エンティティに簡単に添付できます。 すべてのマネージドポリシーには、
重要AWS Cloud9 環境を作成し、 詳細については、「AWS の マネージドポリシー AWS Cloud9」を参照してください。 |
|
IAM ポリシーを編集し、必要なポリシーステートメントを追加する |
既存のポリシーを編集するため、 ポリシーを編集するときに、 |
次のアクセス許可を使用すると、StartSession API オペレーションの実行が有効になります。インスタンスがAWS Cloud9 EC2 開発環境 (aws:cloud9:environment)という条件で、ssm:resourceTag 条件キーは、Session Manager セッションを任意のインスタンス (Resource: arn:aws:ec2:*:*:instance/*) のためにスタートできます。
注記
次のマネージドポリシーには、AWSCloud9Administrator、AWSCloud9User、およびAWSCloud9EnvironmentMember というポリシーステートメントも含まれています。
{ "Effect": "Allow", "Action": "ssm:StartSession", "Resource": "arn:aws:ec2:*:*:instance/*", "Condition": { "StringLike": { "ssm:resourceTag/aws:cloud9:environment": "*" }, "StringEquals": { "aws:CalledViaFirst": "cloud9.amazonaws.com" } } }, { "Effect": "Allow", "Action": [ "ssm:StartSession" ], "Resource": [ "arn:aws:ssm:*:*:document/*" ] }
AWS CloudFormation を使用して、no-ingress EC2 環境を作成する
AWS CloudFormationテンプレートを使用して、no-ingress Amazon EC2 開発環境を定義する場合は、スタックを作成する前に次のことを行います。
-
AWSCloud9SSMAccessRoleサービスロールとAWSCloud9SSMInstanceProfileインスタンスプロファイルを作成します。詳細については、「AWS CloudFormation テンプレートでサービスロールとインスタンスプロファイルを作成する」を参照してください。 -
AWS CloudFormation を呼び出す IAM エンティティエンティティのポリシーを更新します。こうすることで、EC2 インスタンスに接続する Session Manager セッションをスタートできます。詳細については、「IAM ポリシーに Systems Manager 許可を追加する」を参照してください。
AWS CloudFormation テンプレートでサービスロールとインスタンスプロファイルを作成する
サービスロール AWSCloud9SSMAccessRole とインスタンスプロファイル AWSCloud9SSMInstanceProfileを作成して、Systems Manager による開発環境をバックアップする EC2 インスタンスの管理を有効にします。
no-ingress EC2 環境 with the console を作成またはAWS CLI コマンドの実行によって、AWSCloud9SSMAccessRole および AWSCloud9SSMInstanceProfile を以前に作成済みである場合は、サービスロールとインスタンスプロファイルはすでに使用可能です。
注記
例えば、no-ingress EC2 環境に AWS CloudFormation スタックを作成しようとしたものの、必要なサービスロールとインスタンスプロファイルを最初に作成しなかったとします。そうすると、スタックは作成されず、次のエラーメッセージが表示されます。
インスタンスプロファイル AWSCloud9SSMinStanceProfile がアカウントに存在しません。
AWS CloudFormation を使って no-ingress EC2 環境を初めて作成する場合、テンプレートで AWSCloud9SSMAccessRole および AWSCloud9SSMInstanceProfile を IAM リソースとして定義します。
サンプルテンプレートからのこの抜粋は、これらのリソースを定義する方法を示しています。AssumeRole アクションは、アクセスをAWS Cloud9 環境とそのEC2 インスタンスの両方に提供するセキュリティ認証情報を返します。
AWSTemplateFormatVersion: 2010-09-09 Resources: AWSCloud9SSMAccessRole: Type: AWS::IAM::Role Properties: AssumeRolePolicyDocument: Version: 2012-10-17 Statement: - Effect: Allow Principal: Service: - cloud9.amazonaws.com - ec2.amazonaws.com Action: - 'sts:AssumeRole' Description: 'Service linked role for AWS Cloud9' Path: '/service-role/' ManagedPolicyArns: - arn:aws:iam::aws:policy/AWSCloud9SSMInstanceProfile RoleName: 'AWSCloud9SSMAccessRole' AWSCloud9SSMInstanceProfile: Type: "AWS::IAM::InstanceProfile" Properties: InstanceProfileName: AWSCloud9SSMInstanceProfile Path: "/cloud9/" Roles: - Ref: AWSCloud9SSMAccessRole
IAM ポリシーに Systems Manager 許可を追加する
AWS CloudFormation テンプレートでサービスロールとインスタンスプロファイルを定義した後、スタックを作成する IAM エンティティに Session Manager セッションをスタートする許可があることを確認してください。セッションは、Session Manager を使用した EC2 インスタンス への接続です。
注記
no-ingress EC2 環境用のスタックを作成する前に Session Manager セッションをスタートする許可を追加しない場合、AccessDeniedException エラーが返されます。
AWS CloudFormation を呼び出すため、次のアクセス許可を IAM エンティティのポリシーに追加します。
{ "Effect": "Allow", "Action": "ssm:StartSession", "Resource": "arn:aws:ec2:*:*:instance/*", "Condition": { "StringLike": { "ssm:resourceTag/aws:cloud9:environment": "*" }, "StringEquals": { "aws:CalledViaFirst": "cloudformation.amazonaws.com" } } }, { "Effect": "Allow", "Action": [ "ssm:StartSession" ], "Resource": [ "arn:aws:ssm:*:*:document/*" ] }
依存関係をダウンロードするため、Amazon S3 の VPC エンドポイントを設定する
AWS Cloud9 環境の EC2 インスタンスがインターネットにアクセスできない場合、指定した Amazon S3 バケットの VPC エンドポイントを作成します。このバケットには、IDE を最新の状態に保つために必要な依存関係が含まれています。
Amazon S3 の VPC エンドポイントを設定するには、アクセスポリシーをカスタマイズする必要があります。アクセスポリシーは、ダウンロードする依存関係を含む信頼された S3 バケットのみへのアクセスを許可するようにします。
注記
AWS Management Console、AWS CLI、または Amazon VPC API を使用して、VPC エンドポイントを作成および設定できます。次の手順では、コンソールインターフェイスを使用して VPC エンドポイントを作成する方法について説明します。
Amazon S3 の VPC エンドポイントを作成および設定する
-
AWS Management Console ではい、Amazon VPC のコンソールページに移動します。
-
ナビゲーションバーで、［エンドポイント］ を選択します。
-
エンドポイントページで、［エンドポイント作成］を選択します。
-
エンドポイントの作成ページで、検索フィールドに「s3」と入力し、戻るを押して、現在の AWS リージョン で、Amazon S3 で利用可能なエンドポイントをリストします。
-
返却された Amazon S3 エンドポイントのリストから、ゲートウェイタイプを選択できます。
-
次に、環境の EC2 インスタンスが含まれている VPC を選択します。
-
次に、VPC のルートテーブルを選択します。こうすることで、関連付けられたサブネットはエンドポイントにアクセスできるようになります。環境の EC2 インスタンスは、これらのサブネットの 1 つにあります。
-
ポリシーセクションで、カスタムオプションを選択し、スタンダードポリシーを以下に置き換えます。
{ "Version": "2008-10-17", "Statement": [ { "Sid": "Access-to-C9-bucket-only", "Effect": "Allow", "Principal": "*", "Action": "s3:GetObject", "Resource": "arn:aws:s3:::{bucket_name}/content/dependencies/*" } ] }Resource要素に対して、AWS リージョン で{bucket_name}を利用可能なバケットの実際の名前に置き換えます。例えば、AWS Cloud9欧州 (アイルランド) リージョンで、以下を指定します:"Resource": "arn:aws:s3:::static-eu-west-1-prod-static-hld3vzaf7c4h/content/dependencies/。次の表に AWS Cloud9 が利用可能となる AWS リージョン のバケット名を示します。
AWS Cloud9リージョンの Amazon S3 バケットAWS リージョン バケット名 米国東部 (オハイオ)
static-us-east-2-prod-static-1c3sfcvf9hy4m米国東部 (バージニア北部)
static-us-east-1-prod-static-mft1klnkc4hl米国西部 (オレゴン)
static-us-west-2-prod-static-p21mksqx9zlr米国西部 (北カリフォルニア)
static-us-west-1-prod-static-16d59zrrp01z0アフリカ (ケープタウン)
static-af-south-1-prod-static-v6v7i5ypdppvアジアパシフィック (香港)
static-ap-east-1-prod-static-171xhpfkrorh6アジアパシフィック (ムンバイ) static-ap-south-1-prod-static-ykocre202i9dアジアパシフィック (大阪) static-ap-northeast-3-prod-static-ivmxqzrx2ioiアジアパシフィック (ソウル) static-ap-northeast-2-prod-static-1wxyctlhwiajmアジアパシフィック (シンガポール) static-ap-southeast-1-prod-static-13ibpyrx4vk6dアジアパシフィック (シドニー)
static-ap-southeast-2-prod-static-1cjsl8bx27rfuアジアパシフィック (東京)
static-ap-northeast-1-prod-static-4fwvbdisquj8カナダ (中部)
static-ca-central-1-prod-static-g80lpejy486c欧州 (フランクフルト)
static-eu-central-1-prod-static-14lbgls2vrkhヨーロッパ (アイルランド)
static-eu-west-1-prod-static-hld3vzaf7c4hヨーロッパ (ロンドン)
static-eu-west-2-prod-static-36lbg202837xヨーロッパ (ミラノ)
static-eu-south-1-prod-static-1379tzkd3ni7dヨーロッパ (パリ)
static-eu-west-3-prod-static-1rwpkf766ke58ヨーロッパ (ストックホルム)
static-eu-north-1-prod-static-1qzw982y7yu7e中東 (バーレーン)
static-me-south-1-prod-static-gmljex38qtqx南米 (サンパウロ)
static-sa-east-1-prod-static-1cl8k0y7opidtイスラエル (テルアビブ)
static-il-central-1-prod-static-k02vrnhcesue -
[エンドポイントの作成] を選択します。
正しい設定情報を指定した場合は、作成されたエンドポイントの ID がメッセージに表示されます。
-
IDE が Amazon S3 バケットにアクセスできることをチェックするには、メニューバー上の［Window］、［New Terminal (新しいターミナル)］ を選択してターミナルセッションをスタートします。次に、以下のコマンドを実行し、
{bucket_name}をリージョンのバケットの実際の名前に置き換えます。ping {bucket_name}.s3.{region}.amazonaws.com.例えば、米国東部 (バージニア北部) リージョンで S3 バケットのエンドポイントを作成した場合は、次のコマンドを実行します。
ping static-us-east-1-prod-static-mft1klnkc4hl.s3.us-east-1.amazonaws.comping が応答を受け取ると、IDE がバケットとその依存関係にアクセスできることを確認します。
この特徴の詳細については、「AWS PrivateLink ガイド」にあるAmazon S3 用エンドポイントを参照してください。
プライベート接続用 VPC エンドポイントの設定
Systems Manager を使用するアクセスのオプションを使用して、インスタンスをサブネットに起動する時には、セキュリティグループには受信ネットワークトラフィックを許可するインバウンドルールがありません。ただし、セキュリティグループには、インスタンスからのアウトバウンドトラフィックを許可するアウトバウンドルールがあります。AWS Cloud9 IDE を最新状態で保つには、パッケージとライブラリをダウンロードするためにこうする必要があります。
インスタンスのアウトバウンドトラフィックとインバウンドトラフィックを防ぐには、Systems Manager 用の Amazon VPC エンドポイントを作成して設定します。インターフェイス VPC エンドポイント (インターフェイスエンドポイント) を使用して、AWS PrivateLink によって提供されるサービスに接続できます。AWS PrivateLink は、プライベート IP アドレスを使用して Amazon EC) および Systems Manager API にプライベートアクセスできるようにするテクノロジーです。VPC エンドポイントを設定して Systems Manager を使用するには、このナレッジセンターのリソース
警告
インバウンドまたはアウトバウンドのネットワークトラフィックを許可しないセキュリティグループを設定するとします。その場合、AWS Cloud9 IDE をサポートする EC2 インスタンスは、インターネットにアクセスできません。したがって、VPC の Amazon S3 エンドポイントを作成して、信頼できる S3 バケットに含まれる依存関係へのアクセスを許可する必要があります。さらに、AWS Lambda などの一部の AWS のサービス は、インターネットアクセスなしでは意図したとおりに動作しないかもしれません。
AWS PrivateLink では、VPC エンドポイントを通して処理される各ギガバイトごとにデータ処理料金が発生します。これは、トラフィックの送信元または送信先に関係なく行われます。詳細については、AWS PrivateLink 料金
