⌛
【GKE】 限定公開クラスタ(プライベートクラスタ)について調べたまとめ
こんな人向け
- 限定公開クラスタ(プライベートクラスタ)ってなに?
- GKEのネットワークまわりのセキュリティー強化したい
GKEのアーキテクチャ
GKEは主に以下のふたつから成り立っています
- コントロールプレーン
- クラスタの統合エンドポイント
- kubectlコマンド使った時にアクセスしている場所
- クラスタに対する操作は全てこのコントロールプレーンを通じて行われる
- デフォルトでは公開設定されているのでインターネット上のどこからでもアクセス可能
- Googleが所有するプロジェクトのVPCネットワーク内のVM上で動作している
- ノード
- コンテナ化されたアプリケーションや他のワークロードを実行するワーカーマシン
- 個々のマシンはVMインスタンス
- GKEが自動で作成してくれる
- https://cloud.google.com/kubernetes-engine/docs/concepts/cluster-architecture?hl=ja#nodes
- デフォルトでは、個々のVMインスタンスに外部IPアドレスが割り振られるので、外部のインターネットとルーティング可能な経路があるということ
こんなイメージです
ネットワークのアクセスを制限したい
デフォルトの設定だと、コントロールプレーンへのネットワークアクセスと、各ノードへのネットワークアクセスの制限は一切ない状態になってしまっています。
セキュリティーを強化するために、この2つへのネットワークアクセスを制限したいですよね。
そんな時に限定公開クラスタを使いましょうという話です。
限定公開クラスタを作成する方法
限定公開クラスタを作成するには「Private Clustrer」オプションを選択するだけでOKです。
限定公開クラスタにすると、なにが変わる?
GKEのアーキテクチャで説明した「ノード」に使われるVMインスタンスに外部IPアドレスが割り振られなくなります。
なので、個々のVMインスタンスに外部のネットワークからアクセスする経路がなくなるので、よりセキュアになります。
また、GCPの外部IPアドレスは2020年1月から利用料金が必要になり、IPアドレス一つあたり$2.88/月かかる(プリエンプティブなインスタンスだと半額)ので、多少なりとも料金がお得になるというメリットもあります。
外部のネットワークから限定公開クラスタにデプロイしたサービスにアクセスしたい
通常のクラスタと同様の方法で可能です。
- LoadBalancerタイプのServiceを作成し、外部クライアントがロードバランサのIPアドレスを呼び出す
- NodePortタイプのServiceとIngressを作成し、外部クライアントがロードバランサのIPアドレスを呼び出す
限定公開クラスタのノードから外部のネットワークにアクセスしたい
Cloud NAT を使用するか、独自のNAT ゲートウェイを使用すればOKです。
コントロールプレーンへのアクセス制限したい
コントロールプレーンをインターネットアクセス制限する方法は2パターンあります。
- enable_private_endpointというオプションを指定し、全ての外部ネットワークからのアクセスを拒否する
- クラスタと同じサブネット内のクラスタノードまたはVMからのみアクセスが許可される
- それ以外の内部IPアドレスから接続したい場合は、マスター承認済みネットワークに接続元IPアドレスを設定する必要がある
- 内部IPアドレスからアクセスする必要があるので、踏み台サーバーが必要になる
- enable_private_endpointというオプションは指定しないで、enable_master_authorized_networksというオプションを指定する。
- アクセスを許可するIPアドレス範囲をマスター承認済みネットワークに設定できる
限定公開クラスタの制約と制限
- 制約
- すでに作成されている限定公開クラスタではないクラスタを限定公開クラスタにすることはできない
- マスター承認済みネットワークの設定数に上限がある
- 制限
- 限定公開クラスタはクラスタ毎にVPCネットワークピアリングが必要になる(コントロールプレーンからノードへアクセスするために)
- VPCネットワークには最大25個のVPCネットワークとピアリングを作成可能
- 限定公開クラスタはクラスタ毎にVPCネットワークピアリングが必要になる(コントロールプレーンからノードへアクセスするために)
※その他にも制約と制限あるので公式ドキュメントを参照してください
所感
- これからGKEクラスタ作る人は限定公開クラスタを使いましょう
- すでにGKEクラスタ使ってる人も限定公開クラスタに移行しましょう
- 社内ネットワークからのみ作業する環境では、コントロールプレーンを全ての外部ネットワークからのアクセス制限かけるのがよい
- 外部のネットワークから作業する人がいる環境では、マスター承認済みネットワークに社内VPNの外部IPアドレスを登録するのが無難かな
- 外部のネットワークから作業する人がいる環境では、コントロールプレーンを外部のネットワークからアクセス制限すると、踏み台サーバー踏まないとkubectlコマンドを実行できなくなるので、デプロイや調査が面倒になる。
- CIをVPC内に用意してあげればCIから問題なくkubectlはたたけるが、マネージドのCIサービスは使えなっちゃう
- CloudBuildって特定のネットワーク内で実行できるのだろうか?
- GitOpsとCDでいい感じにすれば、デプロイでkubectlコマンド使わなくてすむので、可能ならばそうすべきなのかも
- そもそもkubectlでデプロイってのがイケてない
- 調査だけなら踏み台サーバー踏んだところで手間はそんなにかわらないけど、ユーザーごとにkubernetesのリソースへのアクセス制限させるのがちょっとめんどくさそう
- 踏み台サーバーにSSHしてからglcoud auth loginしてもらうか、踏み台サーバーを複数たてて権限わけるとかか?
最後に
筆者もkubernetesを使ってはいますが、情報が間違ってる場合や、古くなっている場合がありますので、最新で正確な情報が知りたい場合は公式ドキュメントを参考にしてください。
また、間違っていたり古くなっている場合はコメントくださるとめちゃめちゃ嬉しいです!
Discussion