VPC セキュリティー・グループの作成および管理
Virtual Private Cloud
クラスター作成時のセキュリティー・グループの追加
VPC クラスターを作成すると、 kube-<clusterID>
という名前のデフォルトのワーカー・セキュリティー・グループが自動的に作成され、クラスター内のすべてのワーカーに適用されます。 デフォルトのワーカー・セキュリティー・グループに加えて、追加のセキュリティー・グループを付加することもできます。 クラスタ内のワーカーに適用されるセキュリティグループは、クラスタを作成する際に適用したセキュリティグループとワーカープールを作成する際に適用したセキュリティグループの組み合わせです。
ワーカーには合計 5 つのセキュリティー・グループを適用できます。これには、デフォルトのセキュリティー・グループと、ワーカー・プールに適用されるすべてのセキュリティー・グループが含まれます。 カスタム・セキュリティー・グループをワーカーに追加するオプションは、CLI でのみ使用可能であることに注意してください。
クラスターに適用したセキュリティー・グループは、クラスターの作成後に変更することはできません。 クラスタに適用されるセキュリティグループのルールを変更することはできますが、クラスタレベルでセキュリティグループを追加または削除することはできません。 クラスターの作成時に誤ったセキュリティー・グループを適用した場合は、クラスターを削除して新しいクラスターを作成する必要があります。
デフォルトのセキュリティグループのみを使用したい場合
VPC セキュリティー・グループ ワーカー・セキュリティー・グループ
これは、クラスター作成時のデフォルトの動作です。
クラスターの作成時には、追加のセキュリティー・グループを指定しないでください。
デフォルトの VPC セキュリティー・グループおよび kube-<clusterID>
クラスター・セキュリティー・グループのみを使用して VPC クラスターを作成するコマンドの例:
ibmcloud ks cluster create vpc-gen2 --name <cluster-name> --zone <zone> --vpc-id <vpc-id> --subnet-id <subnet-id>
以下のセキュリティー・グループが適用されます。
- デフォルトのVPCセキュリティグループ(ランダムに生成された名前)
kube-<clusterID>
ワーカー・セキュリティー・グループ。
クラスター・セキュリティー・グループと独自の追加セキュリティー・グループが必要な場合
VPC セキュリティー・グループ ワーカー・セキュリティー・グループ 独自のセキュリティー・グループ
クラスターの作成時に、--cluster-security-group cluster
と、所有する追加セキュリティー・グループ (最大 4 つ) を指定します。 追加する個々のセキュリティー・グループごとに、個別の --cluster-security-group
オプションを指定する必要があります。 ワーカーに適用できるセキュリティー・グループは、デフォルトで適用されるセキュリティー・グループを含めて最大 5 つです。
kube-<clusterID>
クラスター・セキュリティー・グループと独自の追加セキュリティー・グループを使用して VPC クラスターを作成するコマンドの例:
ibmcloud ks cluster create vpc-gen2 --name <cluster-name> --zone <zone> --vpc-id <vpc-id> --subnet-id <subnet-id> --cluster-security-group cluster --cluster-security-group <group-id-1> --cluster-security-group <group-id-2> --cluster-security-group <group-id-3>
以下のセキュリティー・グループが適用されます。
- デフォルトのVPCセキュリティグループ(ランダムに生成された名前)。
kube-<clusterID>
ワーカー・セキュリティー・グループ- 最大 4 つの追加セキュリティー・グループ (合計で最大 5 つのセキュリティー・グループ)。
独自のセキュリティー・グループのみが必要な場合
VPC セキュリティー・グループ 独自のセキュリティー・グループ
このオプションは、バージョン 1.29 以前で作成されたクラスターでのみ使用可能です。 1.30以降、すべてのクラスターがワーカー・ノードのセキュリティー・グループも取得するようになりました。
クラスターの作成時に、所有する最大 5 つのセキュリティー・グループを指定します。 追加する個々のセキュリティー・グループごとに、個別の --cluster-security-group
オプションを指定する必要があります。
独自のセキュリティー・グループのみを使用して VPC クラスターを作成するコマンドの例:
ibmcloud ks cluster create vpc-gen2 --name <cluster-name> --zone <zone> --vpc-id <vpc-id> --subnet-id <subnet-id> --cluster-security-group <group-id-1> --cluster-security-group <group-id-2> --cluster-security-group <group-id-3>
以下のセキュリティー・グループが適用されます。
- デフォルトのVPCセキュリティグループ(ランダムに生成された名前)
- 最大 4 つの追加セキュリティー・グループ (合計で最大 5 つのセキュリティー・グループ)。
作成時のワーカー・プールへのセキュリティー・グループの追加
デフォルトでは、ワーカー・プールに適用されるセキュリティー・グループは、クラスター作成時に示されるものと同じセキュリティー・グループです。 ただし、ワーカー・プールに適用する追加のセキュリティー・グループを指定できます。 ワーカー・プールに追加のセキュリティー・グループを適用する場合、クラスター上のワーカーに適用されるセキュリティー・グループは、クラスター作成時に適用されるセキュリティー・グループとワーカー・プールに適用されるセキュリティー・グループの組み合わせになります。
ワーカーには、最大 5 つのセキュリティー・グループ (デフォルトで適用されるセキュリティー・グループを含む) を適用できます。
ワーカー・プールに適用されるセキュリティー・グループは、ワーカー・プールの作成後に変更することはできません。 ワーカー・プールに適用されているセキュリティー・グループのルールを変更することはできますが、ワーカー・プール・レベルでセキュリティー・グループを追加したり削除したりすることはできません。 ワーカー・プールの作成時に誤ったセキュリティー・グループを適用した場合は、ワーカー・プールを削除して新しいワーカー・プールを作成する必要があります。
ワーカー・プールに追加のセキュリティー・グループを関連付けない場合
ワーカー・プールの作成時には、追加のセキュリティー・グループを指定しないでください。
このシナリオは、バージョン 1.29 以前にのみ適用されます。
セキュリティー・グループを適用せずにワーカー・プールを作成するコマンドの例:
ibmcloud ks worker-pool create vpc-gen2 --name <worker_pool_name> --cluster <cluster_name_or_ID> --flavor <flavor> --size-per-zone <number_of_workers_per_zone>
クラスターに適用されたセキュリティー・グループのみがワーカーに適用されます。
ワーカープールに追加のセキュリティグループを割り当てたい場合
ワーカープールを作成する際には、ワーカープール作成時に追加のセキュリティグループを指定します。 追加する個々のセキュリティー・グループごとに、個別の --security-group
オプションを指定する必要があります。
独自のセキュリティー・グループを適用してワーカー・プールを作成するコマンドの例:
ibmcloud ks worker-pool create vpc-gen2 --name <worker_pool_name> --cluster <cluster_name_or_ID> --flavor <flavor> --size-per-zone <number_of_workers_per_zone> --security-group <group-id-1> --security-group <group-id-2> --security-group <group-id-3>
ワーカー・プール内のワーカーに適用されるセキュリティー・グループは、ワーカー・プールが関連付けられているクラスターに適用されるセキュリティー・グループと、作成時にワーカー・プールに適用されるセキュリティー・グループの組み合わせです。
セキュリティー・グループの表示
VPC セキュリティー・グループに関する詳細を表示するには、以下の手順を実行します。
-
クラスタのリストを作成し、作業中のクラスタのID をメモしてください。
クラスターがどの VPC にあるかを確認するには、
ibmcloud ks cluster get --cluster <cluster_name_or_id>
を実行し、出力で VPC ID を確認します。ibmcloud ks cluster ls --provider vpc-gen2
-
クラスターが存在する VPC に接続されているセキュリティー・グループをリストします。 VPC セキュリティー・グループには、ランダムに生成された名前 (
trench-hexagon-matriarch-flower
など) が割り当てられます。 クラスタセキュリティグループは、kube-<cluster-ID>
という形式で命名されます。 VPCセキュリティグループの名前は、kube-<vpc-ID>
という形式で指定されます。ibmcloud is sgs | grep <vpc_name>
出力例
ID Name Rules Network interfaces VPC Resource group r006-111aa1aa-1a1a-1a11-1111-a111aaa1a11a trench-hexagon-matriarch-flower 4 0 my-vpc default r006-222aa2aa-2a2a-2a22-2222-a222aaa2a22a kube-a111a11a11aa1aa11a11 4 0 my-vpc default r006-333aa3aa-3a3a-3a33-3333-a333aaa3a33a kube-r006-111a11aa-aaa1-1a1a-aa11-1a1a111aa11 4 0 my-vpc default
-
セキュリティー・グループの詳細を取得します。 出力で**「ルール」**セクションを見つけて、セキュリティー・グループに関連付けられているインバウンド・ルールとアウトバウンド・ルールを確認します。
ibmcloud is sg GROUP
出力例
... Rules ID Direction IP version Protocol Remote r006-111bb1bb-1b1b-1b11-1111-b111bbb1b11b outbound ipv4 all 0.0.0.0/0 r006-222bb2bb-2b2b-2b22-2222-b222bbb2b22b inbound ipv4 all behind-unbuilt-guidable-anthill r006-333bb3bb-3b3b-3b33-3333-b333bbb3b33b inbound ipv4 icmp Type=8 0.0.0.0/0 r006-444bb4bb-4b4b-4b44-4444-b444bbb4b44b inbound ipv4 tcp Ports:Min=22,Max=22 0.0.0.0/0
コンソールでのセキュリティー・グループの表示
-
VPCダッシュボードのセキュリティグループから、クラスタが属するVPCにアタッチされているセキュリティグループを見つけます。
-
セキュリティグループをクリックします。
接続先の VPC でセキュリティー・グループをソートするには、表の**「仮想プライベート・クラウド」**列見出しをクリックします。
-
セキュリティー・グループに関連付けられたインバウンド・ルールおよびアウトバウンド・ルールを表示するには、**「ルール」**タブをクリックします。
コンソールでのセキュリティー・グループのルールの作成
- 仮想プライベートクラウドダッシュボードから、クラスタが属するVPCのデフォルトセキュリティグループ名をクリックします。
- **「ルール」**タブをクリックします。
- ワーカー・ノードへのインバウンド・トラフィックを制御する新しいインバウンド・ルールを作成するには、インバウンド・ルールセクションで 作成をクリックします。
- ワーカー・ノードのアウトバウンド・トラフィックを制御する新規ルールを作成するには、**「アウトバウンド・ルール」**セクションで、すべてのアウトバウンド・トラフィックを許可するデフォルトのルールを削除します。 次に、アウトバウンド・ルール セクションで Createをクリックします。
作成するルールに加えて、必要なインバウンド・ルールとアウトバウンド・ルールも作成する必要があることに注意してください。
コマンド行でのセキュリティー・グループ・ルールの作成
IBM Cloud の CLI を使用して、クラスターのデフォルトのセキュリティー・グループにインバウンド・ルールとアウトバウンド・ルールを追加できます。
infrastructure-service
プラグインをインストールします。 コマンドを実行するための接頭部は、ibmcloud is
です。ibmcloud plugin install infrastructure-service
- VPC が存在するリージョンをターゲットにします。
ibmcloud target -r REGION
- クラスターの ID を確認します。
ibmcloud ks cluster get -c CLUSTER
- セキュリティー・グループをリスト表示し、VPC のデフォルトのセキュリティー・グループの ID をメモします。 デフォルトのセキュリティー・グループは、ランダムに生成された名前を使用し、
kube-<cluster_ID>
形式でないことに注意してください。
ランダムに生成された名前ibmcloud is sgs
chamomile-dislodge-showier-unfilled
の VPC のデフォルト・セキュリティー・グループを使用した出力例。ID Name Rules Network interfaces VPC Resource group 1a111a1a-a111-11a1-a111-111111111111 chamomile-dislodge-showier-unfilled 5 2 events-vpc default 2b222b2b-b222-22b2-b222-222222222222 kube-df253b6025d64744ab99ed63bb4567b6 5 3 gen2-vpn default
- セキュリティー・グループの ID を環境変数として格納します。
sg=GROUP
- セキュリティー・グループのデフォルト・ルールを確認します。 作成するルールに加えて、必要なインバウンド・ルールとアウトバウンド・ルールも作成する必要があることに注意してください。
ibmcloud is sg $sg
-
インバウンド・トラフィック・ルールを作成するには、
ibmcloud is sg-rulec <sg> inbound
コマンドを使用します。ibmcloud is sg-rulec $sg inbound <protocol> [--remote <remote_address> | <CIDR_block> | <security_group_ID>] [--icmp-type <icmp_type> [--icmp-code <icmp_code>]] [--port-min <port_min>] [--port-max <port_max>]
-
アウトバウンド・トラフィック・ルールを作成するには、
ibmcloud is sg-rulec <sg> outbound
コマンドを使用します。ibmcloud is sg-rulec $sg outbound <protocol> [--remote <remote_address> | <CIDR_block> | <security_group_ID>] [--icmp-type <icmp_type> [--icmp-code <icmp_code>]] [--port-min <port_min>] [--port-max <port_max>]
-
カスタム・アウトバウンド・ルールを作成した後、すべてのアウトバウンド・トラフィックを許可するデフォルト・ルールの ID を取得します。
ibmcloud is sg $sg
出力例
Rules ID Direction IP version Protocol Remote r010-e3a34cbb-d5e8-4713-a57e-3e35a7458272 inbound ipv4 all freeload-flavored-surging-repaying r010-036c3a13-1c16-4425-9667-a4ec34b1702b inbound ipv4 icmp Type=8 0.0.0.0/0 r010-15591636-6976-493f-a94f-70721702860a inbound ipv4 tcp Ports:Min=22,Max=22 0.0.0.0/0
-
すべてのアウトバウンド・トラフィックを許可するデフォルトのルールを削除します。
ibmcloud is security-group-rule-delete $sg <rule_ID>
-
-
独自のセキュリティー・グループを作成したり、作成したルールに追加したルールを追加または削除したりできることに留意してください。また、必要な インバウンド・ルールとアウトバウンド・ルール も作成する必要があります。
ワーカーノードがIngressに接続できるようにする LoadBalancer
以下の手順に従って、ワーカー・ノードが Ingress LoadBalancerに接続できるようにします。
このシナリオは、バージョン 1.29 以前にのみ適用されます。
-
LoadBalancer サービスの
EXTERNAL-IP
を取得します。kubectl get svc -o wide -n openshift-ingress router-default
-
EXTERNAL-IP
でdig
を実行して、LoadBalancer に関連付けられた IP アドレスを取得します。dig <EXTERNAL-IP> +short
出力例
150.XXX.XXX.XXX 169.XX.XXX.XXX
-
前に取得した各 IP アドレスとポート 443 に対するアウトバウンド・セキュリティー・ルールを作成します。
ibmcloud is sg-rulec <sg> outbound tcp --port-min 443 --port-max 443 --remote 150.XXX.XXX.XXX
Ingressまたはコンソールオペレーターが健康チェックに不合格となった場合、これらの手順を繰り返して、 LoadBalancer のIPアドレスが変更されたかどうかを確認できます。 まれなケースですが、 LoadBalancers へのトラフィック量が大幅に変動する場合、負荷の増減に対応するためにこれらのIPアドレスが変更されることがあります。