【第4回】ミニPCにKubernetes環境を構築するまで ～Cloudflare基礎編～

はじめに

本記事は、前回公開した
「【第3回】ミニPCに Kubernetes 環境を構築するまで 〜アプリデプロイ編〜」の続編です。

前回の記事では、ミニ PC 上に構築した Kubernetes クラスタへ Spring Boot アプリケーションをデプロイし、NodePort を利用してアプリケーションの動作確認を行いました。

しかし、実際にアプリケーションを運用する場合は、NodePort のまま公開するのではなく、独自ドメインや HTTPS、WAF などを利用して、安全な構成で公開することが一般的です。

そこで今回は、その実現に利用する Cloudflare について紹介します。

Cloudflare は CDN や DNS、WAF、Cloudflare Tunnel など、Web アプリケーションを高速かつ安全に公開するためのさまざまな機能を提供しています。

本記事では、これらの主要機能や役割を整理し、次回以降の記事で Cloudflare を利用して Kubernetes 上のアプリケーションを公開するための準備として、Cloudflare の全体像を理解することを目的とします。

✅ 本記事で分かること

• Cloudflare の概要と役割
• Cloudflare が提供する主要機能（CDN、DNS、WAF、Cloudflare Tunnel）
• Cloudflare を利用するメリット
• Kubernetes と Cloudflare を組み合わせるイメージ

✅ 対象読者

• Kubernetes 上のアプリケーションを安全に公開したい方
• Cloudflare の概要や主要機能を知りたい方
• Cloudflare Tunnel を利用した構成に興味がある方
• ミニPCで自宅 Kubernetes を運用してみたい方

✅ 前提

本記事はシリーズ形式のため、以下の状態がすでに整っている前提で進めます。

• ミニ PC に Kubernetes クラスタが構築済み
  （前々回の記事「構築編」で実施）
• 前回の記事でデプロイした Spring Boot アプリケーションが、Kubernetes 上で動作している
  • Deployment および Service（NodePort）が作成済み
  • kubectl get pods や NodePort 経由のアクセスで動作確認済みの状態

Cloudflare とは

CDN とは

Cloudflare の説明に入る前に、まずはその基盤となる考え方である CDN（Content Delivery Network） について整理します。

CDN とは、Web コンテンツを高速・安定的にユーザーへ配信するための分散型ネットワークの仕組みです。
CDN を利用すると、以下のような場面でも素早くコンテンツを提供できます。

• アクセスが集中している場合
• コンテンツの容量が大きい場合
• サーバーがユーザーから地理的に離れている場合
  • 例：日本にあるサーバーへ、ヨーロッパのユーザーがアクセスするケース

CDN が高速化を実現する仕組み

CDN の高速化は、主に以下 2 つの仕組みによって成り立っています。

① オリジンサーバーの負荷軽減（キャッシュの活用）

CDN には「キャッシュサーバー」と呼ばれるサーバーが世界中に配置されています。
ユーザーがコンテンツにアクセスすると、CDN は次のように動きます。

• 1. キャッシュサーバーにデータ（キャッシュ）がある場合
     → キャッシュサーバーから直接ユーザーへコンテンツを返す（高速・低負荷）
• 1. キャッシュがない場合
     → オリジンサーバーからコンテンツを取得してキャッシュサーバー内に保存し、次回以降キャッシュとして使用する

これにより、
・オリジンサーバーへのアクセス回数が減る ( = オリジンサーバーの負荷を軽減)
・キャッシュから返せるため応答速度が向上する
というメリットがあります。

② ユーザーとサーバー間の物理的距離を短縮

CDN のキャッシュサーバーは世界中に分散しており、ユーザーは最寄りのキャッシュサーバー に自動的にルーティングされます。

例えば、日本にいるユーザーが、アメリカにホストされている Web サイトにアクセスすると、アメリカのオリジンサーバーではなく日本にあるキャッシュサーバーにルーティングされます。
そして、キャッシュサーバーにコンテンツがキャッシュされていれば、キャッシュサーバーからコンテンツがユーザーに返されます。
このようにユーザーとサーバー間の応答距離が短くなることで通信の遅延が減り、体感速度が向上します。

