すべてのプロダクト
Search

このプロダクト

    Alibaba Cloud Service Mesh:ACME CA を使用して ASM イングレスゲートウェイの証明書を発行する

    ドキュメントセンター

    Alibaba Cloud Service Mesh:ACME CA を使用して ASM イングレスゲートウェイの証明書を発行する

    最終更新日:Apr 09, 2025

    Automatic Certificate Management Environment (ACME) は、X.509 証明書の発行を自動化するためのプロトコルです。ACME プロトコルを使用すると、認証局 (CA) は証明書の申請者がドメインを所有していることを自動的に検証し、申請者に証明書を発行します。Let's Encrypt は、ACME プロトコルを使用して、ほとんどのブラウザで信頼されている証明書を発行する非営利の公開 CA です。このトピックでは、cert-manager と Let's Encrypt を併用して、Service Mesh (ASM) イングレスゲートウェイのブラウザ信頼 HTTPS 証明書を発行する方法について説明します。

    前提条件

    cert-manager の ACME

    cert-manager を使用すると、ACME Issuer は ACME プロトコルをサポートする CA サーバーにアカウントを登録します。ACME Issuer リソースを作成すると、cert-manager は秘密鍵を生成します。この秘密鍵は、ACME CA サーバーとの安全な通信に使用されます。Let's Encrypt などの公開 CA によって発行された証明書は、通常、クライアントの Web ブラウザで信頼されています。これは、ユーザーがブラウザを介して Web サイトにアクセスすると、ブラウザが Web サイトの Secure Sockets Layer (SSL) および Transport Layer Security (TLS) 証明書を自動的に信頼することを意味します。公開 CA によって発行された証明書の主な目的は、現在のサーバーがドメインの正当なサービスプロバイダーであることをブラウザに証明することです。このため、公開 CA は、証明書を申請するサーバーが実際にドメインを所有していることを検証してから、証明書を発行する必要があります。ACME プロトコルの詳細については、「Automatic Certificate Management Environment」をご参照ください。

    チャレンジの解決

    チャレンジは、証明書の申請者が証明書のドメインを所有していることを検証するために ACME プロトコルで使用される重要なメカニズムです。証明書の申請プロセスでは、ACME CA サーバーは、クライアント (証明書の申請者) が特定のチャレンジを完了して、ドメインの正当な所有者のみが対応する証明書を正常に申請できるようにすることを要求します。これにより、ネットワークセキュリティが向上し、ドメインのなりすましのリスクが防止されます。 cert-manager は、次の主要なチャレンジタイプをサポートしています。HTTP-01 チャレンジと DNS-01 チャレンジ。

    • HTTP-01 チャレンジは、計算されたキーを提示することで完了します。キーは HTTP URL エンドポイントに存在し、インターネット経由でルーティング可能です。この URL は、証明書に要求されたドメインを使用します。ACME サーバーがこのキーをインターネット経由でこの URL から取得できるようになると、ACME サーバーは申請者がこのドメインの所有者であることを検証できます。HTTP-01 チャレンジが作成されると、cert-manager は、この URL のトラフィックをこのキーを提示する小さな Web サーバーにルーティングするようにクラスタイングレスを自動的に構成します。小さな Web サーバーは、このキーを返すことによって、ACME サーバーによって開始されたチャレンジ検証リクエストに応答します。

    • DNS-01 チャレンジは、ドメインネームシステム (DNS) TXT レコードに存在する計算されたキーを提供することで完了します。この TXT レコードがインターネット全体に伝播された後、ACME サーバーは DNS ルックアップを介してこのキーを正常に取得し、申請者が要求された証明書のドメインを所有していることを検証できます。適切な権限があれば、cert-manager は DNS プロバイダーのこの TXT レコードを自動的に提示します。

    説明

    実際の使用シナリオでは、現在の CA が ACME プロトコルをサポートしているかどうかを確認する必要があります。CA が ACME プロトコルをサポートしている場合、ASM イングレスゲートウェイは cert-manager を使用して CA から証明書を自動的に取得できます。たとえば、Sectigo は ACME プロトコルをサポートしています。Sectigo の動作方法は、このトピックで説明されている方法と似ています。

    手順 1：パブリックドメインを準備する

    Let's Encrypt を使用してドメインの証明書を発行するには、パブリックドメインを用意し、そのパブリックドメインを使用する ASM イングレスゲートウェイにポイントする必要があります。詳細については、DNS プロバイダーのドキュメントをご参照ください。Alibaba Cloud DNS を使用している場合は、「DNS レコードの追加」をご参照ください。Let's Encrypt の詳細については、「Getting Started」をご参照ください。

    手順 2：Issuer リソースを作成して cert-manager を Let's Encrypt に接続する

    1. ASM インスタンスに追加したデータプレーン上の ACK クラスタの kubeconfig ファイルを使用して、次のコードブロックに示されているリソースを作成します。

      apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
  name: letsencrypt-prod-issuer
  namespace: istio-system
