Terraform ID 認証 - Terraform - Alibaba Cloud ドキュメントセンター

このトピックでは、Alibaba Cloud Terraform Provider の身元認証方式について説明します。

概要

Terraform を使用して Alibaba Cloud インフラストラクチャリソースを管理する前に、Alibaba Cloud Terraform Provider の身元認証を通過する必要があります。身元認証を通過すると、Terraform を使用して Alibaba Cloud API オペレーションを呼び出し、Alibaba Cloud インフラストラクチャリソースを作成および管理できます。

Alibaba Cloud Terraform Provider は、複数の身元認証方式をサポートしています。Terraform がインストールおよび実行される環境、およびシナリオに基づいて方式を選択できます。次の表に、Alibaba Cloud Terraform Provider の身元認証方式を示します。

認証方式	説明	シナリオ
静的クレデンシャル	構成ファイルに AccessKey ペアなどのアクセス認証情報をプレーンテキストで定義するか、変数を使用してアクセス認証情報を指定します。	開発環境のテストと検証継続的インテグレーションおよび継続的デリバリー ( CI/CD ) リソース管理
環境変数	AccessKey ペアなどのアクセス認証情報を環境変数に保存します。静的クレデンシャルが定義されていない場合、Terraform は環境変数からアクセス認証情報を読み取ります。	開発環境のテストと検証 Elastic Compute Service ( ECS ) インスタンスなどの独立したランタイム環境
ECS インスタンスの Resource Access Management ( RAM ) ロール	ECS インスタンスのメタデータから、ECS インスタンスにアタッチされている RAM ロールのアクセス認証情報を取得します。	Terraform が ECS インスタンスで実行されるシナリオ
RAM ロール	RAM ロールを引き受けることでアクセス認証情報を取得します。	複数アカウントのリソース管理 CI/CD リソース管理
OpenID Connect ( OIDC ) ID プロバイダー ( IdP ) の RAM ロール	OIDC IdP の RAM ロールを引き受けることでアクセス認証情報を取得します。	Terraform が Container Service for Kubernetes ( ACK ) クラスタで実行されるシナリオ
共有プロファイル	Alibaba Cloud CLI を使用して、上記の身元認証方式を統合ファイルで構成し、使用するプロファイルの名前に基づいてアクセス認証情報を取得します。	複数アカウントおよび複数リージョンのリソース管理開発環境のテストと検証複数環境のリソース管理

認証方式

以下のセクションでは、Alibaba Cloud Terraform Provider の身元認証方式について説明します。

静的クレデンシャル

Terraform 構成ファイルのプロバイダーコードブロックにアクセス認証情報を定義できます。サンプルコード:

provider "alicloud" {
  access_key = "<Your AccessKey ID>"
  secret_key = "<Your AccessKey secret>"
  # セキュリティトークンサービス ( STS ) トークンを使用する場合は、security_token パラメーターを指定します。
  # security_token = "<Your STS token>"
}

セキュリティ上の理由から、変数を使用してアクセス認証情報を指定し、変数のデフォルト値を指定しないことをお勧めします。構成ファイルにプレーンテキストでアクセス認証情報を定義することはお勧めしません。

variable "access_key_id" {
  description = "インフラストラクチャを操作するための AccessKey ID"
}
variable "access_key_secret" {
  description = "インフラストラクチャを操作するための AccessKey Secret"
}
variable "security_token" {
  description = "インフラストラクチャを操作するためのセキュリティトークン"
}
provider "alicloud" {
  access_key = var.access_key_id
  secret_key = var.access_key_secret
  // STS トークンを使用する場合は、security_token パラメーターを指定します。
  // security_token = var.security_token
}

Terraform コマンドを実行するときは、-var オプションを使用して変数の値を指定できます。

$ terraform plan -var access_key_id="<Your AccessKey ID>" -var access_key_secret="<Your AccessKey Secret>" -var security_token="<Your STS token>"

環境変数

アクセス認証情報を特定の環境変数に保存できます。Terraform コマンドを実行するときに、構成ファイルにアクセス認証情報が宣言されていない場合、Terraform は環境変数からアクセス認証情報を取得できます。環境変数を構成するためのサンプルコード:

Linux

重要

export コマンドを使用して構成された一時環境変数は、現在のセッションでのみ有効です。セッションが終了すると、構成された環境変数は失われます。環境変数を永続的に保持するには、オペレーティングシステムの起動構成ファイルに export コマンドを追加します。

