Enterprise Distributed Application Service (EDAS) では、リソース管理によって提供されるリソースグループを使用して、リソース権限を管理できます。EDAS のリソースグループを作成した後、クラスターとアプリケーションを異なるリソースグループに追加できます。その後、これらのリソースグループに必要な権限を RAM ユーザーに付与できます。これにより、リソース権限の管理が簡素化されます。
前提条件
EDAS は、プライマリアカウントとサブアカウントの管理システムを使用して開発されています。リソースグループを使用して権限を管理するには、EDAS プライマリアカウントとサブアカウントの管理システムではなく、Resource Access Management (RAM) を使用する必要があります。詳細については、「EDAS定義の権限を RAM ポリシーに置き換える」をご参照ください。
リソース管理サービスは、Alibaba Cloud アカウントと RAM ユーザーに対して自動的にアクティブ化されます。
背景情報
リソース管理は、企業の IT ガバナンスを促進するための幅広いサービスを提供します。リソース管理を使用すると、ビジネス要件に基づいてリソース階層を構築できます。異なるユーザーのリソースグループを作成し、クラスターとアプリケーションに必要な権限をユーザーに付与できます。
リソースグループを使用すると、Alibaba Cloud アカウントが所有するリソースをグループに分類できます。これにより、Alibaba Cloud アカウント内のリソースと権限の管理が簡素化されます。
さまざまなリージョンの Alibaba Cloud アカウントのリソースを管理するためのリソースグループを作成します。
各リソースグループの管理者を指定します。各管理者は、自分が担当するリソースグループ内のリソースを管理します。
EDAS プライマリアカウントとサブアカウントの管理システムと RAM の関係
EDAS は、互いに独立した以下の権限管理システムをサポートしています。
各 Alibaba Cloud アカウントは、以下の権限管理システムのいずれか 1 つのみを使用できます。RAM を使用することをお勧めします。
EDAS が RAM と統合される前は、EDAS はプライマリアカウントとサブアカウントの管理システムを使用して、サブアカウントの権限を管理していました。
EDAS が RAM と統合された後、EDAS はリソースグループを使用して RAM ユーザーの権限を管理します。
リソースグループの利点
次の例は、権限管理におけるリソースグループの利点を示しています。

会社 A には、deptA と deptB の 2 つの部門があります。 deptA は subA という名前の RAM ユーザーを使用して、clusterA という名前のクラスターと appA1 および appA2 という名前のアプリケーションを管理します。 deptB は subB という名前の RAM ユーザーを使用して、clusterB という名前のクラスターと appB1 および appB2 という名前のアプリケーションを管理します。
RAM を使用すると、ポリシーまたはリソースグループを使用して権限を管理できます。
表 1. 次の表は、RAM ポリシーとリソースグループの違いについて説明しています。
項目 | RAM ポリシー | リソースグループ |
シナリオ | 指定したリソースに対する制限付き権限をユーザーに付与できます。 | 1 つ以上のリソースを含む可能性のある、指定したリソースグループに対する制限付き権限をユーザーに付与できます。 |
仕組み | RAM コンソールで、Alibaba Cloud アカウントを使用して、deptA 用の RAM ユーザー subA と deptB 用の RAM ユーザー subB を作成する必要があります。次に、subA 用の policyA という名前のポリシーと subB 用の policyB という名前のポリシーを作成します。ポリシーでは、RAM ユーザーが管理できるクラスターとアプリケーション、およびクラスターとアプリケーションに対する権限を指定します。 | Alibaba Cloud アカウントを使用して、deptA 用の groupA という名前のリソースグループと deptB 用の groupB という名前のリソースグループを作成する必要があります。次に、deptA に属するクラスターとアプリケーションを groupA に、deptB に属するクラスターとアプリケーションを groupB に追加します。 RAM コンソールで、deptA 用の RAM ユーザー subA と deptB 用の RAM ユーザー subB を作成します。次に、groupA と groupB の subA と subB の両方にアタッチされるカスタムポリシーを作成します。このカスタムポリシーは、groupA と groupB のリソースに対する個別の権限を subA と subB に付与します。 |
特性 | この方法には、次の欠点があります。
| この方法には、次の利点があります。
|
前述の方法は、さまざまなシナリオに適用できます。ビジネス要件に基づいて方法を選択してください。
制限事項
リソースグループは権限管理を容易にします。ただし、次の制限事項に注意する必要があります。
マイクロサービス名前空間はリソースグループに追加できません。アプリケーションとクラスターのみをリソースグループに追加できます。マイクロサービス名前空間の権限を管理するには、RAM のみを使用できます。
Application Configuration Management (ACM) と Application Real-Time Monitoring Service (ARMS) リソースは、リソースグループに追加できません。
手順
前の例を使用して、リソースグループを使用して権限を管理する方法を示します。
リソース管理コンソールにログオンし、groupA と groupB の 2 つのリソースグループを作成します。詳細については、「リソースグループの作成」をご参照ください。
クラスターとアプリケーションを groupA と groupB に追加します。詳細については、「リソースをリソースグループに転送する」をご参照ください。
RAM コンソールにログオンし、deptA 用の RAM ユーザー subA と deptB 用の RAM ユーザー subB を作成します。詳細については、「RAM ユーザーの作成」をご参照ください。
RAM コンソールで、groupA と groupB の subA と subB の両方にアタッチされるカスタムポリシーを作成します。詳細については、「カスタムポリシーの作成」をご参照ください。
次のコードは、ポリシーの内容を示しています。
{ "Version": "1", "Statement": [ { "Effect": "Allow", "Action": [ "edas:*Cluster", // クラスターに対するすべてのアクションを許可します "edas:*Application" // アプリケーションに対するすべてのアクションを許可します ], "Resource": [ "acs:edas:*:*:*" ] } ] }リソース管理コンソールで、カスタムポリシーを subA と subB にアタッチします。詳細については、「RAM 認証の追加」をご参照ください。
オプション:groupA と groupB からリソースを削除するか、groupA と groupB にリソースを追加することで、リソースに対する権限を管理します。
オプション:カスタムポリシーを作成して、groupA に属さないリソースに対する権限を subA に付与します。この例では、マイクロサービス名前空間内のマイクロサービスを照会する権限が subA に付与されます。詳細については、「RAM ユーザーに権限を付与する」をご参照ください。
説明subA がマイクロサービス名前空間を指定してマイクロサービスを照会すると、groupA に対する AliyunEDASFullAccess 権限が subA に付与されている場合でも、権限が不十分なためエラーが返されます。これは、マイクロサービス名前空間をリソースグループに追加できず、マイクロサービス名前空間に対する権限を subA に付与する必要があるためです。
次のコードは、ポリシーの内容を示しています。
{ "Version": "1", "Statement": [ { "Action": ["edas:ReadService"], // マイクロサービスの読み取りを許可します "Resource": ["acs:edas:$regionid:*:namespace/$namespace"], "Effect": "Allow" } ] }[クラスター管理]、[アプリケーション管理]、および[アプリケーションベースのマイクロサービス管理]に加えて、「ポリシーの詳細」で説明されている権限も subA に付与する必要があります。
結果の確認
上記の手順を実行した後、RAM ユーザーに指定された権限が付与されているかどうかを確認します。