Identity and Access Management(IAM)Conditions を使用すると、IAM ポリシーを条件付きで定義できます。条件は、リソースの IAM ポリシーのロール バインディングで指定します。条件が存在する場合、条件式が true
と評価されたときのみロールが付与されます。各条件式は一連の論理ステートメントであり、1 つまたは複数の属性を指定できます。詳細については、IAM Conditions の属性のリファレンスをご覧ください。
Cloud Load Balancing と併用することで、IAM Conditions によってロードバランサ管理者やネットワーク管理者などの事前定義済みのロール、またはカスタムのロールを条件付きで付与し、特定の種類のロードバランサのみを作成可能にすることができます。
IAM Conditions では、転送ルールの負荷分散スキームを確認する条件式がサポートされています。たとえば、内部ロードバランサは作成できても外部ロードバランサは作成できないという権限を IAM メンバーに条件付きで付与できます。この IAM メンバーが外部ロードバランサの転送ルールを作成しようとすると、Google Cloud はそのアクションを拒否して、次のようなエラーを返します。
ERROR: (gcloud.compute.forwarding-rules.create) Could not fetch resource:
- Required 'compute.forwardingRules.create' permission for
'projects/project-id/regions/region/forwardingRules/forwarding-rule-name'
Google Cloud ロードバランサでの IAM Conditions の使用
転送ルールの負荷分散スキームにより、転送ルールを使用できるロードバランサの種類が決定します。言い換えれば、負荷分散スキームは、次の表に示すようにロードバランサの種類に対応します。
負荷分散スキーム | 説明 |
---|---|
EXTERNAL | 外部 HTTP(S) 負荷分散 外部 SSL プロキシと TCP プロキシ負荷分散 外部 TCP / UDP ネットワーク負荷分散 |
INTERNAL | 内部 TCP / UDP 負荷分散 |
INTERNAL_MANAGED | 内部 HTTP(S) 負荷分散 |
INTERNAL_SELF_MANAGED | Traffic Director |
ロードバランサを作成するときに、loadBalancingScheme
フィールドを指定します。IAM 条件の loadBalancingScheme
フィールドにチェックを入れることで、特定の種類のロードバランサを作成する権限をメンバーに付与できます。
IAM Conditions の指定
他のロール バインディングの構成で使用したものと同じ setIamPolicy
メソッドを使用して、条件付きロール バインディングを設定できます。プロジェクトの条件を使用してロール バインディングを設定するには、REST API、gcloud
コマンドライン ツール、または Cloud Console の IAM ページを使用します。
詳細については、条件付きポリシーの管理をご覧ください。
負荷分散の条件式の例
IAM ポリシーで使用できる以下の条件式は、次のいずれかに該当する場合にのみ API リクエストを許可します。
- リクエストが転送ルールの作成に関与しない場合。
- リクエストが、内部スキームのいずれか 1 つを持つ転送ルールを作成する場合。
!compute.isForwardingRuleCreationOperation() || (
compute.isForwardingRuleCreationOperation() &&
compute.matchLoadBalancingSchemes(['INTERNAL', 'INTERNAL_MANAGED', 'INTERNAL_SELF_MANAGED'])
)
このポリシーにより、メンバーが EXTERNAL
負荷分散スキームで転送ルールを作成しようとすると、権限エラー メッセージが表示されます。これは、負荷分散スキーム EXTERNAL
が省略されているためです。
ポリシーの例
プロジェクトの IAM ポリシーの次の例では、外部ロードバランサを作成する権限を除く(負荷分散スキーム EXTERNAL
が省略されているため)、ロードバランサ管理者の事前定義済みのロールを IAM メンバー jane@example.com
に付与しています。jane@example.com
は、内部ロードバランサの作成、および任意のロードバランサの管理、変更、削除ができるようになります。
{
"bindings": [
{
"role": "roles/compute.loadBalancerAdmin",
"members": ["user:jane@example.com"],
"condition": {
"title": "only_internal_lb_schemes",
"description": "Internal LB creation only permitted",
"expression": "
!compute.isForwardingRuleCreationOperation() || (
compute.isForwardingRuleCreationOperation() &&
compute.matchLoadBalancingSchemes(['INTERNAL', 'INTERNAL_MANAGED', 'INTERNAL_SELF_MANAGED'])
)
"
}
}
]
}
特定の種類の転送ルールに対する GKE サービス アカウント権限の付与
IAM Conditions を使用して GKE サービス アカウントへのアクセスを制限し、特定のタイプの転送ルールのみを作成することもできます。
次の JSON の例は、GKE サービス アカウント(service-<project-ID>@container-engine-robot.iam.gserviceaccount.com
)に Kubernetes Engine サービス エージェントのロールを付与する完全な IAM ポリシーを示しています。このロールにより、サービス アカウントは外部転送ルール以外のロードバランサ コンポーネントを作成、変更、削除できるようになります。
この条件付き付与を使用する場合、GKE サービス アカウントが作成できるのは新しい内部転送ルールのみですが、既存のすべての転送ルールを管理できるようになります。
{
"bindings": [
{
"role": "roles/container.serviceAgent",
"members": ["serviceAccount:service-<project-ID>@container-engine-robot.iam.gserviceaccount.com"],
"condition": {
"title": "only_internal_lb_schemes",
"description": "Internal LB Creation Only Permitted",
"expression": "(
compute.isForwardingRuleCreationOperation()
&&
compute.matchLoadBalancingSchemes(['INTERNAL', 'INTERNAL_MANAGED', 'INTERNAL_SELF_MANAGED'])
)
||
!compute.isForwardingRuleCreationOperation()
"
}
}
]
}
他に付与されている権限がない場合、内部 TCP / UDP ロードバランサのアノテーションなしで LoadBalancer タイプの新しい GKE サービスを作成しようとすると、次のようなエラー メッセージが表示されます。
Error creating load balancer (will retry): failed to ensure load balancer for
service default/SERVICE-NAME: failed to create forwarding rule for load balancer
(a01d427111c7011ea96e142010a80006(default/SERVICE-NAME)): googleapi: Error 403:
Required 'compute.forwardingRules.create' permission for
'projects/[project-id]/regions/[region]/forwardingRules/[forwarding-rule-name]',
forbidden
また、他に付与されている権限がない場合に Cloud Load Balancing Ingress コントローラを使用して新しい Ingress オブジェクトを作成しようとすると、同様のエラー メッセージが表示されます。これは、Cloud Load Balancing Ingress コントローラが外部 HTTP(S) ロードバランサを作成する必要があるためです。
上記の例では、kubectl describe
コマンドと kubectl get events -w
コマンドを使用して GKE エラー メッセージを確認できます。
次のステップ
- IAM の詳細について学習する。
- IAM 役割を付与する。