# AccessKey ID
$ export ALICLOUD_ACCESS_KEY="<Your AccessKey ID>"
# AccessKey Secret
$ export ALICLOUD_SECRET_KEY="<Your AccessKey secret>"
# STS 認証情報を使用する場合は、security_token を構成する必要があります。
$ export ALICLOUD_SECURITY_TOKEN="<Your access token>"

Windows

Windows デスクトップで、[PC] を右クリックし、[プロパティ(>)] > [システムの詳細設定(>)] > [環境変数(>)] > [システム環境変数またはユーザー環境変数] を選択します。

[システム環境変数] または [ユーザー環境変数] セクションで、[作成] をクリックして、次の変数を作成します。

変数	説明	値
ALICLOUD_ACCESS_KEY	AccessKey ID	例: yourAccessKeyID
ALICLOUD_SECRET_KEY	AccessKey シークレット	例: yourAccessKeySecret
ALICLOUD_SECURITY_TOKEN (オプション)	STS クレデンシャルを使用する場合は、セキュリティトークンを構成する必要があります。	例: yourSTSToken

環境変数を構成した後、アクセス認証情報を宣言する必要はありません。または、構成ファイルのプロバイダーコードブロックにリージョン ID のみ宣言できます。

provider "alicloud" {
  region = "cn-hangzhou"
}

ALICLOUD_REGION 環境変数を使用してリージョン ID を指定することもできます。リージョン ID が宣言されておらず、 ALICLOUD_REGION 環境変数が構成されていない場合、 cn-beijing が region パラメーターのデフォルト値として使用されます。

静的クレデンシャルと比較して、環境変数は使いやすく、より安全です。

ECS インスタンスの RAM ロール

Terraform が Alibaba Cloud リソースを管理するために ECS インスタンスで実行されている場合、ECS インスタンスに RAM ロールをアタッチして、ECS インスタンスで RAM ロールの STS トークンを自動的に取得および更新できます。この場合、AccessKey ペアを公開する必要がないため、AccessKey ペアの漏洩のリスクが軽減されます。また、RAM ロールのきめ細かいアクセス制御を使用して、過剰な権限が付与されるのを防ぐこともできます。詳細については、「インスタンス RAM ロール」をご参照ください。

身元認証のために ECS インスタンスの RAM ロールを構成するには、次の手順を実行します。

インターネットにアクセスできる ECS インスタンスを準備します。
RAM ロールを作成し、ECS インスタンスにアタッチします。
プロバイダーコードブロックで ecs_role_name パラメーターを定義し、このパラメーターの値として RAM ロールの名前を指定します。

provider "alicloud" {
  ecs_role_name = "<ECS インスタンスにアタッチされている RAM ロールの名前>"
}

ALICLOUD_ECS_ROLE_NAME 環境変数を使用して RAM ロールの名前を指定することもできます。

ECS インスタンスの RAM ロールはより安全です。Terraform が ECS インスタンスで実行されている場合は、この認証方式を使用することをお勧めします。

RAM ロール

ほとんどの場合、RAM ユーザーまたは ECS などのクラウドサービスによって引き受けられた RAM ロールが Alibaba Cloud リソースにアクセスして管理します。この場合、RAM ユーザーの AccessKey ペアまたはクラウドサービスによって引き受けられた RAM ロールの STS トークンがアクセス認証情報として使用されます。それらのアクセス権限は、RAM ユーザーまたはクラウドサービスによって引き受けられた RAM ロールにアタッチされているポリシーによって決定されます。Terraform に必要なアクセス権限を RAM ユーザーまたはクラウドサービスによって引き受けられた RAM ロールのアクセス権限から分離したり、アカウント間でクラウドリソースにアクセスしたりする場合は、RAM ユーザーまたはクラウドサービスによって引き受けられた RAM ロールに RAM ロールを割り当てることができます。その後、RAM ロールは STS トークンを取得して Alibaba Cloud リソースにアクセスします。

RAM ロールベースの認証方式は、AssumeRole オペレーションに基づいて実装されます。Terraform で身元認証のために RAM ロールを構成する前に、次の準備を行います。