補足：CloudFront のエッジロケーションとは？

AWS の CDN サービスである CloudFront では、「エッジロケーション」と呼ばれるサーバー群が世界中に展開されています。

このエッジロケーションは、CDN におけるキャッシュサーバーと同じ役割を持つものです。
CloudFront はユーザーのアクセス元の地域を解析し、最寄りのエッジロケーションへ案内することで、コンテンツ配信を高速化しています。
（CloudFront の詳細については、以下の記事でも説明されています）
https://business.ntt-east.co.jp/content/cloudsolution/column-480.html

Cloudflare とは

Cloudflareは、CDN を提供するサービスの 1つです。
CDN が持つ Web コンテンツの迅速な提供はもちろん、独自ドメインの設定（DNS の設定）や、WAF や DDoS 防御などのwebセキュリティをオールインワンで提供しています。

Cloudflare は海外の企業が提供するサービスですが、日本においても利用が広がっており、Cloudflare の導入支援サービスを提供する日本企業も存在します。

ここからは Cloudflare の主要な機能について見ていきたいと思います。

CDN

Cloudflare も他の CDN サービスと同様、世界中に分散されたサーバーネットワークを活用し、Web コンテンツの迅速な提供を実現しています。

Cloudflare は全世界で 330 箇所以上にデータセンターを保持しており、インターネット人口の約 95% が 50 ミリ秒以内にキャッシュサーバーへ到達できるとされています。

そのため世界中のユーザーは低レイテンシーでキャッシュサーバーにアクセスでき、CDN 本来の特性とあわせて高速なコンテンツ配信が可能となっています。

階層型キャッシュ（Argo Tiered Cache）

Cloudflare ではキャッシュサーバーのキャッシュヒット率をさらに高めるために、階層型キャッシュという仕組みを採用しています。

• Upper Tier：オリジンに最も近い DC にあるキャッシュサーバー（オリジンとの通信を担当）
• Lower Tier：ユーザーに最も近い DC にあるキャッシュサーバー（ユーザーからのアクセスを担当）

Upper Tier は 1 つに固定される仕組みになっており、これがキャッシュヒット率向上のポイントになっています。

階層型キャッシュの処理の流れ

ユーザーが Web コンテンツにアクセスした場合、以下のように処理されます。

1. リクエストはまず、ユーザーに最も近い Lower Tier にルーティングされる
2. Lower Tier にキャッシュがない場合、Upper Tier にキャッシュ有無を問い合わせる
3. Upper Tier にキャッシュがある場合：
   → それを Lower Tier に返却
4. Upper Tier にキャッシュがない場合：
   → Upper Tier がオリジンサーバーへリクエストし、取得したコンテンツを Lower Tier に返却

階層型キャッシュがキャッシュヒット率を高める理由（例）

階層型キャッシュでは Upper Tier が全世界で共通の参照ポイントになる ため、各地域で個別にキャッシュを持つ方式よりもキャッシュヒット率が高くなります。

以下の例がわかりやすいです。

例：イギリスと日本から同じ Web コンテンツにアクセスした場合

• イギリスのユーザーが Web コンテンツに初めてアクセス
  • Lower Tier にキャッシュがない
  • Upper Tier もキャッシュなし → オリジンへ問い合わせ
  • Upper Tier は取得したキャッシュを保持

• その後、日本のユーザーが同じコンテンツにアクセス
  • 日本の Lower Tier にキャッシュがなくても、
  • Upper Tier にキャッシュがあるため、そのまま返される

階層型キャッシュを使わない場合、日本のユーザーからのアクセス時にはオリジンへの問い合わせが必要ですが、階層型キャッシュでは Upper Tier がキャッシュを保持しているため、オリジンへの問い合わせが不要になります。

その結果、

