Cert Manager を使用して Kubernetes Gateway 証明書を自動的に管理する

Cert Manager を使用して Kubernetes Gateway 証明書を自動的に管理する

背景

Kubernetes ゲートウェイ

おそらく、より正確にはKubernetes Gateway API[1] (GWAPI)と呼ぶべきでしょう。 GWAPIはSIG-NETWORK[2]コミュニティによって管理されているオープンソースプロジェクトです。これは仕様であり、実装は提供しません。 Gateway APIはKubernetes Ingress API[3]の後継と考えられており、2019年のIngress革命[4]で初めて提案されました。最初のバージョンは2020年11月にリリースされました。GWAPIは非常に急速に発展しています。本稿執筆時点ではバージョン1.0.0[5]まで進化しており、1.1.0がリリースされようとしている(1.1.0-rc2[6]がリリースされている)。

GWAPI は、Kubernetes クラスターの内外のトラフィックを管理する方法です。ルーティングとゲートウェイの構成を記述するための、より洗練されたモジュール式のアプローチを提供します。従来の Ingress API と比較して、GWAPI はより柔軟で拡張性の高い設計になっています。

証明書マネージャー

cert-manager[7]はKubernetes専用に設計された自動証明書管理ツールです。 Kubernetes クラスターで X.509 証明書を使用する管理プロセスが簡素化されます。 cert-manager を使用すると、ユーザーは、サービス、アプリケーション、内部通信など、Kubernetes 内のさまざまなリソースの SSL/TLS 証明書を簡単かつ自動的に発行、更新、管理できます。これはデータ転送のセキュリティを確保するために非常に重要です。

cert-manager には主に次の機能があります。

  • 自動証明書発行および更新: cert-manager は、証明書の申請、更新、およびライフサイクル管理を自動的に処理できます。
  • 複数の発行元のサポート: cert-manager は、自己署名証明書を含む複数の証明機関 (CA) をサポートします。 ACME 経由で Let's Encrypt などのパブリック CA を使用する。 HashiCorp Vault[8]やRustyVault[9] PKIなどのエンタープライズ向けCAシステム。
  • Kubernetes ネイティブ統合: Kubernetes のネイティブ コンポーネントとして、cert-manager は CRD を使用して発行者や証明書などのリソースを定義できます。

特に最後のポイントとして、cert-manager は、この記事で紹介した K8s Gateway との統合など、Kubernetes エコシステムの他のコンポーネントと簡単かつシームレスに統合できます。

なぜ cert-manager なのか?

Kubernetes 環境では、クラスター全体への入り口となる Gateway は、受信トラフィックを管理するための重要なコンポーネントです。多くの機能的特徴の中でも、セキュリティは特に顕著かつ重要です。その中でも、通信の暗号化はデータのセキュリティを確保するための主な手段です。 TLS/SSL 証明書を使用することで、Gateway はクラスターに出入りするすべてのデータが暗号化されることを保証します。これにより、盗聴や改ざんからデータが保護されるだけでなく、クライアントとサービス間の通信が安全であることも保証されます。この一方向 SSL 暗号化に加えて、エンドツーエンドのセキュリティ検証を実現するために双方向 SSL 暗号化をサポートするように構成することもできます。

cert-manager を使用して Kubernetes Gateway 証明書を管理すると、運用効率が大幅に向上し、システム セキュリティが強化され、スケーラブルかつ保守可能な方法でエンタープライズ レベルの展開と管理がサポートされるなど、多くの利点が得られます。

  • 自動証明書管理: 開発者と管理者は手動による介入を減らすことができるため、証明書関連のタスク (更新忘れなど) を手動で処理することによって発生するエラーやサービスの中断のリスクを軽減できます。これらはすべて、cert-manager を使用して自動化できます。
  • 外部 CA の統合: cert-manager は、Let's Encrypt、HashiCorp Vault、Venafi など、複数の証明機関 (CA) をサポートしています。これにより、Kubernetes 環境で商用または自社開発の CA を簡単に使用し、証明書のコンプライアンスと認証を確保できます。
  • セキュリティとコンプライアンス: 自動証明書ローテーションと有効期間の短い証明書の使用により、セキュリティとコンプライアンスが強化されます (自動証明書更新により、攻撃者から盗まれた証明書は短期間しか使用できなくなります)。
  • Kubernetes とのネイティブ統合: GWAPI を操作するための CRD と同様に、cert-manager CRD の操作は開発者にとって使いやすく、GWAPI とシームレスに統合できます。