spec:
  acme:
    email: 'te**@mail.com'    # このフィールドはオプションですが、指定することをお勧めします。ACME サーバーは、このメールアドレスを介して証明書関連の重要な通知を送信する場合があります。
    privateKeySecretRef:
      name: letsencrypt-prod
    server: https://acme-v02.api.letsencrypt.org/directory
    solvers:
    - http01:
        ingress:
          ingressClassName: istio

      上記の Issuer リソースは、http01 タイプのソルバーを指定します。Ingress API アクセスが有効になっており、ingressClassName フィールドの値は istio です。次の手順では、このソルバーがどのように有効になるかを説明します。

      説明

      cert-manager は、Ingress API と Gateway API の 2 つのタイプのソルバーをサポートしています。ASM もこれらの 2 つの API をサポートしています。この例では、Ingress API が使用されています。

    2. Issuer リソースの準備ができるまで待ちます。次のコマンドを実行して、Issuer リソースのステータスを確認します。

      kubectl -n istio-system get issuer letsencrypt-prod-issuer

      予期される出力：

      NAME                      READY   AGE
letsencrypt-prod-issuer   True    8m3s

    手順 3：ASM イングレスゲートウェイの証明書を発行する

    1. ASM インスタンスに追加したデータプレーン上の ACK クラスタの kubeconfig ファイルを使用して、次のコードブロックに示されているリソースを作成します。

      apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: istio-ingressgateway-certs
  namespace: istio-system
spec:
  dnsNames:
  - ${テストドメイン} # test.com
  issuerRef:
    group: cert-manager.io
    kind: Issuer
    name: letsencrypt-prod-issuer
  secretName: istio-ingressgateway-certs

    2. Certificate リソースの準備ができるまで待ちます。次のコマンドを実行して、Certificate リソースのステータスを確認します。

      kubectl -n istio-system get certificate istio-ingressgateway-certs

      予期される出力：

      NAME                         READY   SECRET                       AGE