• オリジンサーバーへのアクセス回数が減る
• コンテンツ配信が高速化される
• キャッシュヒット率が高まる

というメリットが得られます。

※この機能を使うには「Argo Tiered Cache」を有効にする必要があります。

DNS

Cloudflare には「Cloudflare DNS」という DNS サービスがあります。
Cloudflare DNS は権威 DNS として非常に高速で、DNS ルックアップ速度は平均 10 数ミリ秒とされており、Web サイトの高速な名前解決を実現します。

また、CDN の章で記載した通り、Cloudflare は全世界で 330 箇所以上のデータセンターを保持しており、これらのデータセンター上で Cloudflare DNS が稼働しています。
各データセンターで DNS 応答が可能なため、冗長性・可用性の高い DNS サービスとなっています。

Cloudflare DNS では、DDoS 攻撃に対する耐性を備えているほか、DNSSEC（Domain Name System Security Extensions）を利用した DNS 応答の検証にも対応しています。

次の章では、この DNSSEC がどのような仕組みで DNS 応答の正当性を検証しているのかについて説明します。

DNSSEC

DNSSEC（DNS Security Extensions）とは、DNSの名前解決結果が改ざんされていないことを検証するための仕組みです。

従来のDNSでは、DNSキャッシュサーバー（リゾルバ）は権威DNSサーバーから返ってきた応答をそのまま信頼していました。

そのため、攻撃者が偽の応答をDNSキャッシュサーバーに送りつけることで、DNSキャッシュに偽のIPアドレスを登録させ、利用者を不正なサイトへ誘導するキャッシュポイズニング攻撃が可能でした。

DNSSECの仕組み
DNSSECでは、DNSレコードに 電子署名 を付与することで、応答の正当性を検証できるようにしています。
A レコード (www.hogehoge.co.jp) を例に DNSSEC における応答検証の流れを以下に記載します。

• ① hogehoge.co.jp の権威 DNS サーバーが秘密鍵と公開鍵の鍵ペアを作成
  • 公開鍵は DNSKEY レコードとして登録します

• ② 権威 DNS サーバーが　www.hogehoge.co.jp A レコードからハッシュ値を生成

• ③ 自身が作成した秘密鍵を用いて、ハッシュ値に対する電子署名を生成
  • 署名は RRSIG レコードに登録します

• ④ クライアント（DNSキャッシュサーバー）から www.hogehoge.co.jp A レコードの問い合わせがあったら、権威 DNS サーバーは A レコード 、A レコードの署名（RRSIG）を返す。

• ⑤ キャッシュサーバーは、署名の検証に必要な公開鍵（DNSKEY レコード）を権威 DNS サーバーから取得する。

• ⑥ DNSキャッシュサーバーは受け取った A レコード、RRSIG レコード、権威 DNS サーバーの公開鍵を使って検証を行う
  ・A レコードから、権威 DNS サーバーが署名を作成した際と同じアルゴリズムでハッシュ値を生成（a）
  ・RRSIG レコードの値（署名）を公開鍵で復号（b）
  ・(a) と (b) の値を比較し、値が同一であることを確認

• ⑦ 検証が成功すれば「正しい権威DNSサーバーから改ざんされていない応答が返ってきた」と判断できる
  • 攻撃者から偽の応答が返されていれば、(a) と (b) の値が異なるので検証に成功しない

この仕組みにより、DNSキャッシュポイズニング攻撃を防ぐことができます。

ただ、これには 1 つ懸念があります。
キャッシュサーバーは受け取った DNSKEY レコードが、権威 DNS サーバーのものであると信頼の上、この検証を行っています。

もし、攻撃者が偽の A レコードだけでなく、そのレコードのハッシュ値の署名 (RRSIG) 、公開鍵 (DNSKEY) を用意している場合はどうなるでしょうか？
この場合、DNSSEC の検証自体は PASS できてしまいます。
　偽の A レコードのハッシュ値と、RRSIG レコードを復号して取得した値が同じ場合検証に成功してしまう

 

