【ITニュース解説】Home Lab: Chapter 7 — Kubernetes DNS and SSL

Kubernetes環境が安定し、サービスを外部から利用可能にするための重要なステップとして、DNSとSSLの設定について解説する。DNS（Domain Name System）は、ウェブサイトやサービスにアクセスする際に、人が覚えやすいドメイン名（例: example.com）をコンピューターが理解できるIPアドレス（例: 192.0.2.1）に変換する仕組みである。SSL（Secure Sockets Layer）は、通信を暗号化して安全に保つための技術であり、現代のウェブサービスでは必須である。

まず、サービスにアクセスするためのドメイン名を用意する必要がある。NamecheapやGoDaddy、Google Domainsなどのドメイン登録業者を通じて、自由に管理できる独自のドメインを取得することを推奨する。独自ドメインを使う大きな利点は、公式なSSL証明書を簡単に発行できることである。もし内部専用のドメインを使用する場合、自己署名証明書やプライベートな認証局（CA）による証明書を使うことになるが、これらはブラウザに信頼されていないため、外部からアクセスする際に警告が表示されるなどの問題が生じる可能性がある。独自ドメインを利用すれば、このような手間を避けてHTTPSによる安全なアクセスを容易に実現できる。

DNSの設定は、サービスが内部ネットワークからのみアクセスされる「内部向けアプリケーション」と、インターネット全体からアクセスされる「公開向けアプリケーション」の二つのシナリオで異なる。シンプルに管理するため、これら二つのシナリオに対して異なるDNSサーバーを使用する方法が一般的だ。内部向けにはオープンソースの権威DNSサーバーであるBind9を、公開向けには高速でセキュアなサービスを提供するCloudflareを使用する例を挙げる。

内部向けDNSにはBind9を利用する。Bind9は、内部ドメインのDNSレコードを管理し、外部のドメインに対するリクエストはCloudflareやGoogleなどの外部リゾルバーへ転送する役割を担う。これにより、Bind9は内部のホスト名も外部のホスト名も解決できる、内部ネットワークの主要なDNSサーバーとなる。

Bind9のセットアップは、Helmチャートと呼ばれるパッケージ管理ツールと、GitOpsワークフローを自動化するArgoCDを用いてKubernetesクラスターにデプロイする。この設定では、Bind9コンテナイメージを指定し、DNSサービスをNodePortとして公開することで、クラスター外部からアクセスできるようにする。また、コンフィグレーションファイルは永続化され、Bind9は内部ドメインのDNSレコードを管理する「権威モード」で動作する。Bind9の設定ファイルでは、認証と動的な更新をセキュアに行うためのTSIGキー、ドメインの基本的な情報を定義するSOAレコード、ネームサーバーを指すNSレコード、特定のホスト名をIPアドレスにマッピングするAレコードなどを記述する。これにより、内部DNSは安全かつ永続的に運用され、動的なレコード更新も可能になる。

DNSサーバーが稼働したら、次にレコードの自動作成に取り組む。ExternalDNSというKubernetesコントローラーは、Kubernetesクラスター内のServiceやIngressなどのリソースに付与されたアノテーション（追加情報）を読み取り、対応するDNSレコードを自動的に作成・更新する。Bind9はRFC2136というDNS更新プロトコルをサポートしており、ExternalDNSはこのプロトコルを使ってBind9のレコードを動的に管理できる。ExternalDNSもHelmチャートとArgoCDでデプロイし、Bind9サービスを指すように設定し、TSIGキーを用いてセキュアな更新を保証する。

DNSが整ったら、安全なHTTPSアクセスを可能にするTLS証明書の設定を行う。Cert-ManagerというKubernetesコントローラーは、TLS証明書の発行と更新を自動化する。Let's Encryptのような公開認証局と連携し、証明書を無料で取得できる。Cert-ManagerもHelmとArgoCDでデプロイし、証明書発行のためのClusterIssuerリソースを設定する。このClusterIssuerは、Let's Encryptサーバーを指定し、DNS01チャレンジという方法でドメインの所有権を検証するためにCloudflareを利用する設定を行う。アプリケーションのIngressリソースにアノテーションを追加するだけで、Cert-Managerが自動的に証明書を発行し、更新する仕組みを構築する。

これらの内部設定をテストするため、シンプルなNginxアプリケーションをデプロイし、ServiceとIngressリソースを設定する。IngressにはExternalDNSとCert-Managerのそれぞれのアノテーションを付与する。これにより、ExternalDNSが自動的にBind9にNginxアプリケーションのDNSレコードを作成し、Cert-ManagerがLet's EncryptからTLS証明書を発行して、Ingress Controllerがその証明書を使ってHTTPS通信を終端する。これにより、内部ネットワークからhttps://nginx.<内部ドメイン>のようなホスト名でNginxアプリケーションに安全にアクセスできるようになる。

さらに、内部ネットワークのDNSリゾルバーとしてUnboundを使用している場合、UnboundからBind9へのDNSクエリの転送を設定できる。これにより、内部ネットワークのクライアントはUnboundを通じて、内部アプリケーションのホスト名も外部ドメインも透過的に解決できるようになる。

次に、公開向けアプリケーションのためのDNSとSSLの設定に移る。ここではCloudflareをDNSプロバイダーとして利用する。Cloudflareはその無料プランでもDNS管理機能を提供し、さらにCloudflare Tunnelsという強力な機能を使って、内部サービスを安全にインターネットに公開できる。Cloudflare Tunnelsは、サービスを実行しているサーバーとCloudflareの間に安全なトンネルを確立し、外部からのアクセスはCloudflareのIPアドレスを経由してトンネルを通り、内部サービスに到達する。これにより、自身のサーバーのIPアドレスを隠蔽し、DoS/DDoS攻撃からの保護やトラフィック制御といったCloudflareのセキュリティ機能を自動的に利用できる。

Cloudflare TunnelsをKubernetesから管理するために、cloudflare-operatorというプロジェクトを利用する。これもArgoCDでクラスターにデプロイし、Cloudflare APIトークンをKubernetes Secretに保存する。このAPIトークンには、Tunnelの編集やDNSレコードの編集などの適切な権限を与える必要がある。ClusterTunnelリソースを定義することで、Cloudflare上にトンネルが作成される。アプリケーションを公開するには、TunnelBindingリソースを作成し、公開したいアプリケーションのFQDN（完全修飾ドメイン名）とKubernetes内部でのサービスのエンドポイントを指定する。これにより、Cloudflareが自動的に対応するDNSレコードを作成し、TLS証明書を発行して管理してくれる。

この公開設定もNginxアプリケーションを使ってテストする。アプリケーションをデプロイし、Serviceを設定後、TunnelBindingリソースを作成してCloudflare TunnelにNginxサービスを紐付ける。これにより、CloudflareがDNSレコードとSSL証明書を自動で設定し、インターネットからhttps://nginx.<公開ドメイン>のURLでNginxアプリケーションに安全にアクセスできるようになる。

これらの設定を通じて、DNSとSSL管理の自動化を実現できる。内部向けと公開向けでDNS管理を明確に分離し、ExternalDNSやCert-Manager、Cloudflare Tunnelsなどのツールを活用することで、Kubernetesリソースの定義に基づいてDNSレコードの更新やTLS証明書の発行・更新が自動で行われるようになる。これにより、手動での作業を排除し、安全で最新の状態を常に保ちながら、どのサービスも簡単に外部公開できるようになる。この環境があれば、安心して様々なアプリケーションのデプロイと運用に集中できるだろう。