RAM ユーザーを作成し、AliyunSTSAssumeRoleAccess システムポリシーを RAM ユーザーにアタッチします。この場合、RAM ユーザーには AssumeRole オペレーションを呼び出す権限が付与されます。
RAM ユーザーの AccessKey ペアを作成します。AccessKey ペアを使用して、Terraform で AssumeRole オペレーションを呼び出し、STS トークンを取得できます。
信頼できるエンティティが Alibaba Cloud アカウントである RAM ロールを作成し、アクセスするクラウドサービスの RAM ポリシー ( Object Storage Service ( OSS ) にアクセスするために使用される AliyunOSSFullAccess ポリシーなど) を RAM ロールにアタッチし、RAM ロールの Alibaba Cloud Resource Name ( ARN ) を記録します。
ビジネス要件に基づいてクラウドリソースにアクセスするために使用されるカスタム RAM ポリシーを作成します。たとえば、中国 (杭州) リージョンにあるすべてのバケットにのみアクセスするカスタムポリシーを作成できます。このカスタムポリシーは、前の手順でアタッチされたクラウドサービスの RAM ポリシーとともに RAM ロールに権限を付与するために使用されます。これにより、きめ細かいアクセス制御が実装されます。

上記の手順を実行した後、次のプロバイダーコードブロックで身元認証のために RAM ロールを宣言します。

provider "alicloud" {
  # AssumeRole オペレーションを呼び出す権限が付与されている RAM ユーザーの AccessKey ID 。
  access_key = "<RAM ユーザーの AccessKey ID>"
  # AssumeRole オペレーションを呼び出す権限が付与されている RAM ユーザーの AccessKey シークレット。
  secret_key = "<RAM ユーザーの AccessKey シークレット>"
  assume_role {
    role_arn           = "<RAM ロールの ARN>"
    policy             = "<RAM ポリシー>"
    session_name       = "<RAM ロールのカスタムセッション名>"
    session_expiration = <STS トークンの有効期間>
  }
}

Terraform で身元認証のために RAM ロールを構成する場合、次のパラメーターがサポートされます。

access_key および secret_key
RAM ユーザーが RAM ロールを引き受ける場合、access_key パラメーターと secret_key パラメーターが必要です。RAM ユーザーには、AssumeRole オペレーションを呼び出す権限が付与されている必要があります。そうでない場合、RAM ユーザーは AssumeRole オペレーションを呼び出して STS トークンを取得できません。環境変数を使用して AccessKey ペアを指定することもできます。
assume_role
assume_role パラメーターは、STS トークンを取得するために使用されます。このコードブロックには、次のパラメーターが含まれています。
1. role_arn: 必須。 RAM ロールの ARN 。このパラメーターの値は、acs:ram::<Alibaba Cloud アカウントの ID>:role/<RAM ロールの名前> の形式です。例: acs:ram::151192xxxxxx:role/k8srole 。
2. policy: オプション。RAM ロールにアタッチされているカスタムポリシー。このパラメーターを指定すると、RAM ロールの権限は、このカスタムポリシーと、準備を行う際に RAM ロールにアタッチされているクラウドサービスの RAM ポリシーによって付与されます。このパラメーターを指定しない場合、RAM ロールの権限は、準備を行う際に RAM ロールにアタッチされているクラウドサービスの RAM ポリシーによって付与されます。
3. session_name: オプション。RAM ロールのセッション名。このパラメーターの値はユーザー定義であり、通常は API オペレーションを呼び出すユーザーの ID (ユーザー名など) に設定されます。このパラメーターを指定しない場合、Alibaba Cloud Terraform Provider はこのパラメーターのデフォルト値を terraform に設定します。
4. session_expiration: オプション。 STS トークンの有効期間。単位: 秒。このパラメーターの最小値は 900 で、最大値は RAM ロールのMaxSessionDuration パラメーターの値です。MaxSessionDuration パラメーターのデフォルト値は 3600 で、最大値は 43200 です。UpdateRole 操作を呼び出して MaxSessionDuration パラメーターを指定できます。
5. external_Id: オプション。RAM ロールの外部 ID 。このパラメーターの値は外部関係者によって提供され、なりすまし副官問題を防ぐために使用されます。詳細については、「外部 ID を使用してなりすまし副官問題を防ぐ」をご参照ください。

次のサンプルコードは、身元認証のために RAM ロールを構成し、中国 (杭州) リージョンにある OSS バケットのリストを照会する権限を付与する方法を示しています。