そのため、各ゾーンの公開鍵が、本当にそのゾーンの権威 DNS サーバーが発行したものであることを何らかの形で保証する必要があります。

DNSSEC では、この公開鍵を信頼する仕組みとして「信頼の連鎖（Chain of Trust）」を採用しています。

 

信頼の連鎖
DNS の問い合わせでは、以下の順番に問い合わせがされていきます。
　ルートドメイン → トップレベルドメイン ( TLD ) → TLD の子ドメイン → さらにその子のドメイン

DNSSEC では、この仕組みを上手く活用し、各ゾーンの正規の権威 DNS サーバーの公開鍵が改ざんされていないことを保証しています。

信頼の連鎖 では、各ゾーンの公開鍵の信頼性を、そのゾーンの親ゾーンが担保しています。
ゾーンの管理者は公開鍵・秘密鍵の鍵ペアを作成し、公開鍵のハッシュ値（DS：Delegation Signer）を親ゾーンの管理者へ送信します。

親ゾーンの管理者は、そのハッシュ値が正しいことを確認したうえで、DS レコードとして公開します。

同様に親ゾーンも自身の公開鍵のハッシュ値を、その親ゾーンに登録します。
この処理を繰り返すことで、最終的に TLD の DS レコードがルートドメインに登録されます。
これにより、ルートドメインを起点として各ゾーンの公開鍵を順番に検証できる「信頼の連鎖」が構築されます。

DNS キャッシュサーバーはこの DS レコードを使って、対象ゾーンの公開鍵が正しいものであるか確認し、その結果に応じて正規の権威 DNS サーバーから正しい応答が返されていることを検証します。
上記の A レコード (www.hogehoge.co.jp) を例に説明します。

• ① ユーザが DNS キャッシュサーバーに www.hogehoge.co.jp A レコードを問い合わせる。
• ② キャッシュサーバーは自身のキャッシュ内にこの A レコードの情報が存在しない場合、ルートドメインから順番にDNS の問い合わせを行い、以下の情報をルートドメインから取得する。
  ・「.jp」の権威 DNS の場所と DS レコード

• ③ キャッシュサーバーが「.jp」の権威 DNS に問い合わせ、以下の情報を取得する
  ・「.co.jp」の権威 DNS サーバーの場所と DS レコード
  ・「.jp」の権威 DNS の DNSKEY レコード

• ④ キャッシュサーバーは「.jp」の DNSKEY レコードから公開鍵のハッシュ値を生成し、ルートドメインから返された DS レコードとハッシュ値が同じかを確認する

• ⑤ 比較した DS レコードとハッシュ値が同じであれば、「.jp」の公開鍵は改ざんされておらず、正しい権威 DNS から鍵が返されているとキャッシュサーバーは判断する。その後、キャッシュサーバーは「.co.jp」の権威 DNS に問い合わせ、以下の情報を取得する
  ・「.hogehoge.co.jp」の権威 DNS サーバーの場所と DS レコード
  ・「.co.jp」の権威 DNS の DNSKEY レコード

• ⑥ キャッシュサーバーは「.co.jp」の DNSKEY レコードから公開鍵のハッシュ値を生成し、「.jp」の権威 DNS から返された DS レコードとハッシュ値が同じかを確認する

• ⑦ ⑥ で比較した DS レコードとハッシュ値が同じであれば、「.co.jp」の公開鍵は改ざんされておらず、正しい権威 DNS から鍵が返されているとキャッシュサーバーは判断する。その後、キャッシュサーバーは「.hogehoge.co.jp」の権威 DNS に問い合わせ、以下の情報を取得する
  ・ www.hogehoge.co.jp A レコードの値（IP アドレス）
  ・「.hogehoge.co.jp」の権威 DNS の DNSKEY レコード、RRSIG レコード

• ⑧ キャッシュサーバーは「.hogehoge.co.jp」の DNSKEY レコードから公開鍵のハッシュ値を生成し、「.co.jp」の権威 DNS から返された DS レコードとハッシュ値が同じかを確認する

