Kubernetes Ingress によるワークロード公開範囲の確認

Ingress の実際のアクセス経路、認証、TLS 構成がサービス要件に合っているか確認してください。

説明

Ingress は、対応するコントローラーを通じて HTTP・HTTPS リクエストをクラスターの Service に転送します。Ingress があるだけでインターネット公開が確定するわけではなく、コントローラー、エンドポイント、ネットワーク構成によって決まります。内部専用のワークロードを意図せず公開すると、攻撃対象が増える場合があります。

想定される影響

  • 外部リクエストが、機密性の高い管理機能や内部サービスへ届く場合があります。
  • 認証、TLS、バックエンド接続が誤っていると、データ漏えいやサービス停止につながる場合があります。

対処方法

  • 必要なサービスだけを Ingress に接続し、対象 Service の名前とポートを確認してください。内部サービスには、プライベートなコントローラーやエンドポイントと必要なネットワーク制限を使ってください。
  • 公開サービスには適切な認証と TLS を適用し、実際の外部アクセスをテストしてください。Service 名を Terraform 参照に変えるだけでは、公開範囲や権限は制限されません。

例

削除された旧 Ingress API による過去の抜粋です。Kubernetes 1.22 以降では、対応する Ingress API と kubernetes_ingress_v1 の形式を使用してください。コントローラー、パスの解釈、Service の実際のバックエンドは別途構成します。

変更前

hcl
resource "kubernetes_service" "example" {
  metadata {
    name = "ingress-service"
  }

  spec {
    port {
      port        = 80
      target_port = 80
      protocol    = "TCP"
    }

    type = "NodePort"
  }
}

resource "kubernetes_ingress" "example" {
  metadata {
    name = "example"
  }

  spec {
    rule {
      http {
        path {
          path = "/*"

          backend {
            service_name = "example"
            service_port = 80
          }
        }
      }
    }
  }
}

変更後

hcl
resource "kubernetes_service" "example" {
  metadata {
    name = "ingress-service"
  }

  spec {
    port {
      port        = 80
      target_port = 80
      protocol    = "TCP"
    }

    type = "NodePort"
  }
}

resource "kubernetes_ingress" "example" {
  metadata {
    name = "example"
  }

  spec {
    rule {
      http {
        path {
          path = "/*"

          backend {
            service_name = kubernetes_service.example.metadata.0.name
            service_port = 80
          }
        }
      }
    }
  }
}

補足:

  • 変更前: バックエンド名 example は、宣言した Service 名 ingress-service と異なります。example という別の Service がなければ接続されません。
  • 変更後: 宣言した Service の名前を参照します。名前の対応を修正しますが、公開範囲や認証は変更しません。

参考資料