固定 IP アドレスを使用するように LoadBalancer タイプの Kubernetes サービスを構成できます。この機能を実装する場合は、コンポーネントの最小要件、セキュリティに関する重要な考慮事項、およびクラスタのセキュリティ強化に関するガイダンスに注意してください。

LoadBalancer タイプのサービスにおける固定 IP アドレスの使用

通常、LoadBalancer タイプの Kubernetes サービスを定義すると、ロード バランサによって IP アドレスが一時的に割り当てられます。

ロード バランサの固定 IP アドレスを指定することもできます。サービスの作成時に、割り当てられた固定 IP アドレスを使用してロード バランサのインスタンスがプロビジョニングされます。

次のサービスの例では、固定 IP アドレスを使用してサポート対象のロード バランサを構成する方法を示します。サービス仕様に loadBalancerIP パラメータと IP アドレス値を含めます。この例では、IP アドレスは 10.11.12.49 です。 
kind: Service
apiVersion: v1
metadata:
  name: load-balancer-service-with-static-ip
spec:
  selector:
    app: hello-world
    tier: frontend
  ports:
  - protocol: "TCP"
    port: 80
    targetPort: 80
  type: LoadBalancer
  loadBalancerIP: 10.11.12.49

NSX Advanced Load Balancer の場合は、ロード バランサのインストール時に構成された IP アドレス管理プール内の IP アドレスを使用します。サービスが作成され、固定 IP アドレスが割り当てられると、ロード バランサは割り当て済みとマークし、一時的な IP アドレスと同じように IP アドレスのライフサイクルを管理します。つまり、サービスが削除されると、IP アドレスは割り当て解除され、再割り当てが可能になります。

NSX-T ロード バランサの場合は、2 つのオプションがあります。デフォルトのメカニズムは、NSX Advanced Load Balancer と同じように、ロード バランサのインストール時に構成された IP アドレス プールから取得された IP アドレスを使用します。固定 IP アドレスが割り当てられると、ロード バランサは自動的に割り当て済みとマークし、そのライフサイクルを管理します。

NSX-T の 2 番目のオプションでは、固定 IP アドレスを手動で事前に割り当てます。この場合、ロード バランサに割り当てられた外部ロード バランサの IP アドレス プールに含まれない、フローティング IP アドレス プールから取得された IP アドレスを使用します。この場合は、NSX Manager を使用して、IP アドレスの割り当てとライフサイクルを手動で管理します。

セキュリティに関する重要な検討事項とセキュリティ強化要件

この機能を使用する場合は、セキュリティ上の問題が発生する可能性を認識しておく必要があります。開発者が Service.status.loadBalancerIP 値にパッチを適用できる場合、その開発者は、パッチが適用された IP アドレス宛てのクラスタ内のトラフィックをハイジャックできる可能性があります。特に、この機能が実装されているクラスタで、patch 権限を持つ Role または ClusterRole がサービスまたはユーザー アカウントにバインドされている場合は、そのアカウント所有者が自身の認証情報を使用して kubectl コマンドを発行し、ロード バランサに割り当てられた固定 IP アドレスを変更できます。

ロード バランサ サービスに固定 IP アドレスを割り当てた場合に生じる可能性のあるセキュリティ面の影響を回避するには、この機能を実装している各クラスタのセキュリティを強化する必要があります。これを行うには、開発者に対して定義した Role または ClusterRole で、apiGroups:"" および resources: services/status の verb として patch を禁止する必要があります。ロール スニペットの例は、この機能を実装する際の禁止項目を示しています。

パッチ適用の禁止 
- apiGroups:
  - ""
  resources:
  - services/status
  verbs:
  - patch
開発者にパッチ権限が付与されているかどうかを確認するには、次のコマンドをそのユーザーとして実行します。 
kubectl --kubeconfig <KUBECONFIG> auth can-i patch service/status

このコマンドによって yes が返された場合、そのユーザーにはパッチ権限が付与されています。詳細については、Kubernetes のドキュメントのChecking API Accessを参照してください。

開発者にクラスタへのアクセス権を付与する方法については、以下を参照してください。開発者への TKG サービス クラスタへの vCenter SSO アクセス権付与。カスタマイズ可能なサンプルのロール テンプレートの例については、TKG サービス クラスタへのデフォルトのポッド セキュリティ ポリシーの適用を参照してください。クラスタへのアクセスを制限する方法の例については、https://kubernetes.io/docs/reference/access-authn-authz/rbac/#role-example を参照してください。