デモの説明

  1. FSMゲートウェイ[10]はゲートウェイAPI[11]の実装の1つであり、FSM[12]エコシステム全体の多くのコンポーネントの1つです。 Kubernetes の入力トラフィック管理を担当します。このデモンストレーションでは、ゲートウェイ実装としてFSMゲートウェイを使用し、そのTLSオフロード[13]機能を活用してアップストリームサービスのセキュリティを強化します。
  2. 前述したように、cert-managerは複数の発行元をサポートできます[14]。ここでは、操作の容易さのために、最も単純な自己署名 CA 証明書を選択します。

写真

前提条件

  • K8s クラスター>=1.22
  • kubectl

FSMゲートウェイをインストールする

FSMゲートウェイ[15]のインストールドキュメントを参考に、インストールにはCLIを使用します。 FSM の最新バージョンは 1.2.4 です。

 system=$(uname -s | tr '[:upper:]' '[:lower:]') arch=$(uname -m | sed -E 's/x86_/amd/' | sed -E 's/aarch/arm/') release=v1.2.4 curl -L https://github.com/flomesh-io/fsm/releases/download/$release/fsm-$release-$system-$arch.tar.gz | tar -vxzf - ./$system-$arch/fsm version

インストールするには、次のコマンドを実行します。

 fsm install \ --set=fsm.fsmGateway.enabled=true

インストールが成功すると、GatewayClass fsm-gateway-cls が登録されていることがわかります。

 kubectl get gatewayclass NAME CONTROLLER ACCEPTED AGE fsm-gateway-cls flomesh.io/gateway-controller True 106s

cert-managerをインストールする

cert-manager は、kubectl マニフェストまたは helm チャートを通じてインストールできます。ここではヘルムチャートを選択します。注意: インストール中に CRD をインストールすることを忘れないでください。

 helm repo add jetstack https://charts.jetstack.io --force-update helm repo update helm install \ cert-manager jetstack/cert-manager \ --namespace cert-manager \ --create-namespace \ --version v1.14.5 \ --set installCRDs=true

自己署名 CA 証明書が使用されるため、発行元を作成する前に CA 証明書が署名されます。

 openssl genrsa 2048 > ca-key.pem openssl req -new -x509 -nodes -days 365000 \ -key ca-key.pem \ -out ca-cert.pem \ -subj '/CN=flomesh.io'

CA 証明書を Secret ca-key-pair に保存し、名前空間 cert-manager を指定します。

 kubectl create secret generic -n cert-manager ca-key-pair \ --from-file=tls.crt=./ca-cert.pem \ --from-file=tls.key=./ca-key.pem

ここでは、タイプ ca の ClusterIssuer を直接作成し、上記で作成した秘密の ca-key-pair を指定します。

 cat <<EOF | kubectl apply -f - apiVersion: cert-manager.io/v1 kind: ClusterIssuer metadata: name: ca-issuer-sample spec: ca: secretName: ca-key-pair EOF

準備が整ったので、サンプル アプリケーションをテスト用にデプロイしましょう。

サンプルアプリケーションをデプロイする

httpbin サービスを作成します。

 kubectl create namespace httpbin cat <<EOF | kubectl apply -n httpbin -f - apiVersion: apps/v1 kind: Deployment metadata: name: httpbin spec: replicas: 1 selector: matchLabels: app: httpbin template: metadata: labels: app: httpbin spec: containers: - name: httpbin image: kennethreitz/httpbin ports: - containerPort: 80 --- apiVersion: v1 kind: Service metadata: name: httpbin spec: selector: app: httpbin ports: - protocol: TCP port: 8080 targetPort: 80 EOF

