説明
Service の type を LoadBalancer にすると、対応する環境ではロードバランサー経由でサービスを公開できます。インターネットへの公開は、プロバイダー、コントローラー、内部ロードバランサーの設定に左右されます。外部アクセスが不要なサービスをパブリックエンドポイントで公開すると、不要な接続試行が増える場合があります。
想定される影響
- 認証やアプリケーションに脆弱性があると、外部接続からデータが漏えいする場合があります。
- 不要な外部エンドポイントは、攻撃対象と運用コストを増やす場合があります。
対処方法
- クラスター内だけで必要なサービスには ClusterIP を使い、プライベートネットワークのロードバランサーが必要なら、プロバイダーの内部設定を使用してください。
- 公開が必要なサービスは送信元範囲を制限し、認証と TLS を構成して、実際に割り当てられたエンドポイントを確認してください。Ingress など他の公開経路も確認してください。
例
Service の種類だけを比較する既存の例です。selector に一致するワークロードは別途必要です。ClusterIP に変更しても、他の Ingress やプロキシがサービスを公開する場合があります。
変更前
hcl
resource "kubernetes_service" "example" {
metadata {
name = "terraform-example"
}
spec {
selector = {
app = "my-app"
}
port {
port = 80
target_port = 8080
}
type = "LoadBalancer"
}
}
変更後
hcl
resource "kubernetes_service" "example" {
metadata {
name = "terraform-example"
}
spec {
selector = {
app = "my-app"
}
port {
port = 80
target_port = 8080
}
type = "ClusterIP"
}
}
補足:
- 変更前: LoadBalancer を使用します。実際のパブリック・内部エンドポイントは環境の設定に左右されます。
- 変更後: ClusterIP に変更し、この Service 自体はロードバランサーを要求しません。