provider "alicloud" {
  # セキュリティ上の理由から、AccessKey ID と AccessKey シークレットは環境変数を使用して指定されます。
  region = "cn-hangzhou"
  assume_role {
    role_arn           = "acs:ram::11827xxxxxx:role/tf-assume-role"
    policy             = <<EOF
    {
      "Version": "1",
      "Statement": [
        {
          "Effect": "Allow",
          "Action": "oss:ListBuckets",
          "Resource": "acs:oss:oss-cn-hangzhou:*:*"
        }
      ]
    }
    EOF
    session_name       = "terraform-assume-role-session"
    session_expiration = 1000
  }
}

上記のサンプルコードを実行する前に、tf-assume-role RAM ロールに AliyunOSSFullAccess ポリシーをアタッチする必要があることに注意してください。そうでない場合、Terraform を使用して中国 (杭州) リージョンにある OSS バケットのリストを照会すると、必要な権限がないことを示すエラーメッセージが返されます。

policy パラメーターを使用してきめ細かいアクセス制御を実装したくない場合は、準備を行う際に上記のポリシーを tf-assume-role RAM ロールに直接アタッチできます。この場合、assume_role パラメーターのコードブロックで role_arn パラメーターのみを指定する必要があります。

Terraform が ECS インスタンスで実行されている場合は、ECS インスタンスに RAM ロールをアタッチして、AccessKey ペアの漏洩を防ぐこともできます。サンプルコード:

provider "alicloud" {
  ecs_role_name = "<ECS インスタンスにアタッチされている RAM ロールの名前>"
  region        = "cn-hangzhou"
  assume_role {
    role_arn           = "acs:ram::11827xxxxxx:role/tf-assume-role"
    policy             = <<EOF
    {
      "Version": "1",
      "Statement": [
        {
          "Effect": "Allow",
          "Action": "oss:ListBuckets",
          "Resource": "acs:oss:oss-cn-hangzhou:*:*"
        }
      ]
    }
    EOF
    session_name       = "terraform-assume-role-session"
    session_expiration = 1000
  }
}

この場合、ECS インスタンスにアタッチされている RAM ロールに AliyunSTSAssumeRoleAccess システムポリシーをアタッチして、RAM ロールに AssumeRole オペレーションを呼び出す権限を付与するだけで済みます。

OIDC IdP の RAM ロール

OIDC IdP の ID に RAM ロールを割り当てることができます。その後、RAM ロールは STS トークンを取得して Alibaba Cloud リソースにアクセスします。この認証方式は、RAM ロールベースの認証方式に似ています。唯一の違いは、OIDC IdP によって発行された ID が必要であることです。詳細については、「OIDC IdP を管理する」をご参照ください。

OIDC IdP の RAM ロールを使用した認証方式は、AssumeRoleWithOIDC オペレーションに基づいて実装されます。Terraform で身元認証のために OIDC IdP の RAM ロールを構成する前に、次の準備を行います。

OIDC IdP を作成し、外部 IdP によって発行された OIDC トークンを申請し、OIDC IdP の ARN と OIDC トークンを記録します。
信頼できるエンティティが IdP である RAM ロールを作成し、アクセスするクラウドサービスの RAM ポリシー ( OSS にアクセスするために使用される AliyunOSSFullAccess ポリシーなど) を RAM ロールにアタッチし、RAM ロールの ARN を記録します。
ビジネス要件に基づいてクラウドリソースにアクセスするために使用されるカスタム RAM ポリシーを作成します。たとえば、中国 (杭州) リージョンにあるすべてのバケットにのみアクセスするカスタムポリシーを作成できます。このカスタムポリシーは、前の手順でアタッチされたクラウドサービスの RAM ポリシーとともに RAM ロールに権限を付与するために使用されます。これにより、きめ細かいアクセス制御が実装されます。

上記の手順を実行した後、次のプロバイダーコードブロックで身元認証のために RAM ロールを宣言します。

provider "alicloud" {
  assume_role_with_oidc {
    oidc_provider_arn  = "<OIDC IdP の ARN>"
    oidc_token         = "<外部 IdP によって発行された OIDC トークン>"
    role_arn           = "<RAM ロールの ARN>"
    policy             = "<RAM ポリシー>"
    role_session_name  = "<RAM ロールのカスタムセッション名>"
    session_expiration = <STS トークンの有効期間>
  }
}