istio-ingressgateway-certs   True    istio-ingressgateway-certs   59m

    証明書の発行プロセス

    Certificate リソースを作成すると、cert-manager は作成された Issuer リソースを使用して、Certificate リソースで指定したドメインの証明書を発行します。このプロセス中に、構成されたソルバーが有効になります。

    Let's Encrypt は、現在のサーバーが証明書で指定したドメインの所有者であることを検証するために HTTP-01 チャレンジを開始します。これを行うために、Let's Encrypt はこのドメインに HTTP リクエストを送信します。ドメインの所有権を検証する前に、有効なレスポンスを取得する必要があります。この例では、ASM イングレスゲートウェイには HTTPBin ルーティングルールのみが構成されています。ASM イングレスゲートウェイには、チャレンジ関連の構成は構成されていません。Let's Encrypt はチャレンジ検証リクエストを送信しましたか？リクエストはどのように応答されますか？

    次のコマンドを実行して、ASM イングレスゲートウェイのアクセスログを表示できます。次に、Let's Encrypt が ASM イングレスゲートウェイにチャレンジ検証リクエストを送信したかどうかを判断できます。

    kubectl -n istio-system logs ${ASM イングレスゲートウェイ Pod の名前} | grep letsencrypt | tail -1

    予期される出力を表示する

    {

    "authority_for": "xxxxxxx",

    "bytes_received": "0",

    "bytes_sent": "87",

    "downstream_local_address": "xx.xx.xx.xx:80",

    "downstream_remote_address": "xx.xx.xx.xx:57101",

    "duration": "0",

    "istio_policy_status": "-",

    "method": "GET",

    "path": "/.well-known/acme-challenge/JfKvfdSNmkR7UqmCQU0OSkJC3EsnP4ZUiCc28OLLLxA",

    "protocol": "HTTP/1.1",

    "request_id": "e6806d08-0469-4383-be8e-4d7506b39ec5",

    "requested_server_name": "-",

    "response_code": "200",

    "response_flags": "-",

    "route_name": "-",

    "start_time": "2024-04-08T12:04:06.153Z",

    "trace_id": "-",

    "upstream_cluster": "outbound|8089||cm-acme-http-solver-c4ch9.istio-system.svc.cluster.local",

    "upstream_host": "xx.xx.xx.xx:8089",

    "upstream_local_address": "xx.xx.xx.xx:55886",

    "upstream_response_time": "0",

    "upstream_service_time": "0",

    "upstream_transport_failure_reason": "-",

    "user_agent": "Mozilla/5.0 (compatible; Let's Encrypt validation server; +https://www.letsencrypt.org)",

    "x_forwarded_for": "xx.xx.xx.xx"

}

    出力は、Let's Encrypt が ASM イングレスゲートウェイにチャレンジ検証リクエストを送信し、リクエストが正常にレスポンスされたことを示しています。Issuer リソースでは、ingressClassName フィールドが istio に設定されています。したがって、cert-manager は ingressClassName が istio である Ingress リソースを自動的に作成し、チャレンジ検証リクエストを cert-manager のソルバーに転送してドメイン所有権の検証を完了します。

    Certificate リソースの準備ができた後、kubectl -n istio-system get ingress コマンドを実行しても、関連する Ingress リソースを表示することはできません。理由は、証明書が発行された後、cert-manager は Ingress、Service、Deployment リソースなどのソルバー関連のリソースを自動的に削除するためです。

    手順 4：Let's Encrypt によって発行された証明書を確認する

    1. 次のコードブロックに示されている Istio ゲートウェイを作成します。手順 3 で生成された証明書を ASM イングレスゲートウェイのポート 443 に構成します。詳細については、「Istio ゲートウェイの管理」をご参照ください。

      apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
  name: httpbin-https
  namespace: default
spec:
  selector:
    istio: ingressgateway
  servers:
  - hosts:
    - ${テストドメイン}
    port:
      name: https
      number: 443
      protocol: HTTPS
    tls:
      credentialName: istio-ingressgateway-certs
      mode: SIMPLE

    2. 元の httpbin-vs 仮想サービスを、次のコードブロックに示されている内容に変更します。詳細については、「仮想サービスの管理」をご参照ください。

      apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: httpbin-vs
  namespace: default
spec:
  gateways:
    - httpbin
    -httpbin-https # この行を追加します。
  hosts:
    - '*'
  http:
    - name: test
      route:
        - destination:
            host: httpbin.default.svc.cluster.local
            port:
              number: 8000

    3. https://${テストドメイン} をブラウザのアドレスバーに入力します。

      ブラウザのアドレスバーは、次の図のようになります。image アイコンをクリックします。接続は安全ですと表示され、ブラウザが証明書を信頼していることを示します。

      image