TLS証明書の発行

TLS 証明書を発行するには、CR 証明書を作成する必要があります。 cert-manager はリソースを監視し、リソース構成に基づいて証明書を発行し、secretName フィールドで指定されたシークレットに保存します。

  • 証明書は秘密の simple-gateway-cert に保存されます。
  • 証明書の有効期間は60分に設定されています
  • 証明書のローテーションの事前時間 renewBefore は 59 分に設定されており、これは 1 分ごとにローテーションが行われることを意味します。
  • 共通名 commonName は foo.example.com に設定されています
  • 最も重要なことは、証明書の発行元をClusterIssuer ca-issuer-sampleとして指定することです。
 cat <<EOF | kubectl apply -f - apiVersion: cert-manager.io/v1 kind: Certificate metadata: name: simple-gateway-cert namespace: httpbin spec: secretName: simple-gateway-cert duration: 60m renewBefore: 59m subject: organizations: - flomesh-io commonName: foo.example.com issuerRef: name: ca-issuer-sample kind: ClusterIssuer group: cert-manager.io EOF

証明書が作成されると、cert-manager によって作成された secert が、名前空間 httpbin の下に、タイプ kubernetes.io/tls で見つかります。

 kubectl get secret simple-gateway-cert NAME TYPE DATA AGE simple-gateway-cert kubernetes.io/tls 3 20s

証明書を取得したら、httpbin サービスの HTTPS アクセス エントリを公開できます。

ゲートウェイとルーターの作成

httpbin サービスをクラスターの外部に公開するには、ゲートウェイとルートを作成する必要があります。

  • リスナーはポート8000​​でリッスンします
  • プロトコルをTLSに設定
  • 証明書は秘密のsimple-gateway-cert経由で提供されます
  • 最も重要なモードは終了に設定されています
cat <<EOF | kubectl apply -n httpbin -f - apiVersion: gateway.networking.k8s.io/v1beta1 kind: Gateway metadata: name: simple-fsm-gateway spec: gatewayClassName: fsm-gateway-cls listeners: - name: https port: 8000 protocol: HTTPS tls: certificateRefs: - kind: Secret name: simple-gateway-cert mode: Terminate allowedRoutes: namespaces: from: Same --- apiVersion: gateway.networking.k8s.io/v1beta1 kind: HTTPRoute metadata: name: http-route-foo spec: parentRefs: - name: simple-fsm-gateway port: 8000 hostnames: - foo.example.com rules: - matches: - path: type: PathPrefix value: / backendRefs: - name: httpbin port: 8080 EOF

テスト

直接アクセス用の CA 証明書を提供しないと、次のような問題が発生します。

 curl https://foo.example.com/headers --connect-to foo.example.com:443:$GATEWAY_IP:8000 curl: (60) SSL certificate problem: unable to get local issuer certificate

