あけましておめでとうございます。これが 2023 年最初のブログエントリとなります。本年もよろしくお願いいたします。
これまで IBM Cloud で OpenShift クラスタ環境を何度も作って(&そして削除して)来ました。が、それらは全てパブリッククラウド環境としての OpenShift クラスタでした。 このたびプライベートクラウド環境としての OpenShift クラスタを作る機会がありました。その考慮点や手順がパブリッククラウドの時と比べてかなり複雑だったので、備忘録の意味も含めて最初から最後まで手順をまとめてみました。
【プライベートクラウドの設計】
一言で「プライベートクラウド」といっても、その制約というか仕様には色々なパターンが考えられます。例えば「プライベートクラウド」なので、ウェブの管理コンソールや管理 CLI の操作、クラスタにデプロイしたアプリケーションにインターネットからアクセスできない(インターネット側からプライベートクラウドへのアクセスは不可とする)、というのは共通仕様だと思っています。一方で、デプロイするアプリケーションのイメージは Docker ハブから使いたい(つまりプライベートクラウド側からインターネットへのアクセスは許可したい)というケースはあるかもしれませんし、そこも制約として許可したくないケースもあると思います(後者の場合でイメージからデプロイするにはイメージリポジトリもプライベートクラウド内に構築する必要も出てきます)。
以下で手順を紹介するのは「前者」のパターンとします。つまり、
・CLI やウェブコンソールを含めて、インターネットからの直接アクセスは許可しない
・専用の VPN 環境を構築し、この VPN 接続が有効な場合のみアクセスを許可する
・プライベートクラウド側からインターネットへのアクセスは許可する(Docker ハブなどからのアプリケーションデプロイを可能とする)
という条件でプライベートクラウド環境を構築します。なお以下の作業を行う上で必要なユーザー権限は全て取得済みであるものとします。
【VPC とサブネットの作成】
まず、今回のようなパブリックインターフェースを持たないプライベートインターフェースのみの OpenShift クラスタを IBM Cloud に作る場合、クラシックインフラではなく VPC(Virtual Private Cloud)インフラに作る必要があります。そのためまずは OpenShift クラスタを作成するための VPC(Virtual Private Cloud:仮想プライベートクラウド)環境を作成します。IBM Cloud のダッシュボードから「リソースの作成」をクリックします:

カタログ画面の検索バーに "Virtual Private" と入力すると選択候補の中に "Virtual Private Cloud" というのが出てくると思うので、これを選択します:

VPC 環境を作成するロケーションを選択します。以下の例では「アジア太平洋地域」の「東京」を選択しています。ここは自分の環境にあったもの(なるべく利用者に近い場所)を選択してください。そして VPC の名称(下の例では "kkimura-vpc")を入力します:

下にスクロールするとデフォルト接頭部とサブネットに関する情報が表示されます。デフォルトでは選択したロケーション(この場合は東京)の3つのゾーンに1つずつサブネットが用意されます。このままでもよければこのまま進めることもできますが、今回は規模の小さいプライベートクラウド環境を作る想定なので、デフォルト設定を無効にした上でサブネットを1つだけ用意することにします:

というわけで、「各ゾーンのデフォルト接頭部の作成」のチェックを外してください。最後に「仮想プライベート・クラウドの作成」ボタンをクリックします:

仮想プライベート・クラウドの一覧画面に遷移し、先ほど指定した名前の VPC が追加されたことを確認し、これを選択します:

VPC の中身を確認するとアドレス接頭部が空になっています。ここに1つだけ追加することにします:

同じ画面の「アドレス接頭部」タブを選択して「作成」ボタンをクリックします:

画面右から「アドレス接頭部の作成」というウィンドウが表示されます。ここに作成するアドレス空間の範囲(下の例では 10.10.0.0/18)と、そのアドレス空間を作るロケーション(下の例では東京2)を指定して「作成」ボタンをクリックします:

指定した値(10.10.0.0/18)のアドレス空間が定義できました:

アドレス空間が定義できたので、次にサブネットを作成します。画面左ペインから「サブネット」を選択し、「作成」ボタンをクリックします:

ロケーション(下の例ではアジア太平洋の東京2)とサブネットの名称(下の例では "sn-tok2")を指定します。まだ入力項目があるので、そのまま下にスクロールします:

このサブネットを使う VPC を指定し、最後にアドレス接頭部(10.10.0.0/18)内のどの部分をサブネットとして利用するかを指定します(下の例では "10.10.0.0/24" を指定しています)。ここまで指定できたら最後に「サブネットの作成」ボタンをクリックします:

VPC 用のサブネットを新しく1つ定義できました。この後 OpenShift 環境を構築する場合に、このサブネット上に構築することになります:

【パブリックゲートウェイの作成】
今回のプライベートクラウドでは「プライベート環境側からインターネット側へのアクセスは許可する」前提で環境を構築します。これを実現するには「パブリックゲートウェイ」と呼ばれるゲートウェイをサブネットに紐づけることで実現します。 以下ではその手順を紹介します。なお「プライベート環境側からインターネット側へのアクセスも禁止する」というポリシーで構築する場合は、このパブリックゲートウェイ作成手順は読み飛ばしてください。
VPC インフラストラクチャー画面の左ペインで「パブリック・ゲートウェイ」を選択し、「作成」ボタンをクリックします:

画面右からパブリック・ゲートウェイの設定画面が現れます。まずはパブリック・ゲートウェイを作成するロケーション(下の例ではアジア太平洋の東京2)を指定します:

画面を下にスクロールして設定の続きを行います。作成するパブリック・ゲートウェイの名前("kkimura-pgw")、対象となる VPC("kkimura-vpc")を指定し、最後に「作成」ボタンをクリックします:

しばらく待つとパブリック・ゲートウェイが作成されます。ただこの時点では作成されただけで、まだ対象となるプライベート・サブネットとの接続ができていない状態です:

というわけで、プライベート・サブネットとの接続を行います。対象パブリック・ゲートウェイの右(必要に応じてスクロールしてください)のメニューをクリックして「接続」を選択します:

接続するサブネットを選択します。ここでは先ほど作成した "sn-tok2" サブネットを指定しています。最後に「作成」ボタンをクリックします:

パブリック・ゲートウェイとサブネットとの接続ができました。これで対象サブネット内に作られるサーバーリソースからインターネット側へアクセスすることができるようになりました:

【Secrets Manager で証明書を管理】
この後 OpenShift クラスタをプライベート環境内に作るのですが、プライベート環境なのでそのままでは(ウェブコンソールにも oc CLI からも)アクセスできません。というわけで、プライベート環境にアクセスするための VPN をあらかじめ用意しておくことにします。
この VPN 接続をセキュアにするためには証明書が必要で、その証明書を Secrets Manager を使って管理します。したがってまず最初に Secrets Manager を(まだ使ったことがなければ)作成します。
IBM Cloud のダッシュボードから「リソースの作成」をクリックし、カタログ内の検索画面で "Secrets" と入力すると "Secrets Manager" が見つかるはずです。これを選択します:

Secrets Manager の構成画面ではまずロケーション(下の例では「東京」)を選択します。また Secrets Manager の料金プランを選択します。Secrets Manager を初めて使う場合は無料の「トライアル」プランを 30 日間だけ使うこともできます:

最後に、作成する Secrets Manager の名称(下の例では "kkimura-secrets-manager-tok2")を指定し、「以下のご使用条件を読み、同意します」にチェックを入れて「作成」します:

Secrets Manager が作成できたら VPN サービスから Secrets Manager を使うことができるよう権限を設定する必要があります。IBM Cloud の画面右上のメニューから 管理→アクセス(IAM) を選択します:

左ペインで「許可」を選択して許可の管理画面を表示してから「作成」をクリックします:

サービス許可の設定をします。ここでは以下のように指定します:
ソースアカウント:当該アカウント
ソースサービス:VPC Infrastructure Services
アクセス権限の範囲の指定:選択された属性に基づくリソース
リソースタイプにチェックして "Client VPN for VPC" を選択
(下に続く)

(上から続く)
ターゲット・サービス: Secrets Manager
アクセス権限の範囲の指定:全てのリソース
サービス・アクセス:シークレット・リーダーにチェック
最後に「作成」ボタンをクリックします:

指定した内容の許可レコードが作成されたことを確認します:

ここまで準備できたら実際に証明書を作成します。ターミナル等で以下を実行します:
作成した Secrets Manager に、作成した証明書を登録します。IBM Cloud で作成した Secrets Manager インスタンスを選択し、画面左の「シークレット」を選択し、画面右の「作成」をクリックします:

次の画面では「TLS 証明書」を選択します:

次の画面では「証明書のインポート」を選択します。また、この時点でシークレットの名称(下の例では "kkimura-vpn-certs" )を指定します:

画面を下方向に、ファイルを3つアップロードするところまでスクロールします:

3か所に、先ほど作成した証明書からそれぞれ以下のファイルを選択して指定します:
証明書: "./pki/issued/vpn-server.vpn.ibm.com.crt"
秘密鍵:"./pki/private/vpn-server.vpn.ibm.com.key"
中間証明書:"./pki/ca.crt"
最後に「作成」ボタンをクリックします:

正しく処理が行われて、新しいシークレットが作成されたことを確認します:

これで VPN 接続をセキュアに行うための証明書を作成して Secrets Manager で管理するところまでの作業が完了しました。この後はこれらの情報を使って実際に VPN 環境を構築します。
【VPN 環境の作成】
改めて IBM Cloud の VPC のプライベート環境にアクセスするための VPN 環境を作ります。IBM Cloud のカタログから "client vpn for vpc" を検索して選択します:

VPN の設定項目を指定しながら作成していきます。まず VPN タイプには「クライアントとサイト間のサーバー」を選択し、ロケーションは VPN サーバーをどのロケーションに設置するかを指定(下の例では「東京」)します:

設定を続けます。次に VPN サーバー名を適当に(下の例では "kkimura-client-vpn")入力し、接続対象となる VPC(下の例では上で作成した "kkimura-vpc")を入力します。その下のクライアント IPv4 アドレスプールには VPN 接続したマシンに割り振られる IP アドレスの範囲(下の例では 10.244.0.0/16)を指定します。ここは上で作成したサブネットと被らないアドレス帯を指定してください:

設定を続けます。VPN サーバーモードは「スタンドアロン・モード」を選択し、そのサブネットは上で作成したサブネット(下の例では "sn-tok2")を指定します:

設定を続けます。次は認証に関わる設定を行います。サーバー認証の証明書ソースは "Secrets Manager" を選択し、「インスタンスで検索」をクリックしてからサーバー・シークレット・マネージャーとサーバー SSL 証明書として先ほど作成したもの(下の例では "kkimura-secrets-manager-tok2" と "kkimura-vpn-certs")を指定します:

設定を続けます。次はクライアント認証の設定を行います。「クライアント証明書」にチェックを入れ、証明書ソースは "Secrets Manager"、「インスタンスで検索」を選んでから、上同様にクライアント・シークレット・マネージャーとクライアント SSL 証明書をそれぞれ先ほど作成したもの(下の例では "kkimura-secrets-manager-tok2" と "kkimura-vpn-certs")を指定します:

設定を続けます。次は一番下までスクロールして追加の構成部分を設定します。トランスポートプロトコルは "UDP" 、VPN ポートは 443 を指定します。またトンネルモードは「フル・トンネル」か「分割トンネル」かを選びます。クライアントがこのプライベートネットワークに VPN 接続中もインターネットの利用をさせる場合は「分割トンネル」を、VPN 接続中はインターネットアクセスを無効にさせる場合は「フルトンネル」を、それぞれ目的に応じて選択します(下の例では「分割トンネル」)。最後に「VPN サーバーの作成」ボタンをクリックして作成します:

作成して状況が「安定」になるまで少し時間がかかりますが、VPN の「クライアントとサイト間のサーバー」タブに VPN が1つ追加されたことが確認できます:

直前の設定で UDP/443 ポートを使う旨を指定しましたが、この設定内容がセキュリティグループでも許可されている必要があります。そのための設定を追加します。
VPC インフラストラクチャー画面の左ペインで「セキュリティ・グループ」を選択します。そこから今設定している VPC(下の例であれば "kkimura-vpc")のセキュリティグループになっているものを探してクリックします:

セキュリティグループの「ルール」タブを選択して、「作成」ボタンをクリックします:

新しいインバウンドルールを追加します。今回の例であればプロトコルは "UDP"、ポートは「ポート範囲」を選択した上で、最小値と最大値の両方に "443" を入力します。またソースタイプは「すべて」を選択して、最後に「作成」ボタンをクリックします:

これで新しいインバウンドルールが追加され、セキュリティグループでも UDP/443 を許可することができました:

VPN の設定項目はまだ必要なのですが、ここまでの作業ができたら一旦終わりとして、次はプライベートな OpenShift クラスタを作ります。
【プライベート OpenShift クラスタ環境の作成】
パブリックな OpenShift 環境の場合はいきなり OpenShift クラスタを作ってそのまま使い始めることができますが、プライベート環境の場合は(そのセキュリティポリシーにもよりますが)かなり準備が必要でした。が、ここまでできていればあと少しで、OpenShift クラスタを作ることもできます。
IBM Cloud のダッシュボードから「リソースの作成」を選び、カタログの検索バーに "OpenShift" と入力すると "Red Hat OpenShift on IBM Cloud" が見つかるのでこれを選択します:

作成する OpenShift クラスタの設定項目を指定していきます。まずセットアップの種類は「手動セットアップ」で、インフラストラクチャーは "VPC" を選びます。なお、この後マスターサービス・エンドポイントを指定する項目があるのですが、そこで「プライベートのみ」を選択できるのはここで "VPC" を選んだ場合のみです。つまりプライベートクラウドとしての OpenShift 環境を構築するにはここで VPC を選択する必要があり、そのためこの上で準備したような設定を行う必要があったのでした:

続けて利用する VPC("kkimura-vpc")とクラウド・オブジェクト・ストレージを指定します。クラウド・オブジェクト・ストレージを使っていない場合は新規に1つ作ってからここで指定します。また OpenShift のバージョンは特にこだわりがなければ最新版を、OCP ライセンスは「このワーカー・プールの追加ライセンスを購入する」を選択します:

ワーカー・ゾーンはワーカーノードをどのゾーンのどのサブネットに配置するかを指定します。サブネットを作成したゾーンと、そのサブネットを指定します。それ以外のゾーンのチェックを外します。またワーカープールのノード数は「2」を指定します(ここで1以下を指定すると作成前のチェックでエラーになりますが、この後の作業でワーカー・ノードは1つに変更できます)。ワーカープールのフレーバー(1台あたりのスペックは必要に応じて適宜変更してください):

マスター・サービス・エンドポイントを指定します。ここで「プライベート・エンドポイントのみ」を指定します(OpenShift を VPC で作成する場合はプライベートのみが選択できます。Classic 環境だとプライベートのみという選択肢はありません)。また適当な名称でクラスター名を指定します:

最後の統合項目ではアクティビティトラッキングやロギング、モニタリングを有効にすることも可能ですが、不要の場合はチェックを外しても問題ありません。最後に「作成」ボタンをクリックします:

これでプライベート版 OpenShift クラスタ環境のセットアップが開始されます。セットアップが完了するまでしばらく(30分ほど?)待ちます:

ステータスが「正常」になり、Ingress まで含めた全ての機能が正常に稼働している状態になることを確認します:

この状態で「OpenShift Web コンソール」ボタンをクリックしても「OpenShift Web コンソール URL に到達できませんでした」というエラーになることを確認します。この環境はプライベートネットワーク上に構築されているので、これまでのようにインターネット経由でのアクセスができないからです(つまり現時点ではアクセスできないことが正しい状態で、クラスタがプライベートネットワーク上に構築されていることを意味します):

では次にこのプライベート OpenShift クラスタにアクセスすることができるようになる VPN 環境を構築します:
【VPN サーバー環境の作成】
最後にもう一度 VPN の設定を行います。VPN の経路情報を登録します。VPC インフラストラクチャー画面の左ペインで "VPN" を選択し、「クライアントとサイト間のサーバー」タブに表示される VPN を選択します:

この VPN の「VPN サーバー経路」タブを選択して「作成」ボタンをクリックします:

まずサブネット 10.10.0.0/24 へのアクセスはそのまま通す必要があるので、CIDR に "10.10.0.0/24"、アクションは「配信」を選択して「作成」します(名前は適当に):

同様に、他のクラウドサービスへもアクセスできる必要があるため、同じ作業を繰り返して、CIDR に "166.8.0.0/14" 、アクションは「変換」でルールを1つ追加します:

下図のように VPN サーバー経路が2つ登録できていれば VPN の経路に関する設定は終わりです:

【VPN クライアント環境の作成】
VPN サーバーの準備ができたので、次に VPN クライアントを用意します。まずは VPN クライアント用のプロファイルをダウンロードします。VPN インフラストラクチャー画面の左ペインで VPN を選び、「クライアントとサイト間のサーバー」タブから先ほど作成した VPN 接続を選択します:

そして「クライアント」タブ内の「クライアント・プロファイルのダウンロード」を選択します。すると .ovpn という拡張子がついた Open VPN 向けプロファイルがダウンロードできます:

自分が付けた VPN 名(この例では "kkimura-client-vpn")に ".ovpn" という拡張子が付いたファイル名のプロファイルがダウンロードされているはずです。このファイルをテキストエディタで開きます:

ファイルの最後に近いあたりにある "#cert " で始まる行と、"#key " で始まる行両方の "#" を削除します。加えて "cert", "key" に続く文字列を以下のように変更して保存します:
cert client1.vpn.ibm.com.crt
key client1.vpn.ibm.com.key

そして証明書ファイルを作った際の ./pki/issued/client1.vpn.ibm.com.crt および ./pki/private/client1.vpn.ibm.com.key の2つのファイルを OVPN ファイルを同じフォルダにコピーします:

これで VPN 接続用プロファイルが準備できました。後は VPN クライアントを用意して、このプロファイルを適用するだけです。
VPN クライアントは(2023/01/04 時点では)OpenVPN クライアントの V2 および V3 が推奨されています。今回はこちらから OpenVPN V3 をダウンロード&インストールしました。自分のシステム環境プラットフォームにあったものを選んでダウンロードしてください:
https://openvpn.net/vpn-client/#tab-windows
OpenVPN クライアントのインストールが環境したら起動します。初回起動時にプロファイルのインポート画面になるので、FILE タブを選んで"BROWSE" ボタンをクリックし、上で用意した OVPN ファイル(kkimura-client-vpn.ovpn)を指定します:

OVPN ファイルが正しく作成され、また正しく編集できていれば鍵ファイルごと読み込まれてプロファイルのインポートが完了します。ここで "CONNECT" ボタンを押すと VPN 接続が開始します:

設定にミスがなければ VPN 接続は一瞬で完了するはずです。"CONNECTED" と表示されていれば接続できていることになります:

試しにこの VPN 接続ができている間を使ってプライベート OpenShift クラスタが正しく作られていることを確認してみます。IBM Cloud のダッシュボード画面に戻り、作成した OpenShift クラスタを選択して「OpenShift Web コンソール」ボタンをクリックしてみます(先ほどはエラーになったオペレーションです):

今回は OpenShift のウェブコンソール画面が表示されるはずです。VPN 接続が有効になっているので、この URL にアクセスすることができました。なお IBM Cloud の OpenShift では URL のリージョン部分(例えば "jp-tok")の直前が "0000" であればパブリック、"i000" であればプライベートな URL になっているとのことで、今回は "****-i000-jp-tok.***" というパターンになっているので、ここでもプライベートな URL にアクセスできていることが確認できます:

ついでに今回は「プライベートクラウド側からインターネット側へのアクセスは許可」するポリシーで環境を構築しました。上述のパブリックゲートウェイが有効になっているので、プライベートクラウド側から Docker ハブ等にもアクセスできるはずなので、それを確認してみます。まずはパースペクティブを切り替えるため、画面左の "Administrator" と書かれた部分をクリックして "Developer" に変更します:

Developer パースペクティブの状態で「+追加」をクリックし、プロジェクト(例えば "default")を選択してから「コンテナイメージ」を選択します(新しいアプリケーションをコンテナイメージから作る、という指示を意味しています):

今回動作検証用に使うアプリケーションのイメージはこれを使うことにします。私が作って Docker ハブで公開しているもので、HTTP でアクセスすると /etc/hostname の内容を読み取って text/plain で返す、というシンプルなアプリケーションです。イメージ名は dotnsf/hostname です:

このイメージを指定します。OpenShift の画面には docker.io/dotnsf/hostname と入力します(Docker ハブ上の dotnsf/hostname という指定です)。入力後に「検証済み」と表示されるまで少し待ちます:

これ以外のオプションは特に変更の必要はありませんが、名称などはお好きなように指定してください。ただ「生成するリソースタイプの選択」は「デプロイメント」を指定するようにしてください。最後に「作成」ボタンをクリックします:

少し時間がかかりますが、以下のような画面が表示されればデプロイ完了です。アイコン右上のリンクボタンをクリックして動作確認してます:

別のウィンドウタブが開いて、プライベート OpenShift 上にデプロイされた dotnsf/hostname アプリにアクセスできることを確認します。またこの URL パターンが "***.i000-jp-tok***" となっていて、プライベート OpenShift のパターンになっていることも合わせて確認します:

無事にプライベート OpenShift 環境を構築することができました。VPN 接続を切る場合、Windows であればタスクバーなどから OpenVPN クライアントを選択して disconnect することもできます:

これまで IBM Cloud で OpenShift クラスタ環境を何度も作って(&そして削除して)来ました。が、それらは全てパブリッククラウド環境としての OpenShift クラスタでした。 このたびプライベートクラウド環境としての OpenShift クラスタを作る機会がありました。その考慮点や手順がパブリッククラウドの時と比べてかなり複雑だったので、備忘録の意味も含めて最初から最後まで手順をまとめてみました。
【プライベートクラウドの設計】
一言で「プライベートクラウド」といっても、その制約というか仕様には色々なパターンが考えられます。例えば「プライベートクラウド」なので、ウェブの管理コンソールや管理 CLI の操作、クラスタにデプロイしたアプリケーションにインターネットからアクセスできない(インターネット側からプライベートクラウドへのアクセスは不可とする)、というのは共通仕様だと思っています。一方で、デプロイするアプリケーションのイメージは Docker ハブから使いたい(つまりプライベートクラウド側からインターネットへのアクセスは許可したい)というケースはあるかもしれませんし、そこも制約として許可したくないケースもあると思います(後者の場合でイメージからデプロイするにはイメージリポジトリもプライベートクラウド内に構築する必要も出てきます)。
以下で手順を紹介するのは「前者」のパターンとします。つまり、
・CLI やウェブコンソールを含めて、インターネットからの直接アクセスは許可しない
・専用の VPN 環境を構築し、この VPN 接続が有効な場合のみアクセスを許可する
・プライベートクラウド側からインターネットへのアクセスは許可する(Docker ハブなどからのアプリケーションデプロイを可能とする)
という条件でプライベートクラウド環境を構築します。なお以下の作業を行う上で必要なユーザー権限は全て取得済みであるものとします。
【VPC とサブネットの作成】
まず、今回のようなパブリックインターフェースを持たないプライベートインターフェースのみの OpenShift クラスタを IBM Cloud に作る場合、クラシックインフラではなく VPC(Virtual Private Cloud)インフラに作る必要があります。そのためまずは OpenShift クラスタを作成するための VPC(Virtual Private Cloud:仮想プライベートクラウド)環境を作成します。IBM Cloud のダッシュボードから「リソースの作成」をクリックします:

カタログ画面の検索バーに "Virtual Private" と入力すると選択候補の中に "Virtual Private Cloud" というのが出てくると思うので、これを選択します:

VPC 環境を作成するロケーションを選択します。以下の例では「アジア太平洋地域」の「東京」を選択しています。ここは自分の環境にあったもの(なるべく利用者に近い場所)を選択してください。そして VPC の名称(下の例では "kkimura-vpc")を入力します:

下にスクロールするとデフォルト接頭部とサブネットに関する情報が表示されます。デフォルトでは選択したロケーション(この場合は東京)の3つのゾーンに1つずつサブネットが用意されます。このままでもよければこのまま進めることもできますが、今回は規模の小さいプライベートクラウド環境を作る想定なので、デフォルト設定を無効にした上でサブネットを1つだけ用意することにします:

というわけで、「各ゾーンのデフォルト接頭部の作成」のチェックを外してください。最後に「仮想プライベート・クラウドの作成」ボタンをクリックします:

仮想プライベート・クラウドの一覧画面に遷移し、先ほど指定した名前の VPC が追加されたことを確認し、これを選択します:

VPC の中身を確認するとアドレス接頭部が空になっています。ここに1つだけ追加することにします:

同じ画面の「アドレス接頭部」タブを選択して「作成」ボタンをクリックします:

画面右から「アドレス接頭部の作成」というウィンドウが表示されます。ここに作成するアドレス空間の範囲(下の例では 10.10.0.0/18)と、そのアドレス空間を作るロケーション(下の例では東京2)を指定して「作成」ボタンをクリックします:

指定した値(10.10.0.0/18)のアドレス空間が定義できました:

アドレス空間が定義できたので、次にサブネットを作成します。画面左ペインから「サブネット」を選択し、「作成」ボタンをクリックします:

ロケーション(下の例ではアジア太平洋の東京2)とサブネットの名称(下の例では "sn-tok2")を指定します。まだ入力項目があるので、そのまま下にスクロールします:

このサブネットを使う VPC を指定し、最後にアドレス接頭部(10.10.0.0/18)内のどの部分をサブネットとして利用するかを指定します(下の例では "10.10.0.0/24" を指定しています)。ここまで指定できたら最後に「サブネットの作成」ボタンをクリックします:

VPC 用のサブネットを新しく1つ定義できました。この後 OpenShift 環境を構築する場合に、このサブネット上に構築することになります:

【パブリックゲートウェイの作成】
今回のプライベートクラウドでは「プライベート環境側からインターネット側へのアクセスは許可する」前提で環境を構築します。これを実現するには「パブリックゲートウェイ」と呼ばれるゲートウェイをサブネットに紐づけることで実現します。 以下ではその手順を紹介します。なお「プライベート環境側からインターネット側へのアクセスも禁止する」というポリシーで構築する場合は、このパブリックゲートウェイ作成手順は読み飛ばしてください。
VPC インフラストラクチャー画面の左ペインで「パブリック・ゲートウェイ」を選択し、「作成」ボタンをクリックします:

画面右からパブリック・ゲートウェイの設定画面が現れます。まずはパブリック・ゲートウェイを作成するロケーション(下の例ではアジア太平洋の東京2)を指定します:

画面を下にスクロールして設定の続きを行います。作成するパブリック・ゲートウェイの名前("kkimura-pgw")、対象となる VPC("kkimura-vpc")を指定し、最後に「作成」ボタンをクリックします:

しばらく待つとパブリック・ゲートウェイが作成されます。ただこの時点では作成されただけで、まだ対象となるプライベート・サブネットとの接続ができていない状態です:

というわけで、プライベート・サブネットとの接続を行います。対象パブリック・ゲートウェイの右(必要に応じてスクロールしてください)のメニューをクリックして「接続」を選択します:

接続するサブネットを選択します。ここでは先ほど作成した "sn-tok2" サブネットを指定しています。最後に「作成」ボタンをクリックします:

パブリック・ゲートウェイとサブネットとの接続ができました。これで対象サブネット内に作られるサーバーリソースからインターネット側へアクセスすることができるようになりました:

【Secrets Manager で証明書を管理】
この後 OpenShift クラスタをプライベート環境内に作るのですが、プライベート環境なのでそのままでは(ウェブコンソールにも oc CLI からも)アクセスできません。というわけで、プライベート環境にアクセスするための VPN をあらかじめ用意しておくことにします。
この VPN 接続をセキュアにするためには証明書が必要で、その証明書を Secrets Manager を使って管理します。したがってまず最初に Secrets Manager を(まだ使ったことがなければ)作成します。
IBM Cloud のダッシュボードから「リソースの作成」をクリックし、カタログ内の検索画面で "Secrets" と入力すると "Secrets Manager" が見つかるはずです。これを選択します:

Secrets Manager の構成画面ではまずロケーション(下の例では「東京」)を選択します。また Secrets Manager の料金プランを選択します。Secrets Manager を初めて使う場合は無料の「トライアル」プランを 30 日間だけ使うこともできます:

最後に、作成する Secrets Manager の名称(下の例では "kkimura-secrets-manager-tok2")を指定し、「以下のご使用条件を読み、同意します」にチェックを入れて「作成」します:

Secrets Manager が作成できたら VPN サービスから Secrets Manager を使うことができるよう権限を設定する必要があります。IBM Cloud の画面右上のメニューから 管理→アクセス(IAM) を選択します:

左ペインで「許可」を選択して許可の管理画面を表示してから「作成」をクリックします:

サービス許可の設定をします。ここでは以下のように指定します:
ソースアカウント:当該アカウント
ソースサービス:VPC Infrastructure Services
アクセス権限の範囲の指定:選択された属性に基づくリソース
リソースタイプにチェックして "Client VPN for VPC" を選択
(下に続く)

(上から続く)
ターゲット・サービス: Secrets Manager
アクセス権限の範囲の指定:全てのリソース
サービス・アクセス:シークレット・リーダーにチェック
最後に「作成」ボタンをクリックします:

指定した内容の許可レコードが作成されたことを確認します:

ここまで準備できたら実際に証明書を作成します。ターミナル等で以下を実行します:
Easy-RSA 3 リポジトリをローカルフォルダに複製
$ git clone https://github.com/OpenVPN/easy-rsa.git $ cd easy-rsa/easyrsa3
新しい PKI と CA を作成
$ ./easyrsa init-pki $ ./easyrsa build-ca nopass
VPN サーバー証明書(vpn-server.vpn.ibm.com)を生成
$ ./easyrsa build-server-full vpn-server.vpn.ibm.com nopass (プロンプトが止まったら "yes" と入力)
VPN クライアント証明書(client1.vpn.ibm.com)を生成
$ ./easyrsa build-client-full client1.vpn.ibm.com nopass (プロンプトが止まったら "yes" と入力)
証明書ファイルの取り出し
./pki/ 以下をまとめて取り出しておく
作成した Secrets Manager に、作成した証明書を登録します。IBM Cloud で作成した Secrets Manager インスタンスを選択し、画面左の「シークレット」を選択し、画面右の「作成」をクリックします:

次の画面では「TLS 証明書」を選択します:

次の画面では「証明書のインポート」を選択します。また、この時点でシークレットの名称(下の例では "kkimura-vpn-certs" )を指定します:

画面を下方向に、ファイルを3つアップロードするところまでスクロールします:

3か所に、先ほど作成した証明書からそれぞれ以下のファイルを選択して指定します:
証明書: "./pki/issued/vpn-server.vpn.ibm.com.crt"
秘密鍵:"./pki/private/vpn-server.vpn.ibm.com.key"
中間証明書:"./pki/ca.crt"
最後に「作成」ボタンをクリックします:

正しく処理が行われて、新しいシークレットが作成されたことを確認します:

これで VPN 接続をセキュアに行うための証明書を作成して Secrets Manager で管理するところまでの作業が完了しました。この後はこれらの情報を使って実際に VPN 環境を構築します。
【VPN 環境の作成】
改めて IBM Cloud の VPC のプライベート環境にアクセスするための VPN 環境を作ります。IBM Cloud のカタログから "client vpn for vpc" を検索して選択します:

VPN の設定項目を指定しながら作成していきます。まず VPN タイプには「クライアントとサイト間のサーバー」を選択し、ロケーションは VPN サーバーをどのロケーションに設置するかを指定(下の例では「東京」)します:

設定を続けます。次に VPN サーバー名を適当に(下の例では "kkimura-client-vpn")入力し、接続対象となる VPC(下の例では上で作成した "kkimura-vpc")を入力します。その下のクライアント IPv4 アドレスプールには VPN 接続したマシンに割り振られる IP アドレスの範囲(下の例では 10.244.0.0/16)を指定します。ここは上で作成したサブネットと被らないアドレス帯を指定してください:

設定を続けます。VPN サーバーモードは「スタンドアロン・モード」を選択し、そのサブネットは上で作成したサブネット(下の例では "sn-tok2")を指定します:

設定を続けます。次は認証に関わる設定を行います。サーバー認証の証明書ソースは "Secrets Manager" を選択し、「インスタンスで検索」をクリックしてからサーバー・シークレット・マネージャーとサーバー SSL 証明書として先ほど作成したもの(下の例では "kkimura-secrets-manager-tok2" と "kkimura-vpn-certs")を指定します:

設定を続けます。次はクライアント認証の設定を行います。「クライアント証明書」にチェックを入れ、証明書ソースは "Secrets Manager"、「インスタンスで検索」を選んでから、上同様にクライアント・シークレット・マネージャーとクライアント SSL 証明書をそれぞれ先ほど作成したもの(下の例では "kkimura-secrets-manager-tok2" と "kkimura-vpn-certs")を指定します:

設定を続けます。次は一番下までスクロールして追加の構成部分を設定します。トランスポートプロトコルは "UDP" 、VPN ポートは 443 を指定します。またトンネルモードは「フル・トンネル」か「分割トンネル」かを選びます。クライアントがこのプライベートネットワークに VPN 接続中もインターネットの利用をさせる場合は「分割トンネル」を、VPN 接続中はインターネットアクセスを無効にさせる場合は「フルトンネル」を、それぞれ目的に応じて選択します(下の例では「分割トンネル」)。最後に「VPN サーバーの作成」ボタンをクリックして作成します:

作成して状況が「安定」になるまで少し時間がかかりますが、VPN の「クライアントとサイト間のサーバー」タブに VPN が1つ追加されたことが確認できます:

直前の設定で UDP/443 ポートを使う旨を指定しましたが、この設定内容がセキュリティグループでも許可されている必要があります。そのための設定を追加します。
VPC インフラストラクチャー画面の左ペインで「セキュリティ・グループ」を選択します。そこから今設定している VPC(下の例であれば "kkimura-vpc")のセキュリティグループになっているものを探してクリックします:

セキュリティグループの「ルール」タブを選択して、「作成」ボタンをクリックします:

新しいインバウンドルールを追加します。今回の例であればプロトコルは "UDP"、ポートは「ポート範囲」を選択した上で、最小値と最大値の両方に "443" を入力します。またソースタイプは「すべて」を選択して、最後に「作成」ボタンをクリックします:

これで新しいインバウンドルールが追加され、セキュリティグループでも UDP/443 を許可することができました:

VPN の設定項目はまだ必要なのですが、ここまでの作業ができたら一旦終わりとして、次はプライベートな OpenShift クラスタを作ります。
【プライベート OpenShift クラスタ環境の作成】
パブリックな OpenShift 環境の場合はいきなり OpenShift クラスタを作ってそのまま使い始めることができますが、プライベート環境の場合は(そのセキュリティポリシーにもよりますが)かなり準備が必要でした。が、ここまでできていればあと少しで、OpenShift クラスタを作ることもできます。
IBM Cloud のダッシュボードから「リソースの作成」を選び、カタログの検索バーに "OpenShift" と入力すると "Red Hat OpenShift on IBM Cloud" が見つかるのでこれを選択します:

作成する OpenShift クラスタの設定項目を指定していきます。まずセットアップの種類は「手動セットアップ」で、インフラストラクチャーは "VPC" を選びます。なお、この後マスターサービス・エンドポイントを指定する項目があるのですが、そこで「プライベートのみ」を選択できるのはここで "VPC" を選んだ場合のみです。つまりプライベートクラウドとしての OpenShift 環境を構築するにはここで VPC を選択する必要があり、そのためこの上で準備したような設定を行う必要があったのでした:

続けて利用する VPC("kkimura-vpc")とクラウド・オブジェクト・ストレージを指定します。クラウド・オブジェクト・ストレージを使っていない場合は新規に1つ作ってからここで指定します。また OpenShift のバージョンは特にこだわりがなければ最新版を、OCP ライセンスは「このワーカー・プールの追加ライセンスを購入する」を選択します:

ワーカー・ゾーンはワーカーノードをどのゾーンのどのサブネットに配置するかを指定します。サブネットを作成したゾーンと、そのサブネットを指定します。それ以外のゾーンのチェックを外します。またワーカープールのノード数は「2」を指定します(ここで1以下を指定すると作成前のチェックでエラーになりますが、この後の作業でワーカー・ノードは1つに変更できます)。ワーカープールのフレーバー(1台あたりのスペックは必要に応じて適宜変更してください):

マスター・サービス・エンドポイントを指定します。ここで「プライベート・エンドポイントのみ」を指定します(OpenShift を VPC で作成する場合はプライベートのみが選択できます。Classic 環境だとプライベートのみという選択肢はありません)。また適当な名称でクラスター名を指定します:

最後の統合項目ではアクティビティトラッキングやロギング、モニタリングを有効にすることも可能ですが、不要の場合はチェックを外しても問題ありません。最後に「作成」ボタンをクリックします:

これでプライベート版 OpenShift クラスタ環境のセットアップが開始されます。セットアップが完了するまでしばらく(30分ほど?)待ちます:

ステータスが「正常」になり、Ingress まで含めた全ての機能が正常に稼働している状態になることを確認します:

この状態で「OpenShift Web コンソール」ボタンをクリックしても「OpenShift Web コンソール URL に到達できませんでした」というエラーになることを確認します。この環境はプライベートネットワーク上に構築されているので、これまでのようにインターネット経由でのアクセスができないからです(つまり現時点ではアクセスできないことが正しい状態で、クラスタがプライベートネットワーク上に構築されていることを意味します):

では次にこのプライベート OpenShift クラスタにアクセスすることができるようになる VPN 環境を構築します:
【VPN サーバー環境の作成】
最後にもう一度 VPN の設定を行います。VPN の経路情報を登録します。VPC インフラストラクチャー画面の左ペインで "VPN" を選択し、「クライアントとサイト間のサーバー」タブに表示される VPN を選択します:

この VPN の「VPN サーバー経路」タブを選択して「作成」ボタンをクリックします:

まずサブネット 10.10.0.0/24 へのアクセスはそのまま通す必要があるので、CIDR に "10.10.0.0/24"、アクションは「配信」を選択して「作成」します(名前は適当に):

同様に、他のクラウドサービスへもアクセスできる必要があるため、同じ作業を繰り返して、CIDR に "166.8.0.0/14" 、アクションは「変換」でルールを1つ追加します:

下図のように VPN サーバー経路が2つ登録できていれば VPN の経路に関する設定は終わりです:

【VPN クライアント環境の作成】
VPN サーバーの準備ができたので、次に VPN クライアントを用意します。まずは VPN クライアント用のプロファイルをダウンロードします。VPN インフラストラクチャー画面の左ペインで VPN を選び、「クライアントとサイト間のサーバー」タブから先ほど作成した VPN 接続を選択します:

そして「クライアント」タブ内の「クライアント・プロファイルのダウンロード」を選択します。すると .ovpn という拡張子がついた Open VPN 向けプロファイルがダウンロードできます:

自分が付けた VPN 名(この例では "kkimura-client-vpn")に ".ovpn" という拡張子が付いたファイル名のプロファイルがダウンロードされているはずです。このファイルをテキストエディタで開きます:

ファイルの最後に近いあたりにある "#cert " で始まる行と、"#key " で始まる行両方の "#" を削除します。加えて "cert", "key" に続く文字列を以下のように変更して保存します:
cert client1.vpn.ibm.com.crt
key client1.vpn.ibm.com.key

そして証明書ファイルを作った際の ./pki/issued/client1.vpn.ibm.com.crt および ./pki/private/client1.vpn.ibm.com.key の2つのファイルを OVPN ファイルを同じフォルダにコピーします:

これで VPN 接続用プロファイルが準備できました。後は VPN クライアントを用意して、このプロファイルを適用するだけです。
VPN クライアントは(2023/01/04 時点では)OpenVPN クライアントの V2 および V3 が推奨されています。今回はこちらから OpenVPN V3 をダウンロード&インストールしました。自分のシステム環境プラットフォームにあったものを選んでダウンロードしてください:
https://openvpn.net/vpn-client/#tab-windows
OpenVPN クライアントのインストールが環境したら起動します。初回起動時にプロファイルのインポート画面になるので、FILE タブを選んで"BROWSE" ボタンをクリックし、上で用意した OVPN ファイル(kkimura-client-vpn.ovpn)を指定します:

OVPN ファイルが正しく作成され、また正しく編集できていれば鍵ファイルごと読み込まれてプロファイルのインポートが完了します。ここで "CONNECT" ボタンを押すと VPN 接続が開始します:

設定にミスがなければ VPN 接続は一瞬で完了するはずです。"CONNECTED" と表示されていれば接続できていることになります:

試しにこの VPN 接続ができている間を使ってプライベート OpenShift クラスタが正しく作られていることを確認してみます。IBM Cloud のダッシュボード画面に戻り、作成した OpenShift クラスタを選択して「OpenShift Web コンソール」ボタンをクリックしてみます(先ほどはエラーになったオペレーションです):

今回は OpenShift のウェブコンソール画面が表示されるはずです。VPN 接続が有効になっているので、この URL にアクセスすることができました。なお IBM Cloud の OpenShift では URL のリージョン部分(例えば "jp-tok")の直前が "0000" であればパブリック、"i000" であればプライベートな URL になっているとのことで、今回は "****-i000-jp-tok.***" というパターンになっているので、ここでもプライベートな URL にアクセスできていることが確認できます:

ついでに今回は「プライベートクラウド側からインターネット側へのアクセスは許可」するポリシーで環境を構築しました。上述のパブリックゲートウェイが有効になっているので、プライベートクラウド側から Docker ハブ等にもアクセスできるはずなので、それを確認してみます。まずはパースペクティブを切り替えるため、画面左の "Administrator" と書かれた部分をクリックして "Developer" に変更します:

Developer パースペクティブの状態で「+追加」をクリックし、プロジェクト(例えば "default")を選択してから「コンテナイメージ」を選択します(新しいアプリケーションをコンテナイメージから作る、という指示を意味しています):

今回動作検証用に使うアプリケーションのイメージはこれを使うことにします。私が作って Docker ハブで公開しているもので、HTTP でアクセスすると /etc/hostname の内容を読み取って text/plain で返す、というシンプルなアプリケーションです。イメージ名は dotnsf/hostname です:

このイメージを指定します。OpenShift の画面には docker.io/dotnsf/hostname と入力します(Docker ハブ上の dotnsf/hostname という指定です)。入力後に「検証済み」と表示されるまで少し待ちます:

これ以外のオプションは特に変更の必要はありませんが、名称などはお好きなように指定してください。ただ「生成するリソースタイプの選択」は「デプロイメント」を指定するようにしてください。最後に「作成」ボタンをクリックします:

少し時間がかかりますが、以下のような画面が表示されればデプロイ完了です。アイコン右上のリンクボタンをクリックして動作確認してます:

別のウィンドウタブが開いて、プライベート OpenShift 上にデプロイされた dotnsf/hostname アプリにアクセスできることを確認します。またこの URL パターンが "***.i000-jp-tok***" となっていて、プライベート OpenShift のパターンになっていることも合わせて確認します:

無事にプライベート OpenShift 環境を構築することができました。VPN 接続を切る場合、Windows であればタスクバーなどから OpenVPN クライアントを選択して disconnect することもできます:

コメント
コメント一覧 (1)
日本存亡に関わる台湾有事危機が高まる中、
敵国が望む改憲阻止の為、中韓と連携し野党メディアが倒閣へ扇動をかける状況にどうか気付いて頂きたいです(09年は扇動が成功)
国防妨害一色の、メディアが全力で守る野党は、北と韓国政府から資金投入の朝鮮総連、殺人の革マル等反社勢との連携、大炎上中のcolabo等は一切報じぬ裏で、
中朝は核の標準を日本に向け、侵略虐殺を拡げる現在、日本の尖閣に侵犯を激化する中、改憲せず攻撃力を持たずの現防衛力では、
多くの日本人を銃殺した韓国の竹島不法占拠、北の日本人拉致、中国の尖閣侵犯にも、9条により日本は国を守る為の手出しが何一つ出来ない事が示しています。
中韓の間接侵略は、野党が法制化を目指す外国人参政権や日本人のみ弾圧対象ヘイトスピーチ法、維新道州制等、多様性と言う"中韓の声反映"に進んでおり、
野党メディアが09年再現へ世論誘導をかける今、中韓浸透工作は最終段階である事、
日本でウクライナの悲劇を生まぬ為、一人でも多くの方に目覚めて頂きたいと切に思い貼らせて頂きます。
https://pachitou.com/2021/10/29
長文、大変申し訳ありません。