Terraform で身元認証のために OIDC IdP の RAM ロールを構成する場合、assume_role_with_oidc パラメーターのコードブロックで次のパラメーターがサポートされます。

oidc_provider_arn: 必須。 OIDC IdP の ARN 。このパラメーターの値は、acs:ram::<Alibaba Cloud アカウントの ID>:oidc-provider/<RAM ロールの名前> の形式です。例: acs:ram::151192xxxxxx:oidc-provider/ackrole 。 RAM コンソールで OIDC IdP の ARN を表示したり、API 操作を呼び出して OIDC IdP の ARN を照会したりできます。また、 ALIBABA_CLOUD_OIDC_PROVIDER_ARN 環境変数を使用して OIDC IdP の ARN を指定することもできます。
oidc_token: オプション。外部 IdP によって発行された OIDC トークン。このパラメーターの値は、4 ～ 20,000 文字の長さでなければなりません。 oidc_token パラメーターと oidc_token_file パラメーターのいずれかを指定する必要があります。 ALIBABA_CLOUD_OIDC_TOKEN 環境変数でパラメーターを設定できます。
oidc_token_file: オプション。外部 IdP によって発行された OIDC トークンファイルの絶対パス。oidc_token パラメーターと oidc_token_file パラメーターのいずれかを指定する必要があります。また、ALIBABA_CLOUD_OIDC_TOKEN_FILE 環境変数を使用して OIDC トークンファイルの絶対パスを指定することもできます。
role_arn: 必須。 RAM ロールの ARN 。このパラメーターの値は、acs:ram::<Alibaba Cloud アカウントの ID>:role/<RAM ロールの名前> の形式です。例: acs:ram::151192xxxxxx:role/k8srole 。また、 ALIBABA_CLOUD_ROLE_ARN 環境変数を使用して RAM ロールの ARN を指定することもできます。
policy: オプション。RAM ロールにアタッチされているカスタムポリシー。このパラメーターを指定すると、RAM ロールの権限は、このカスタムポリシーと、準備を行う際に RAM ロールにアタッチされているクラウドサービスの RAM ポリシーによって付与されます。このパラメーターを指定しない場合、RAM ロールの権限は、準備を行う際に RAM ロールにアタッチされているクラウドサービスの RAM ポリシーによって付与されます。
role_session_name: オプション。RAM ロールのセッション名。このパラメーターの値はユーザー定義であり、通常は API オペレーションを呼び出すユーザーの ID (ユーザー名など) に設定されます。このパラメーターを指定しない場合、Alibaba Cloud Terraform Provider はこのパラメーターのデフォルト値を terraform に設定します。また、ALIBABA_CLOUD_ROLE_SESSION_NAME 環境変数を使用して RAM ロールのセッション名を指定することもできます。
session_expiration: オプション。 STS トークンの有効期間。単位: 秒。このパラメーターの最小値は 900 で、最大値は RAM ロールのMaxSessionDuration パラメーターの値です。MaxSessionDuration パラメーターのデフォルト値は 3600 で、最大値は 43200 です。UpdateRole 操作を呼び出して MaxSessionDuration パラメーターを指定できます。

Alibaba Cloud ACK では、サービスアカウントの RAM ロール ( RRSA ) 機能を有効にして、OIDC IdP を作成し、OIDC トークンを発行できます。詳細については、「RRSA を使用して異なるポッドに異なるクラウドサービスへのアクセスを承認する」をご参照ください。RRSA 機能が有効になっている場合、ack-pod-identity-webhook コンポーネントは、ALIBABA_CLOUD_OIDC_PROVIDER_ARN 、ALIBABA_CLOUD_OIDC_TOKEN_FILE 、および ALIBABA_CLOUD_ROLE_ARN 環境変数の構成をポッドに自動的に挿入します。この場合、ACK クラスタで Terraform コマンドを実行する場合、次の簡略化されたサンプルコードを使用して、身元認証のために OIDC IdP の RAM ロールを構成し、中国 (杭州) リージョンにある OSS バケットのリストを照会する権限を付与できます。

provider "alicloud" {
  region = "cn-hangzhou"
  assume_role_with_oidc {
    policy             = <<EOF
    {
      "Version": "1",
      "Statement": [
        {
          "Effect": "Allow",
          "Action": "oss:ListBuckets",
          "Resource": "acs:oss:oss-cn-hangzhou:*:*"
        }
      ]
    }
    EOF
    session_name       = "terraform-assume-role-session"
    session_expiration = 1000
  }
}