CA 証明書を指定して再試行してください。 -v パラメータを追加すると、リクエストが成功したことがわかります。

 curl --cacert ca-cert.pem https://foo.example.com/headers --connect-to foo.example.com:443:$GATEWAY_IP:8000 -v * Connecting to hostname: 198.19.249.153 * Connecting to port: 8000 * Trying 198.19.249.153:8000... * Connected to 198.19.249.153 (198.19.249.153) port 8000 * ALPN: curl offers h2,http/1.1 * (304) (OUT), TLS handshake, Client hello (1): * CAfile: ca-cert.pem * CApath: none * (304) (IN), TLS handshake, Server hello (2): * (304) (IN), TLS handshake, Unknown (8): * (304) (IN), TLS handshake, Certificate (11): * (304) (IN), TLS handshake, CERT verify (15): * (304) (IN), TLS handshake, Finished (20): * (304) (OUT), TLS handshake, Finished (20): * SSL connection using TLSv1.3 / AEAD-CHACHA20-POLY1305-SHA256 * ALPN: server accepted h2 * Server certificate: * subject: O=flomesh-io; CN=foo.example.com * start date: May 8 14:59:33 2024 GMT * expire date: May 8 15:59:33 2024 GMT * common name: foo.example.com (matched) * issuer: CN=flomesh.io * SSL certificate verify ok. * using HTTP/2 * [HTTP/2] [1] OPENED stream for https://foo.example.com/headers * [HTTP/2] [1] [:method: GET] * [HTTP/2] [1] [:scheme: https] * [HTTP/2] [1] [:authority: foo.example.com] * [HTTP/2] [1] [:path: /headers] * [HTTP/2] [1] [user-agent: curl/8.4.0] * [HTTP/2] [1] [accept: */*] > GET /headers HTTP/2 > Host: foo.example.com > User-Agent: curl/8.4.0 > Accept: */* > < HTTP/2 200 < server: gunicorn/19.9.0 < date: Wed, 08 May 2024 15:00:07 GMT < content-type: application/json < content-length: 141 < access-control-allow-origin: * < access-control-allow-credentials: true < { "headers": { "Accept": "*/*", "Connection": "keep-alive", "Host": "foo.example.com", "User-Agent": "curl/8.4.0" } } * Connection #0 to host 198.19.249.153 left intact

デバッグ出力から TLS ハンドシェイクに関する詳細情報も確認できます。たとえば、証明書の有効期間の開始日は 2024 年 5 月 8 日 14:59:33 GMT、有効期限は 2024 年 5 月 8 日 15:59:33 GMT です。

1 分待ってから再度リクエストすると、証明書情報が更新されていることがわかります。この時点で、証明書リソースを調べると、証明書が実際にローテーションされたことを確認できます。

 kubectl describe certificate simple-gateway-cert . Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal Issuing 61s cert-manager-certificates-trigger Renewing certificate as renewal was scheduled at 2024-05-08 15:03:33 +0000 UTC Normal Requested 61s cert-manager-certificates-request-manager Created new CertificateRequest resource "simple-gateway-cert-1" Normal Issuing 1s cert-manager-certificates-trigger Renewing certificate as renewal was scheduled at 2024-05-08 15:04:33 +0000 UTC Normal Reused 1s (x2 over 61s) cert-manager-certificates-key-manager Reusing private key stored in existing Secret resource "simple-gateway-cert" Normal Requested 1s cert-manager-certificates-request-manager Created new CertificateRequest resource "simple-gateway-cert-2" Normal Issuing 1s (x2 over 61s) cert-manager-certificates-issuing The certificate has been successfully issued

要約する

cert-manager を使用して Kubernetes Gateway 証明書を自動的に管理すると、セキュリティと管理の効率が大幅に向上します。 cert-manager は、自動更新やローテーションなどの証明書処理を自動化することで、管理上の負担と人的エラーを軽減し、継続的なシステム セキュリティを確保します。このツールの統合性と柔軟性により、Kubernetes クラスターのセキュリティを維持するのに最適です。

参考文献

[1] KubernetesゲートウェイAPI: https://gateway-api.sigs.k8s.io/

[2] SIG-NETWORK: https://github.com/kubernetes/community/tree/master/sig-network

[3] KubernetesイングレスAPI: https://kubernetes.io/docs/concepts/services-networking/ingress/

[4] イングレス革命: https://static.sched.com/hosted_files/kccncna19/a5/Kubecon%2520San%2520Diego%25202019%2520-%2520Evolving%2520the%2520Kubernetes%2520Ingress%2520APIs%2520to%2520GA%2520and%2520Beyond%2520%255BPUBLIC%255D.pdf

[5] バージョン1.0.0: https://github.com/kubernetes-sigs/gateway-api/releases/tag/v1.0.0

