説明
GKE ノードとコントロールプレーンの公開アクセスは、別々に管理する必要があります。プライベートノードは外部 IP なしで動作しますが、それだけでコントロールプレーンの外部 IP エンドポイントも無効になるわけではありません。必要な公開経路を確認し、ネットワーク制限と IAM・Kubernetes RBAC の権限を組み合わせてください。
想定される影響
- 到達可能な公開経路と広いファイアウォール許可があると、ノード上のサービスに不要な接続が試みられる可能性があります。
- コントロールプレーンへのアクセス範囲が広く、認証情報や権限が悪用されると、ワークロードやクラスタ設定が変更されるおそれがあります。公開エンドポイント自体が認証をなくすわけではありません。
対処方法
- 内部用ワークロードにはプライベートノードを使用し、必要な外向き通信と管理経路を用意してください。
- コントロールプレーンの IP エンドポイントと DNS エンドポイントを別々に確認してください。外部 IP エンドポイントを無効にするか管理元を限定し、DNS アクセスにも適切な IAM とネットワーク制御を適用してください。
- 対応する GKE の管理手順で設定を変更し、運用者、自動化処理、ノードからの接続をテストしてください。強固な認証と最小権限の RBAC を維持してください。
例
新規クラスタの設定を比較する抜粋です。バージョンに合う VPC、サブネット、IP 割り当て、必要なコントロールプレーン CIDR、プロジェクト、認証情報は別途設定してください。現在の GKE がサポートしない基本ユーザー名・パスワード認証は含めていません。
変更前
yaml
- name: create a cluster1
google.cloud.gcp_container_cluster:
name: my-cluster1
initial_node_count: 2
node_config:
machine_type: n1-standard-4
disk_size_gb: 500
location: us-central1-a
project: "{{ project_id }}"
auth_kind: serviceaccount
service_account_file: "/tmp/auth.pem"
state: present
- name: create a cluster4
google.cloud.gcp_container_cluster:
name: my-cluster4
initial_node_count: 2
node_config:
machine_type: n1-standard-4
disk_size_gb: 500
location: us-central1-a
project: "{{ project_id }}"
auth_kind: serviceaccount
service_account_file: "/tmp/auth.pem"
state: present
private_cluster_config:
enable_private_endpoint: no
enable_private_nodes: yes
最初の設定はプライベートネットワークを明示していません。二つ目はプライベートノードを使用しますが、外部 IP エンドポイントは無効にしていません。
変更後
yaml
- name: create a cluster
google.cloud.gcp_container_cluster:
name: my-cluster
initial_node_count: 2
node_config:
machine_type: n1-standard-4
disk_size_gb: 500
location: us-central1-a
project: "{{ project_id }}"
auth_kind: serviceaccount
service_account_file: /tmp/auth.pem
state: present
private_cluster_config:
enable_private_endpoint: yes
enable_private_nodes: yes
enable_private_nodes と enable_private_endpoint を両方設定しています。DNS エンドポイントへのアクセスは別途確認してください。名前の異なる新規クラスタの例であり、既存クラスタの変更やワークロード移行の手順を代替するものではありません。