RAM ロールベースの認証方式と同様に、policy パラメーターを使用してきめ細かいアクセス制御を実装したくない場合は、準備を行う際に上記のポリシーを RAM ロールに直接アタッチできます。この場合、上記のサンプルコードをさらに簡略化できます。

provider "alicloud" {
  region = "cn-hangzhou"
  assume_role_with_oidc {
    policy             = <<EOF
    {
      "Version": "1",
      "Statement": [
        {
          "Effect": "Allow",
          "Action": "oss:ListBuckets",
          "Resource": "acs:oss:oss-cn-hangzhou:*:*"
        }
      ]
    }
    EOF
    session_name       = "terraform-assume-role-session" // terraform のセッション名
    session_expiration = 1000 // セッションの有効期限
  }
}

共有プロファイル

プロファイル機能は Alibaba Cloud CLI によって提供され、Alibaba Cloud リソースにアクセスするために必要な複数のクレデンシャルを統一的に構成します。静的クレデンシャル、ECS インスタンスの RAM ロール、RAM ロールのいずれかの身元認証方式を使用して、プロファイルにアクセス認証情報を構成できます。詳細については、「クレデンシャルを構成する」をご参照ください。

Alibaba Cloud CLI を使用してプロファイルに複数のアクセス認証情報を構成した後、Terraform で身元認証のために共有プロファイルを構成できます。

provider "alicloud" {
  region                  = "cn-hangzhou"
  shared_credentials_file = "<共有プロファイルの絶対パス>"
  profile                 = "<使用するプロファイルの名前>"
}

Terraform で身元認証のために共有プロファイルを構成する場合、次のパラメーターがサポートされます。

profile: 必須。身元認証に使用するプロファイルの名前。
shared_credentials_file: オプション。共有プロファイルの保存場所。Alibaba Cloud CLI を使用してプロファイルを構成するときに、--config-path オプションを使用して共有プロファイルの保存場所を指定できます。

共有プロファイルを構成した後、複数の環境またはアカウントにわたる複数のアクセス認証情報を切り替えることができます。たとえば、開発環境とテスト環境で中国 (北京) リージョンと中国 (杭州) リージョンに Alibaba Cloud リソースを作成する場合、次のサンプルコードを使用して、共有プロファイルの複数のプロバイダーコードブロックで身元認証を構成できます。

provider "alicloud" {
  alias   = beijing
  region  = "cn-beijing"
  profile = "bj-test"
}

provider "alicloud" {
  alias   = hangzhou
  region  = "cn-hangzhou"
  profile = "hz-test"
}

まとめ

このセクションでは、上記の身元認証方式をまとめています。

優先順位
ほとんどの場合、身元認証方式は 1 つだけ構成します。一度に複数の身元認証方式を構成する場合、Terraform は優先順位に基づいて身元認証方式を選択します。優先順位の高い順に、静的クレデンシャル、環境変数、プロファイル内の静的クレデンシャル、ECS インスタンスの RAM ロール、プロファイル内の ECS インスタンスの RAM ロール、OIDC IdP の RAM ロール、RAM ロールが挙げられます。
セキュリティ
異なる身元認証方式は、異なるシナリオに適用できます。Terraform を本番環境に適用する場合、セキュリティを考慮する必要があります。次の身元認証方式を使用することをお勧めします: ECS インスタンスの RAM ロール、RAM ロール、OIDC IdP の RAM ロール。上記の方法のいずれかを使用する場合、STS トークンが必要です。この場合、AccessKey ペアを直接公開する必要がないため、AccessKey ペアの漏洩のリスクが軽減されます。また、STS トークンの有効期間を指定することで、公開範囲を効果的に制御できます。
きめ細かい承認
企業の本番環境では、アプリケーション、チーム、プロジェクトなどのディメンションに基づいてリソース管理権限が厳密に制御されます。この場合、きめ細かいアクセス制御が重要になります。きめ細かいアクセス制御を実装するには、次の身元認証方式を使用することをお勧めします: RAM ロール、OIDC IdP の RAM ロール。異なるプロジェクトまたはアプリケーションのインフラストラクチャコードに基づいて異なるポリシーを構成できます。