最近あまりIBM Cloudの最新動向に追いつけていないので、少し時間をとって勉強しました。
タイトルの通り、久しぶりにIKS (IBM Cloud Kubernetes Service)と戯れてみます。
試してみたこと（サマリー）
今回の記事では以下を確認しました。
他も色々試してはみていますが、暇を見つけて追記・別記事を用意していきたいとは思います。
- セキュリティーを考慮し、Private Endpoint OnlyなIKSクラスター VPC Gen2に構成する
- Private Endpoint Onlyな状態でどうやってユーザーが操作できるのか確認する
- Private Endpoint Onlyな状態でアプリを公開する（次回へ続く）
# 本当はRed Hat OpenShiftで試したかったのですが・・・、また今度で。
今回の構成
こんな構成を今回作ってみました。
Step 1. VPCのセットアップ
IKSクラスターを作成する前に、以下の準備を行います。
VPC, サブネットの準備
以下の記事を参考に、以下用意しています。
IBM Cloud の VPC と VPC と Classic Infrastructure を Transit Gateway で接続する
地域(Region)
2020年6月29日現在、以下の４拠点でVPC Gen2がサポートされています。
$ ibmcloud is regions
ユーザー XXXX@gmail.com としてアカウント XXXX の下で世代 2 コンピュートの地域をリストしています...
名前 エンドポイント 状況
eu-de https://eu-de.iaas.cloud.ibm.com available
eu-gb https://eu-gb.iaas.cloud.ibm.com available
us-east https://us-east.iaas.cloud.ibm.com available
us-south https://us-south.iaas.cloud.ibm.com available
VPC
ダラス地域を利用して、BastionとInfraの2つのVPC(Gen2)を作成しました。
- Bastion: 踏み台用のVPC。ユーザーがインターネットからログインし、利用する想定
- Infra: Private Endpoint OnlyなIKSを動かすVPC。アプリを動かす閉じた環境と想定
$ ibmcloud is vpcs
ユーザー XXXX@gmail.com としてアカウント XXXX の下でリソース・グループ prod と地域 us-south 内の世代 2 コンピュートの VPC をリストしています...
ID 名前 状況 クラシック・アクセス デフォルト・ネットワーク ACL デフォルト・セキュリティー・グループ リソース・グループ
r006-XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXc519 bastion available no bastion-network-acl bastion-security-group prod
r006-YYYYYYYY-YYYY-YYYY-YYYY-YYYYYYYYeaf0 infra available no infra-network-acl infra-security-group prod
サブネット(Subnet)
以下の通り、サブネットを用意しました。
IKSが使用するサブネットとしてiks-subnet-X (X=1,2,3)を使用します。
$ibmcloud is subnets
ユーザー XXXX@gmail.com としてアカウント XXXX の下でリソース・グループ prod と地域 us-south 内の世代 2 コンピュートの サブネット をリストしています...
ID 名前 状況 サブネット CIDR アドレス ACL パブリック・ゲートウェイ VPC ゾーン リソース・グループ
0717-XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXX1e40 bastion-subnet-1 available 192.168.10.0/24 251/256 bastion-network-acl - bastion us-south-1 prod
0717-YYYYYYYY-YYYY-YYYY-YYYY-YYYYYYYYc41f iks-subnet-1 available 192.168.110.0/24 251/256 infra-network-acl - infra us-south-1 prod
0727-YYYYYYYY-YYYY-YYYY-YYYY-YYYYYYYYf6c1 iks-subnet-2 available 192.168.120.0/24 251/256 infra-network-acl - infra us-south-2 prod
0737-YYYYYYYY-YYYY-YYYY-YYYY-YYYYYYYYa4c9 iks-subnet-3 available 192.168.130.0/24 251/256 infra-network-acl - infra us-south-3 prod
Network ACLの設定
各ネットワークに対し、ACLの設定を事前に行います。
$ibmcloud is network-acls
ユーザー XXXX としてアカウント XXXX の下でリソース・グループ prod と地域 us-south 内の世代 2 コンピュートの ネットワーク ACL をリストしています...
ID 名前 ルール サブネット VPC リソース・グループ
r006-XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXX2659 bastion-network-acl 2 1 bastion prod
r006-YYYYYYYY-YYYY-YYYY-YYYY-YYYYYYYYf2cb infra-network-acl 24 4 infra prod
Bastion側のNetwork ACLは、Input/Outputともにすべて許可（デフォルト）としています。
bastion-network-acl
$ ibmcloud is network-acl-rules r006-XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXX2659
ユーザー XXXX@gmail.com としてアカウント XXXX の下でネットワーク ACL r006-XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXX2659 のルールをリストしています...
inbound
ID 名前 アクション IP バージョン プロトコル ソース 宛先 作成済み
r006-XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXX3b02 allow-inbound allow ipv4 all 0.0.0.0/0 0.0.0.0/0 2020-06-28T02:57:41Z
outbound
ID 名前 アクション IP バージョン プロトコル ソース 宛先 作成済み
r006-XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXX21ac allow-outbound allow ipv4 all 0.0.0.0/0 0.0.0.0/0 2020-06-28T02:57:41Z
一方で、IKSが稼働するInfra側のNetwork ACLに関しては、同じくデフォルトのままでも良いのですが、以下のドキュメントの記載にしたがい、設定しました。
VPC: Controlling traffic with ACLs, security groups, and network policies
166.8.0.0/14はService Endpoint, 161.26.0.0/16は旧SoftLayerのPrivate NWです。
この2つを通すのがPrivate OnlyなIKSクラスターを動かすためのポイントのようです。
infra-network-acl
$ibmcloud is network-acl-rules r006-YYYYYYYY-YYYY-YYYY-YYYY-YYYYYYYYf2cb
ユーザー XXXX@gmail.com としてアカウント XXXX の下でネットワーク ACL r006-YYYYYYYY-YYYY-YYYY-YYYY-YYYYYYYYf2cb のルールをリストしています...
inbound
ID 名前 アクション IP バージョン プロトコル ソース 宛先 作成済み
31adf942-f61a-4f71-9f14-9388ca8785b8 allow-workers-inbound-1 allow ipv4 all 192.168.110.0/24 0.0.0.0/0 2020-06-28T03:44:46Z
1621f375-b5be-4ada-9de4-9ee6953f84fe allow-workers-inbound-2 allow ipv4 all 192.168.120.0/24 0.0.0.0/0 2020-06-28T03:45:11Z
88394e07-767a-441d-90af-78695165e267 allow-workers-inbound-3 allow ipv4 all 192.168.130.0/24 0.0.0.0/0 2020-06-28T03:45:37Z
220d3d15-3435-4bb5-aeca-270e39e9e70a allow-ibm-private-network-inbound1 allow ipv4 all 161.26.0.0/16 0.0.0.0/0 2020-06-28T03:32:31Z
97a7140c-43c5-4d70-b462-e024dd115440 allow-ibm-private-network-inbound2 allow ipv4 all 166.8.0.0/14 0.0.0.0/0 2020-06-28T03:32:44Z
2166f3b6-79b8-4b0b-b62e-70938c42f946 allow-lb-inbound1 allow ipv4 tcp 0.0.0.0/0 0.0.0.0/0 2020-06-28T03:34:08Z
ソース・ポート: 最小=1,最大=65535
宛先ポート: 最小=56501,最大=56501
5e5fbaa1-b596-4539-91eb-7c6d713a85f9 allow-lb-inbound2 allow ipv4 tcp 0.0.0.0/0 0.0.0.0/0 2020-06-28T03:34:20Z
ソース・ポート: 最小=443,最大=443
宛先ポート: 最小=1,最大=65535
368a281b-f316-40be-af9b-3650bf23eb85 allow-lb-inbound3 allow ipv4 tcp 0.0.0.0/0 0.0.0.0/0 2020-06-28T03:34:32Z
ソース・ポート: 最小=8834,最大=8834
宛先ポート: 最小=1,最大=65535
8ef32d57-9fc1-4629-bfa6-01414b45701e allow-lb-inbound4 allow ipv4 tcp 0.0.0.0/0 0.0.0.0/0 2020-06-28T03:34:48Z
ソース・ポート: 最小=10514,最大=10514
宛先ポート: 最小=1,最大=65535
09f75030-1c30-4a7a-9e14-14b5ff96ad99 allow-bastion-inbound allow ipv4 all 192.168.10.0/24 0.0.0.0/0 2020-06-28T03:47:08Z
42e431b2-1c76-423e-b815-5127d3e41c50 allow-lb-incomming allow ipv4 tcp 0.0.0.0/0 0.0.0.0/0 2020-06-28T05:00:31Z
ソース・ポート: 最小=1,最大=65535
宛先ポート: 最小=443,最大=443
2f351987-f234-4f4f-ada8-62c6ed3fe673 deny-all-inbound deny ipv4 all 0.0.0.0/0 0.0.0.0/0 2020-06-28T04:02:42Z
outbound
ID 名前 アクション IP バージョン プロトコル ソース 宛先 作成済み
28109c45-3051-4e7d-8807-58a61d5ca876 allow-workers-outbound-1 allow ipv4 all 0.0.0.0/0 192.168.110.0/24 2020-06-28T03:44:34Z
cacea245-58ed-40d3-89a9-9dca2d867c30 allow-workers-outbound-2 allow ipv4 all 0.0.0.0/0 192.168.120.0/24 2020-06-28T03:44:59Z
e43e659f-c306-434b-a918-0e7b480ff76f allow-workers-outbound-3 allow ipv4 all 0.0.0.0/0 192.168.130.0/24 2020-06-28T03:45:24Z
fdc55b8b-43ea-4a11-8004-3083e9237d26 allow-ibm-private-network-outbound1 allow ipv4 all 0.0.0.0/0 161.26.0.0/16 2020-06-28T03:31:59Z
1511be8d-95c1-4ceb-9be5-dafca5925992 allow-ibm-private-network-outbound2 allow ipv4 all 0.0.0.0/0 166.8.0.0/14 2020-06-28T03:32:17Z
4771a01d-fe21-4625-8c6a-dcd3969044a1 allow-lb-outbound1 allow ipv4 tcp 0.0.0.0/0 0.0.0.0/0 2020-06-28T03:32:56Z
ソース・ポート: 最小=56501,最大=56501
宛先ポート: 最小=1,最大=65535
1c5bc3f3-5722-455a-b131-b715be0ea5be allow-lb-outbound2 allow ipv4 tcp 0.0.0.0/0 0.0.0.0/0 2020-06-28T03:33:18Z
ソース・ポート: 最小=1,最大=65535
宛先ポート: 最小=443,最大=443
5b893862-584b-43fa-a3a1-6618a8cbe8fd allow-lb-outbound3 allow ipv4 tcp 0.0.0.0/0 0.0.0.0/0 2020-06-28T03:33:31Z
ソース・ポート: 最小=1,最大=65535
宛先ポート: 最小=8834,最大=8834
8e362bc2-3bc2-4cc0-9241-6dee03c1e7de allow-lb-outbound4 allow ipv4 tcp 0.0.0.0/0 0.0.0.0/0 2020-06-28T03:33:54Z
ソース・ポート: 最小=1,最大=65535
宛先ポート: 最小=10514,最大=10514
deecd6fd-5bc6-4f2c-a29c-8ad5f41bd4ff allow-bastion-outbound allow ipv4 all 0.0.0.0/0 192.168.10.0/24 2020-06-28T03:46:53Z
ce0bb8ab-d6a1-463b-bdd1-c77d1397e8ea allow-lb-return allow ipv4 tcp 0.0.0.0/0 0.0.0.0/0 2020-06-28T05:00:57Z
ソース・ポート: 最小=443,最大=443
宛先ポート: 最小=1,最大=65535
949b219b-b6b2-497f-a636-dd235d8f1364 deny-all-outbound deny ipv4 all 0.0.0.0/0 0.0.0.0/0 2020-06-28T04:02:30Z
注意事項（そのうち再検証）
allow-lb-inbound/outboundをドキュメント上で定義しますが、定義が足りていない気がします。
アプリの公開時に気づきましたが、本記事ではinboundにallow-lb-incomming、outboundにallow-lb-returnをそれぞれ追加で登録しています。
セキュリティグループの設定
各VPCに対し、セキュリティグループの設定を事前に行います。
$ ibmcloud is security-groups
ユーザー XXXX@gmail.com としてアカウント XXXX の下でリソース・グループ prod と地域 us-south 内の世代 2 コンピュートの セキュリティー・グループ をリストしています...
ID 名前 ルール ネットワーク・インターフェース VPC リソース・グループ
r006-XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXX61c5 bastion-security-group 5 0 bastion prod
r006-YYYYYYYY-YYYY-YYYY-YYYY-YYYYYYYY364b infra-security-group 5 0 infra prod
Bastion側のセキュリティグループには、作業端末(IP: aaa.aaa.aaa.aaa)のアクセスのためのエントリーと、Infra側のVPCとTransit Gateway経由で通信するためのエントリーを追加しています。
bastion-security-group
$ ibmcloud is security-group-rules r006-XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXX61c5
ユーザー XXXX@gmail.com としてアカウント XXXX の下でセキュリティー・グループ r006-XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXX61c5 のルールをリストしています...
ID 方向 IP バージョン プロトコル リモート
r006-61cacd44-398d-41e6-a446-7f8e736685d0 outbound ipv4 all 0.0.0.0/0
r006-da9e86a7-b4ad-49d5-a2b7-04170ef0b6f5 inbound ipv4 all bastion-security-group
r006-f5812f78-4f36-40f9-a301-fa223c68a0a0 inbound ipv4 icmp タイプ=8 aaa.aaa.aaa.aaa/32
r006-6f53637c-7ef1-4ac8-b228-e68044b7632f inbound ipv4 tcp ポート:最小=22,最大=22 aaa.aaa.aaa.aaa/32
r006-754edfb8-2147-47ce-9e86-e8c33dec8d36 inbound ipv4 all 192.168.0.0/16
Infra側のセキュリティグループには、IKSのWorker NodeのNodePortに対するinbound通信の許可と、Bastion側のVPCとTransit Gateway経由で通信するためのエントリーを追加しています。
infra-security-group
$ibmcloud is security-group-rules r006-YYYYYYYY-YYYY-YYYY-YYYY-YYYYYYYY364b
ユーザー XXXX@gmail.com としてアカウント XXXX の下でセキュリティー・グループ r006-YYYYYYYY-YYYY-YYYY-YYYY-YYYYYYYYc364b のルールをリストしています...
ID 方向 IP バージョン プロトコル リモート
r006-dfc98884-e23a-444e-bf30-f4da1e931ec4 outbound ipv4 all 0.0.0.0/0
r006-d44d4f61-0119-4877-9d4b-13e8a7843516 inbound ipv4 all infra-security-group
r006-56f1bd0e-8196-4ec7-8f04-3dc76edb8416 inbound ipv4 all 192.168.0.0/16
r006-2deb6be5-e6d6-40d9-b877-4e078749821c inbound ipv4 tcp ポート:最小=30000,最大=32767 0.0.0.0/0
r006-d5cd6b5a-d91e-4460-95b8-1d4315b28e1a inbound ipv4 udp ポート:最小=30000,最大=32767 0.0.0.0/0
Transit Gatewayの準備
Bastion側VPCとInfra側VPC間の通信を有効にするため、ダラス・リージョンにTransit Gateway (local)を追加します。
$ ibmcloud tg gateways
Listing gateways under account XXXX as user XXXX@gmail.com...
OK
GatewayID fc7aXXXX-XXXX-XXXX-XXXX-XXXXXXXXd420c
CRN crn:v1:bluemix:public:transit:us-south:a/XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX::gateway:fc7aXXXX-XXXX-XXXX-XXXX-XXXXXXXXd420c
Name dal-tgw
Routing local
Location us-south
Created 2020-06-28T12:06:36.901+09:00
Resource group ID 29b2XXXXXXXXXXXXXXXXXXXXXXXX1745
Status available
Transit Gatewayに各々のVPCに対する接続を追加します。
$ ibmcloud tg connections fc7aXXXX-XXXX-XXXX-XXXX-XXXXXXXXd420c
Listing connections for GatewayID:fc7aXXXX-XXXX-XXXX-XXXX-XXXXXXXXd420c under account XXXX as user XXXX@gmail.com...
OK
Name bastion
NetworkID crn:v1:bluemix:public:is:us-south:a/XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX::vpc:r006-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxc519
Network Type vpc
Connection ID 8751XXXX-XXXX-XXXX-XXXX-XXXXXXXXc44c
Status attached
Name infra
NetworkID crn:v1:bluemix:public:is:us-south:a/XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX::vpc:r006-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxeaf0
Network Type vpc
Connection ID 32f2XXXX-XXXX-XXXX-XXXX-XXXXXXXXef73
Status attached
Step 2. IKSクラスターの作成
それでは、IKSクラスターを作成します。
IBM Cloudにログインし、カタログから「Kubernetes Service」を選択します
プランは「標準クラスター」、クラスタータイプは「Kubernetes」を選択します
環境は「VPCインフラストラクチャー」を選択し、VPCはダラスの「infra」、クラスター名を入力します
ロケーションで、ワーカー・ゾーンはすべてのゾーン、サブネットはiks-subnet-X (X=1,2,3)を指定します
マスター・サービス・エンドポイントは「プライベート・エンドポイントのみ」を選択します
デフォルトのワーカー・プールに関して、ワーカー・ノードのフレーバーを指定します
ワーカー・ノード数を指定します
作成をクリックして、クラスターを作成します
クラスターの状態が正常になるまでしばらく待ちます (3 Node * 3 Zonesでだいたい30分くらい)
クラスターの状態が正常になったら完了です
Step 3. IKSクラスターへのアクセス
Private Endpointのみの状態では、インターネット経由でアクセスしても当然操作はできません。。
# IKSクラスターにアクセスするためのコンテキストを設定
$ ibmcloud ks cluster config --cluster ra1n-cluster-1
OK
ra1n-cluster-1 の構成は正常にダウンロードされました。
ra1n-cluster-1 のコンテキストを現在の kubeconfig ファイルに追加しました。
これで、クラスターに対して「kubectl」コマンドを実行できます。 例えば、「kubectl get nodes」を実行します。
# Master Endpointにアクセスしようにも、166.8.0.0/14に属するService Endpointが宛先なのでアクセス不可
$ kubectl get node
Unable to connect to the server: dial tcp 166.9.32.45:31821: i/o timeout
実際にIKSクラスターにアクセスし、操作を行うためには以下のいずれかの対応が必要です。
1. Kubernetesダッシュボードを使用する (IBM Cloudコンソール提供)
2. Kubernetes Terminalを使用する（IKSで提供されるアドオンを有効にする）
3. Private Endpointにアクセスできるノードからアクセスする
それぞれ説明します。
1. Kubernetesダッシュボードを使用する
デフォルトで利用可能なIKSの機能です。
コンソール右上の「Kubernetes ダッシュボード」をクリックします。
2. Kubernetes Terminalを使用する
IKSのアドオンに、Kubernetes Terminalが提供されています。
クラスターのアドオン管理画面からKubernetes Terminalの「インストール」をクリックし、有効化します。
有効化されると、IBM Cloudコンソール上でWebターミナルを利用することができるようになります。
コンソール右上の「アクション」の「Web 端末」をクリックします。
すると、ブラウザの下部にWebターミナルが開きます。あとは指示にしたがってkubectlコマンドを使用すれば操作できることが確認できます。
3. Private Endpointにアクセスできるノードからアクセスする
今回用意しておいた、Bastion側VPC上のBastion(踏み台)にログインし、アクセスします。
IBM Cloudへのログインにおいてインターネット接続が必要になってしまうのですが、BastionにはFloating IP(浮動IP)を付与しているので、インターネット接続ができる構成になっています。
# Bastionにログインします
$ ssh -i ./id_rsa root@<Bastion(踏み台)のFloating IPアドレス>
Last login: Sat Jun 27 22:07:53 2020 from a.a.a.a
[root@ra1n-bastion1 ~]#
# 踏み台にIBM Cloud CLIを導入します
[root@ra1n-bastion1 ~]# curl -sL https://ibm.biz/idt-installer | bash
# IBM Cloudにログインします (要インターネット接続)
[root@ra1n-bastion1 ~]# ibmcloud login
# クラスターに接続するための Kubernetes 構成ファイルと証明書をダウンロード
[root@ra1n-bastion1 ~]# ibmcloud ks cluster config --cluster ra1n-cluster-1
OK
ra1n-cluster-1 の構成は正常にダウンロードされました。
ra1n-cluster-1 のコンテキストを現在の kubeconfig ファイルに追加しました。
これで、クラスターに対して「kubectl」コマンドを実行できます。 例えば、「kubectl get nodes」を実行します。
# 操作ができることを確認
[root@ra1n-bastion1 ~]# kubectl get nodes
NAME STATUS ROLES AGE VERSION
192.168.110.4 Ready <none> 30m v1.17.7+IKS
192.168.110.5 Ready <none> 31m v1.17.7+IKS
192.168.110.6 Ready <none> 28m v1.17.7+IKS
192.168.120.4 Ready <none> 7m17s v1.17.7+IKS
192.168.120.5 Ready <none> 5m55s v1.17.7+IKS
192.168.120.6 Ready <none> 6m13s v1.17.7+IKS
192.168.130.4 Ready <none> 8m40s v1.17.7+IKS
192.168.130.5 Ready <none> 10m v1.17.7+IKS
192.168.130.6 Ready <none> 10m v1.17.7+IKS
Tips: アクセスのセキュリティーをさらにあげるには？
せっかくPrivate Endpointなクラスターを作成しても、IBM CloudのコンソールにアクセスできればKubernetesダッシュボードやKubernetes Terminalでどこからでも操作できてしまうことが確認できてしまいました。
実運用を想定するなら、アクセスする拠点のIPアドレス帯を確認し、個々のユーザーに対するIPアドレス制限の設定を追加するべきと思います。
こちらを設定することで、登録していないネットワークからのログインは受け付けられなくなります。
Part.1のまとめ
長くなってしまいましたが、ここまででIKSのPrivate Endpoint Onlyなクラスターを作成し、アクセス方法までを確認しました。
Part.2ではアプリをデプロイし、PublicあるいはPrivateに公開するまでの手順を整理しようと思います。