[6] 1.1.0-rc2: https://github.com/kubernetes-sigs/gateway-api/releases/tag/v1.1.0-rc2

[7] 証明書マネージャー: https://cert-manager.io

[8] ボールト: https://www.vaultproject.io

[9] RustyVault: https://github.com/Tongsuo-Project/RustyVault

[10] FSMゲートウェイ: https://fsm-docs.flomesh.io/guides/traffic_management/ingress/fsm_gateway/

[11] ゲートウェイAPI実装: https://gateway-api.sigs.k8s.io/implementations/

[12] FSM: https://fsm-docs.flomesh.io/overview/

[13] TLSオフロード: https://fsm-docs.flomesh.io/guides/traffic_management/ingress/fsm_gateway/tls_termination/

[14] 複数の発行元: https://cert-manager.io/docs/configuration/issuers/

[15] FSMゲートウェイのインストールドキュメント: https://fsm-docs.flomesh.io/guides/traffic_management/ingress/fsm_gateway/installation/

<<:  マルチクラウドの時代には、ロックインのないニュートラルクラウドを採用すべき

>>:  コンテナ化の原則について話しましょう

推薦する

【翻訳】rel=canonical に関するよくある間違い 5 つ

Google は、次のアドレスで元のテキストを中国語に翻訳しています > Web ページにre...

モノのインターネットにおけるクラウドコンピューティングの応用を分析する

[[333057]]ガートナーによれば、現在、約 210 億個の接続された「モノ」が、必死にデータを...

weloveservers ロサンゼルスのハイエンド VPS 最終レビュー

これはおそらく、weloveservers.net が HostCat Blog に登場する最後の機...

2018 年のクラウドに関する 10 の予測

未来に焦点を当てるIT 環境が進化し、顧客が重要なアプリケーションとインフラストラクチャを大規模から...

驚きの発見:Racknerd の「ブラックフライデー」 VPS が利用可能、最低価格 8 ドル/年、オプションで 6 つのデータセンターあり

ウェブマスターは退屈して、racknerd の過去のプロモーションを調べていたところ、rackner...

次世代インターネットの開発を加速させるため、アリババはIPv6の大規模な適用を発表した。

IPv4 アドレスは枯渇に近づいています。次世代のインターネット技術として歓迎されている IPv6 ...

#BlackWeek5# a2hosting-3.3% オフ/仮想ホスト/SSD/SS/無制限のウェブサイト構築

大規模ホストのブラックフライデー プロモーションでは、a2hosting.com が独自の仮想ホスト...

セルフメディアはマーケティングに新たな変化をもたらすでしょうか?

「自メディア」という言葉は、WeChat大衆プラットフォームの登場後に生まれたようです。当時、程玲鋒...

フィリップ・コトラー:新しいテクノロジーの時代にはどのようなマーケティングのルールが変わりましたか?

はじめに: マーケティングは死んだのか? 最近の演説で、マーケティングの創始者はこれを否定しました。...

クラウド移行戦略を成功させる方法

しばらくデータセンターで運用してきた場合は、特定の目的のためにクラウド移行戦略に移行する可能性があり...

企業ウェブサイトの最適化に関する3つの提案の簡単な分析

移民労働者は長い間、SEOに関する記事を書いていません。最近オンラインマーケティングを勉強し始めたの...

ウェブマスターは、自分のウェブサイトにホームページのみを掲載するという「奇妙な現象」にどのように対処すべきでしょうか?

毎日ウェブサイトに収集されたコンテンツの量を確認することは、ウェブマスターがウェブサイトの健全性評価...

2019年コンテンツ起業市場レポート!

コンテンツ起業にとって、暖を取るために「お金を燃やして」脂肪を蓄えることは難しく、多くの企業が実践で...

JVM仮想マシンの全体構造とオブジェクトメモリ割り当ての分析

[[414275]] JVM仮想マシンの全体構造の分析全体構造の紹介jvm は次のように分かれていま...