Enterprise Distributed Application Service:リソースグループを使用した権限管理

サポートされるリソース

すべての EDAS リソースタイプをリソースグループに追加できるわけではありません。権限の構造を計画する前に、この表をご確認ください。

リソースグループをサポートしていないリソースタイプについては、直接 RAM ポリシーを通じて権限を付与します。例については、「サポートされていないリソースタイプへの権限付与」をご参照ください。

基本概念

リソースグループベースの権限は、以下の 3 つの構成要素を組み合わせたものです。

リソースグループを作成し、EDAS リソースを割り当て、各チームの RAM ユーザーを作成し、各ユーザーの権限をそのリソースグループに限定するカスタムポリシーをアタッチします。

リソースグループと RAM ポリシーの比較

RAM は、権限管理に対して 2 つのアプローチをサポートしています。以下の表で、これらを比較します。

前提条件

開始する前に、以下の条件を満たしていることを確認してください。

• RAM ベースの権限管理に切り替えていること。EDAS には、レガシーなプライマリアカウントとサブアカウントの管理システムがあります。各 Alibaba Cloud アカウントは、1 つの権限管理システムしか使用できません。リソースグループを使用するには、RAM に切り替える必要があります。詳細については、「EDAS で定義された権限を RAM ポリシーに置き換える」をご参照ください。

• Resource Management サービスが有効になっているアクティブな Alibaba Cloud アカウント (すべてのアカウントと RAM ユーザーで自動的に有効化されます)

リソースグループベースの権限設定

以下の例では、完全な設定手順を示します。A 社には 2 つの部署があります。

• deptA は clusterA、appA1、appA2 を管理します。

• deptB は clusterB、appB1、appB2 を管理します。

各部署は、自身の所有するリソースにのみアクセスできるようにする必要があります。

{
    "Version": "1",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "edas:*Cluster",
                "edas:*Application"
            ],
            "Resource": [
                "acs:edas:*:*:*"
            ]
        }
    ]
}

サポートされていないリソースタイプへの権限付与

マイクロサービス名前空間はリソースグループに追加できません。RAM ユーザーが特定の名前空間内のマイクロサービスをクエリする必要がある場合は、別の RAM ポリシーを通じて権限を付与します。

名前空間レベルの読み取りアクセス権を付与するには、以下のポリシーを作成して RAM ユーザーにアタッチします。詳細な手順については、「RAM ユーザーへの権限付与」をご参照ください。

{
    "Version": "1",
    "Statement": [
        {
            "Action": [
                "edas:ReadService"
            ],
            "Resource": [
                "acs:edas:$regionid:*:namespace/$namespace"
            ],
            "Effect": "Allow"
        }
    ]
}

以下のプレースホルダーを実際の値に置き換えてください。

このポリシーは edas:ReadService 操作のみを付与します。クラスター管理、アプリケーション管理、アプリケーションベースのマイクロサービス管理を含む EDAS ポリシー操作の完全なリストについては、「RAM ポリシー」をご参照ください。

結果の確認

設定が完了したら、各 RAM ユーザーが割り当てられたリソースグループ内のリソースにのみアクセスできることを確認します。

1. subA として EDAS コンソールにログインします。

2. subA が clusterA、appA1、appA2 を表示および管理できることを確認します。

3. subA が groupB 内のリソース (clusterB、appB1、appB2) を表示または管理できないことを確認します。

4. subB についても、groupB のリソースで同様の確認を繰り返します。