[アップデート] Elastic Load Balancing で IAM 条件キーを使ってユーザーが作成可能なロードバランサーの条件を制限出来るようになりました

[アップデート] Elastic Load Balancing で IAM 条件キーを使ってユーザーが作成可能なロードバランサーの条件を制限出来るようになりました

Clock Icon2023.11.14

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

いわさです。

今朝のアップデートでロードバランサー作成時にサービス固有の IAM 条件キーが追加されました。

この条件キーを使うことで、IAM ポリシーでロードバランサーやリスナーの作成・更新時に条件を設定することが出来るようになります。
これによって、例えば組織のルールとしてインターネット向けのロードバランサーの作成を制限したいとか、特定のセキュリティグループのみ関連付け出来るようにするとか、特定バージョンの ELBSecurityPolicy 以外は許可しないなど、組織統制を行うユースケースで活用することが出来ます。

制限出来るようになったもの

今回新たに追加された条件キーは以下です。

  • elasticloadbalancing:ListenerProtocol
  • elasticloadbalancing:SecurityPolicy
  • elasticloadbalancing:Scheme
  • elasticloadbalancing:Subnet
  • elasticloadbalancing:SecurityGroup

IAM ポリシーで CreateLoadBalancer や CreateListener などのアクションと併せて使うことで、特定条件のみ作成や変更を許可することが出来ます。

上記条件キーはマネジメントコンソールでいうと次の箇所になります。
これらを IAM ポリシーで制約をかけることが出来るようになりました。

elasticloadbalancing:Schemeはロードバランサーのスキーム(インターネット向け or 内部)を制限出来ます。

elasticloadbalancing:Subnetelasticloadbalancing:SecurityGroupでは、ロードバランサーにマッピングされるサブネットとセキュリティグループを許可・拒否することが出来ます。

elasticloadbalancing:ListenerProtocolではリスナーのプロトコルを、elasticloadbalancing:SecurityPolicyでは HTTPS を構成した際のセキュリティポリシーを制限することが出来ます。

スキーム、セキュリティグループ、セキュリティポリシーあたりは利用のイメージがしやすいですね。
管理者が、開発者にロードバランサーの作成を許可しつつポリシーを定めたいシーンはありそうです。

なお、Application Load Balancer (ALB)、Network Load Balancer (NLB)、Classic Load Balancer (CLB) で上記 5 つの条件キーを使うことが出来ます。
また、Gateway Load Balancer (GWLB) についてはelasticloadbalancing:SecurityGroupのみサポートされているようです。

ビジュアルエディターからポリシーを作成して試してみるが...

今回は次のようなインターネット向けのロードバランサーの作成を拒否する設定を行ってみましょう。
内部向けロードバランサーのみ許可します。

まずはビジュアルエディターで IAM ポリシーを作成してみます。
アクションは ELB v2 の CreateLoadBalancer を選択します。

サービスレベルの条件キーを検索してみると、次のように追加された条件キーを選択することが出来るようになっています。
ここではelasticloadbalancing:Schemeを選択します。

一点注意点がありまして、本日時点でビジュアルエディターから CreateLoadBalancer アクションなどを個別に選択した場合、次のように「このポリシーは、いかなる許可も付与しません。アクセス権を付与するポリシーは、対象のリソースまたは条件に適用可能なアクションが必要です。詳細については、残りを表示します。」と表示されてしまいます。

JSON で確認してみると、次のようなポリシーが設定されています。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Deny",
            "Action": "elasticloadbalancering:CreateLoadBalancer",
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "elasticloadbalancing:Scheme": "internet-facing"
                }
            }
        }
    ]
}

ちなみに上記内容は本日時点の公式ドキュメントとも一致しており、問題なさそうに思えます。

しかし、このポリシーだと次のようにロードバランサーが作成出来てしまいます。

JSON エディターで修正する

うーんと悩みながらポリシーを眺めていて気がついたのですが、公式ドキュメントもマネジメントコンソールのビジュアルエディターから作成された場合も、アクションがelasticloadbalancering:として作成されています。なんでだろう。

適当に試してみたところ、どうやらelasticloadbalancing:が正しいようです。
JSON エディターで次のようにアクションを修正します。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Deny",
            "Action": "elasticloadbalancing:CreateLoadBalancer",
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "elasticloadbalancing:Scheme": "internet-facing"
                }
            }
        }
    ]
}

これで試してみるとインターネット向けロードバランサーの作成が拒否されるようになりました。良いですね。

そして、内部向けロードバランサーの作成については許可されています。こちらも期待どおりです。

さいごに

本日は Elastic Load Balancer で IAM 条件キーを使って、ユーザーが作成可能なロードバランサーの条件を制限出来るようになったので、内部向けロードバランサーのみを許可設定してみました。

途中、IAM ポリシーのビジュアルエディターで変な値が設定されてしまうアクシデントがありましたが、そのうちきっと修正されるでしょう。修正されるまでの間は JSON エディターで直接編集をお試しください。

組織として作成リソースのポリシーを定めたい場合があり、以前も ACM を発行を条件キーで制限するアップデートがありましたが、ELB についても同じような方式で統制することが出来るようになりますね。

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.