• ⑨ ⑧ で比較した DS レコードとハッシュ値が同じであれば、「.hogehoge.co.jp」の公開鍵は改ざんされておらず、正しい権威 DNS から鍵が返されているとキャッシュサーバーは判断する。

• ⑩ その後、受け取った A レコード、RRSIG レコード、権威 DNS サーバーの公開鍵を使って A レコードが改ざんされていないか検証を行う
  ・A レコードから、権威 DNS サーバーが署名を作成した際と同じアルゴリズムでハッシュ値を生成（a）
  ・RRSIG レコードの値（署名）を公開鍵で復号（b）
  ・(a) と (b) の値を比較し、値が同一であることを確認

• ⑪ ⑩ の検証が成功すれば「hogehoge.co.jp」の正しい権威DNSサーバーから改ざんされていない応答が返ってきた」と判断

 

DNSSEC が有効化されているゾーンでは、親ゾーンに DS レコードが公開されます。
（com や org などのトップレベルドメイン (TLD) はルートゾーンに DS レコードを公開しています）

ただし、ルートゾーンは DNS 階層の最上位であり、親ゾーンが存在しないため DS レコードは存在しません。
（DS レコードによる公開鍵の検証をルートゾーンで行うことはできない）
そのため、ルートゾーンの公開鍵は別の方法で信頼性を検証しています。

ルートゾーンの公開鍵は、ICANN によるルート署名セレモニーという極めて厳格な手続きによって生成され、
キャッシュサーバーにはルートゾーンの公開鍵が予め登録されています。。

DNS キャッシュサーバーは、このルートの公開鍵を起点として、
DS レコードをたどることで下位ゾーンの公開鍵の正当性を検証していきます。
（ルートの公開鍵は「信頼の起点（Trust Anchor）」として扱われます）

このため、DNSSEC における信頼はルートゾーンから始まり、
ルート → TLD → 子ゾーンへと連鎖的に検証されていきます。
（連鎖的に信頼が検証されていくので、この仕組みを「信頼の連鎖」と呼びます）

独自ドメインの設定

Cloudflare DNS では、自身が取得した独自ドメインを権威 DNS として管理できます。

Cloudflare を権威 DNS として設定すると、
そのドメインのゾーンに A レコードや CNAME レコードなどのDNS レコードを登録できるようになります。

例えば、オリジンサーバーの IP アドレスを指す A レコードを登録することで、
そのドメイン名で自身が用意した Web サイトへアクセスできます。

また、ドメインは他社レジストラで取得したものをCloudflare に移管して利用することも可能ですし、Cloudflare 上で新規にドメインを購入して利用することも可能です。

他社レジストラで取得したドメインを使用する場合は、
ドメインのネームサーバーを取得元のものから Cloudflare が指定するネームサーバーへ変更する必要があります。
ネームサーバーを Cloudflare に変更することで、そのドメインの権威 DNS は Cloudflare が担うことになります。

ネームサーバーの変更手順については、こちらの記事 を参考にしてください。

セキュリティ設定

Cloudflare には様々なセキュリティ機能が備わっています。
まず、WAF 機能があり、SQL インジェクション攻撃やクロスサイトスクリプティング攻撃といった、Web アプリケーションに対する不正アクセスや攻撃をブロックします。

WAF では様々なルールを設定し、そのルールが各リクエストを評価することで、そのリクエストをブロック or 許可するかを制御します。

WAF で設定するルールには、ユーザ自身で定義するルールと、Cloudflare が事前に定義・提供するマネージドルールがあります。
マネージドルールは Cloudflare によって継続的にメンテナンスされており、新たな攻撃手法や脆弱性への対応、誤検知の改善などが自動的に反映されます。
マネージドルールの主なルールセットは以下のとおりです。
　Cloudflare Managed Ruleset
　Cloudflare OWASP Core Ruleset
　Cloudflare Exposed Credentials Check
　Cloudflare Free Managed Ruleset

Cloudflare Managed Ruleset

Cloudflare セキュリティチームによって作成されているルールセットです。
SQL インジェクションや XSS といった既知の攻撃手法やゼロデイ脆弱性（パッチが公開されていない、新たな攻撃や脆弱性）の脅威からアプリケーションを保護します。
このルールセットは新たな脅威や攻撃に対応できるように、また誤検知（正当なリクエストが攻撃と判定されること）を減らすために、Cloudflare セキュリティチームによって頻繁に更新されています。

Cloudflare OWASP Core Ruleset

Cloudflare側で用意されているマネージドルールの一つで、OWASP Top 10 に基づいたルールセットです。
Cloudflare Managed Ruleset は Cloudflare 独自の知見に基づいて作成・更新されるルールセットです。
一方、Cloudflare OWASP Core Ruleset は OWASP ModSecurity Core Rule Set をベースとした標準的なルールセットであり、OWASP Top 10 に代表される一般的なWebアプリケーション攻撃を検知します。

また、このルールセットはスコアリングモデルを採用しており、一致した各ルールのスコアが加算され、累積スコアが閾値を超えた時点で、WAFは設定されたアクション（ブロック等）を実行します。

OWASP Top 10
OWASP (Open Web Application Security Project) と呼ばれる、ソフトウェアのセキュリティ向上を目的とした非営利団体によって公表されているもの。
Webアプリケーションにおける重大なセキュリティリスクを、トップ10形式でまとめたもので、数年ごとに更新されています。

OWASP ModSecurity Core Rule Set
ModSecurity とは OSS の Web Application Firewall（WAF）です。
Apache や Nginx など複数の Web サーバーで利用できます。

ModSecurity は、リクエストやレスポンスをどのように検査するかを「ルールセット」で定義します。
その代表的なルールセットが OWASP ModSecurity Core Rule Set（CRS） です。

OWASP ModSecurity Core Rule Set（CRS）は、OWASP が公開している Web アプリケーションのセキュリティに関する知見やベストプラクティスに基づいて設計・開発されており、SQL インジェクションやクロスサイトスクリプティング（XSS）などの一般的な攻撃を検知・防御するためのルールが含まれています。

Cloudflare Exposed Credentials Check

このルールセットはログイン画面などの認証エンドポイントに送信された認証情報（ユーザー名・パスワード等）の組み合わせを、既知の漏洩認証情報データベースと照合し、「過去に漏洩した認証情報の使い回し」を検知するためのルールセットです。

Cloudflare Free Managed Ruleset

Cloudflare Free Managed Ruleset は、全プランで利用できるルールセットです。
このルールセットでも、影響が大きく、広く悪用されている脆弱性からアプリケーションを保護します。
なお、Cloudflare Managed Ruleset を使用している場合、このルールセットは不要です。
（Cloudflare Managed Ruleset の中に、このルールセットが含まれているため）

このルールセットはデフォルトで有効になっています。

各マネージドルールを整理すると以下のようになります。

ルールセット	役割
Cloudflare Managed Ruleset	Cloudflare独自の最新の脅威やゼロデイ攻撃を検知・防御
Cloudflare OWASP Core Ruleset	OWASP Top 10に代表される一般的なWebアプリケーション攻撃を検知・防御
Cloudflare Exposed Credentials Check	漏洩した認証情報の使い回し検知
Cloudflare Free Managed Ruleset	全プランで利用できる基本的な保護ルール（Cloudflare Managed Ruleset に含まれる）

WAF のカスタムルール設定

WAF では、上記のマネージドルールを利用するだけでなく、ユーザ自身でカスタムでルールを定義することもできます。

以下は日本以外からのアクセスをブロックするルール設定です。
画面上で条件等を選択しながらルールを設定することができるようになっており、簡単に想定通りのルールを定義することができます。

Cloudflare Tunnel

Cloudflare Tunnel は、ユーザのプライベートネットワーク環境下にあるサーバ、API に、パブリック IP を払い出すことなくインターネットからアクセスできるようにする機能です。

自宅等のプライベート環境にホストしているサーバや API をインターネットから直接アクセスさせるには、一般的にパブリック IP の公開やポート開放などのネットワーク設定が必要になります。

Cloudflare Tunnel を利用すると、自宅等にあるサーバにパブリック IP を割り当てたり、インターネット向けにポートを開放したりすることなく、プライベートネットワーク内のサーバや API を公開できます。

Cloudflare Tunnel では、接続対象サーバ内に cloudflared と呼ばれるデーモンをインストールして実行します。
そして、Cloudflare と cloudflared の間で、暗号化された永続的なトンネルを確立します。

Cloudflare に届いたリクエストは、このトンネルを経由して cloudflared に転送され、cloudflared がローカルで動作している Web サーバや API にリクエストを中継します。
（下図は、Cloudflare Tunnel の公式リファレンスから引用）

cloudflared は Cloudflare に対してアウトバウンド通信で接続するため、オリジンサーバ側でインバウンド通信を許可するためのポート開放やファイアウォール設定は不要です。

また、すべての通信が Cloudflare を経由するため、WAF 等の Cloudflare の各種セキュリティ機能をプライベート環境のサーバや API に対して適用できます。

私の自宅 Kubernetes では

私の自宅 Kubernetes では、Kubernetes 上で動作するアプリケーションをインターネットから安全に公開するために、Cloudflare Tunnel を利用しています。

次回以降の記事では、Cloudflare Tunnel を用いて Kubernetes 上のアプリケーションを公開する方法や、実際の構成について紹介します。

おわりに

本記事では、Cloudflare の概要や、CDN・DNS・WAF・Cloudflare Tunnel などの主要な機能について整理しました。

Cloudflare は単なる CDN サービスではなく、Web アプリケーションの高速化やセキュリティ向上、さらにはプライベート環境のサーバを安全に公開するための機能まで備えた、非常に多機能なプラットフォームです。

次回以降の記事では、Cloudflare Tunnel を利用して Kubernetes 上に構築したアプリケーションをインターネットへ公開する方法や、その設定手順について紹介します。

参考資料

https://www.kagoya.jp/howto/it-glossary/web/cdn/
https://dev.classmethod.jp/articles/amazon-cloudfront-cdn/
https://cloudflare.domore.co.jp/
https://dev.classmethod.jp/articles/how-cloudflare-tiered-cache-works/
https://developers.cloudflare.com/reference-architecture/architectures/cdn/?_gl=1*151v4uw*_gcl_au*ODY3MDExMjY4LjE3NjUwMjg2ODY.*_ga*MWM1NGE2ZmQtMzljYi00ZTlkLWE4NjItNTA3OTk2YzQ4NjQ4*_ga_SQCRB0TXZW*czE3NjUwMjg2ODYkbzEkZzEkdDE3NjUwMjg3MTQkajMyJGwwJGgwJGRrZ0huZFNpWEpIMTRjTW5sUWpLNF9BeVRIdHFWUjRfLTd3
https://www.cloudflare.com/ja-jp/application-services/products/dns
https://www.nttpc.co.jp/technology/dns_security.html
https://www.nic.ad.jp/ja/newsletter/No43/0800.html
https://howdnssec.works/jp/new-records/
https://howdnssec.works/jp/trust-the-hierarchy/
https://www.cloudflare.com/ja-jp/learning/dns/dnssec/how-dnssec-works/
https://www.cloudflare.com/ja-jp/learning/dns/dnssec/root-signing-ceremony/
https://www.jnsa.org/result/pki/seminar/2010/2010-015.pdf
https://developers.cloudflare.com/waf/managed-rules/
https://biz.kddi.com/content/glossary/o/open-web-application-security-project/
https://beyondjapan.com/blog/2024/08/modsecurity/
https://webspeed.ne.jp/blog/owasp-modsecurity/
https://developers.cloudflare.com/tunnel/
https://zenn.dev/takajun/articles/fbd783e459c722