ブログ | NGINX

Kubernetes 環境での証明書管理の自動化

ジェイソン・シュミット

2022年10月5日公開

有効な SSL/TLS 証明書は、現代のアプリケーション環境における中核的な要件です。残念ながら、証明書（または cert）の更新の管理は、アプリケーションを展開するときに後回しにされることがよくあります。証明書の有効期間は限られており、 DigiCert の証明書の場合は約 13 か月、 Let's Encrypt の証明書の場合は 90 日間です。安全なアクセスを維持するために、これらの証明書は有効期限が切れる前に更新/再発行する必要があります。ほとんどの運用チームの作業負荷が膨大であることを考えると、証明書の更新が見落とされ、証明書の有効期限が近づいたり、最悪の場合有効期限が過ぎたりすると、慌てることになりかねません。

こうなる必要はない。ある程度の計画と準備を行えば、証明書の管理を自動化し、効率化することができます。ここでは、次の 3 つのテクノロジーを使用した Kubernetes のソリューションについて説明します。

このブログでは、エンドポイントに一意の自動更新および更新された証明書を提供することで、証明書管理を簡素化する方法を学びます。

Kubernetes 環境における証明書

技術的な詳細に入る前に、いくつかの用語を定義する必要があります。「TLS 証明書」という用語は、Ingress コントローラーで HTTPS 接続を有効にするために必要な 2 つのコンポーネントを指します。

証明書
秘密鍵

証明書と秘密鍵は両方ともLet's Encryptによって発行されます。 TLS 証明書の仕組みの詳細については、DigiCert の投稿「TLS/SSL 証明書の仕組み」を参照してください。

Kubernetes では、これら 2 つのコンポーネントはSecretsとして保存されます。 NGINX Ingress Controllerやcert-managerなどの Kubernetes ワークロードは、これらの Secret の書き込みと読み取りを実行できます。また、Kubernetes インストールにアクセスできるユーザーがこれらの Secret を管理することもできます。

cert-manager の紹介

cert-managerプロジェクトは、Kubernetes および OpenShift で動作する証明書コントローラーです。 Kubernetes にデプロイされると、cert-manager は Ingress コントローラーに必要な証明書を自動的に発行し、それらが有効で最新であることを確認します。さらに、証明書の有効期限を追跡し、設定された時間間隔で更新を試みます。多数の公的および民間の発行者と連携しますが、ここでは Let's Encrypt との統合を紹介します。

2つのチャレンジタイプ

Let’s Encrypt を使用すると、すべての証明書管理が自動的に処理されます。これは非常に便利ですが、次のような問題も生じます。サービスはどのようにして、問題の完全修飾ドメイン名 (FQDN) を所有していることを保証しますか?

この問題はチャレンジを使用して解決されます。チャレンジでは、特定のドメインの DNS レコードにアクセスできるユーザーだけが提供できる検証要求に回答する必要があります。チャレンジには次の 2 つの形式があります。

HTTP-01 : この課題は、証明書を発行する FQDN の DNS レコードを用意することで解決できます。たとえば、サーバーの IP アドレスがwww.xxx.yyy.zzzで、FQDN が cert.example.com の場合、チャレンジメカニズムによって、 www.xxx.yyy.zzzのサーバー上のトークンが公開され、Let's Encrypt サーバーは cert.example.com 経由でそのトークンにアクセスしようとします。成功した場合、チャレンジは合格となり、証明書が発行されます。

HTTP-01 は、DNS プロバイダーへの直接アクセスを必要としないため、証明書を生成する最も簡単な方法です。このタイプのチャレンジは常にポート 80 (HTTP) 経由で実行されます。 HTTP-01 チャレンジを使用する場合、cert-manager は Ingress コントローラーを使用してチャレンジトークンを提供することに注意してください。

DNS-01 : このチャレンジにより、トークンを含む DNS TXT レコードが作成され、発行者によって検証されます。トークンが認識されると、そのドメインの所有権が証明され、そのレコードの証明書を発行できるようになります。 HTTP-01 チャレンジとは異なり、DNS-01 チャレンジを使用する場合、FQDN はサーバーの IP アドレスに解決される必要はなく (存在する必要もありません)。さらに、ポート 80 がブロックされている場合は DNS-01 を使用できます。この使いやすさの相殺として、cert-manager インストールへの API トークンを介して DNS インフラストラクチャへのアクセスを提供する必要があります。

イングレスコントローラ

Ingress コントローラーは、クラスター外部からトラフィックを取得し、それを内部Pod (1 つ以上のコンテナーのグループ) に負荷分散し、出力トラフィックを管理する Kubernetes 専用のサービスです。さらに、Ingress コントローラーは Kubernetes API を介して制御され、ポッドが追加、削除、または失敗すると、負荷分散構成を監視および更新します。

Ingress コントローラーの詳細については、次のブログをお読みください。

以下の例では、F5 NGINX によって開発および保守されている NGINX Ingress Controller を使用します。

証明書管理の例

これらの例では、テストに使用できる稼働中の Kubernetes インストールがあり、そのインストールで外部 IP アドレス (Kubernetes LoadBalancer オブジェクト) を割り当てることができることを前提としています。さらに、ポート 80 とポート 443 の両方 (HTTP-01 チャレンジを使用している場合)、またはポート 443 のみ (DNS-01 チャレンジを使用している場合) でトラフィックを受信できることを前提としています。これらの例は Mac OS X を使用して示されていますが、Linux または WSL でも使用できます。

また、A レコードを調整できる DNS プロバイダーと FQDN も必要になります。 HTTP-01 チャレンジを使用している場合は、A レコードを追加する機能 (または A レコードを追加してもらう機能) のみが必要です。 DNS-01 チャレンジを使用している場合は、サポートされている DNS プロバイダーまたはサポートされている Webhook プロバイダーへの API アクセスが必要になります。

NGINX Ingress Controller をデプロイする

最も簡単な方法は、 Helm経由でデプロイすることです。このデプロイメントでは、Kubernetes Ingress と NGINX 仮想サーバー CRD の両方を使用できます。

NGINX リポジトリを追加します。

$ helm repo add nginx-stable https://helm.nginx.com/stable  "nginx-stable" has been added to your repositories

リポジトリを更新します。

$ helm repo update  Hang tight while we grab the latest from your chart repositories...
  ...Successfully got an update from the "nginx-stable" chart repository
  Update Complete. ⎈Happy Helming!⎈

Ingress コントローラーをデプロイします。

$ helm install nginx-kic nginx-stable/nginx-ingress \  --namespace nginx-ingress  --set controller.enableCustomResources=true \ 
  --create-namespace  --set controller.enableCertManager=true 
  NAME: nginx-kic
  LAST DEPLOYED: Thu Sep  1 15:58:15 2022
  NAMESPACE: nginx-ingress
  STATUS: deployed
  REVISION: 1
  TEST SUITE: None
  NOTES:
  The NGINX Ingress Controller has been installed.

デプロイメントを確認し、Ingress コントローラの出力の IP アドレスを取得します。有効な IP アドレスがないと続行できないことに注意してください。

$ kubectl get deployments --namespace nginx-ingress  NAME                      READY   UP-TO-DATE   AVAILABLE   AGE
  nginx-kic-nginx-ingress   1/1     1            1           23s
  $ kubectl get services --namespace nginx-ingress
  NAME                      TYPE           CLUSTER-IP      EXTERNAL-IP    PORT(S)                      AGE
  nginx-kic-nginx-ingress   LoadBalancer   10.128.60.190   www.xxx.yyy.zzz   80:31526/TCP,443:32058/TCP   30s

DNS Aレコードを追加する

ここでのプロセスは DNS プロバイダーによって異なります。この DNS 名は Let's Encrypt サーバーから解決可能である必要があり、機能する前にレコードが伝播するまで待つ必要がある場合があります。詳細については、SiteGround の記事「DNS 伝播とは何か、なぜ時間がかかるのか?」を参照してください。

選択した FQDN を解決できたら、次のステップに進むことができます。

$ host cert.example.com  cert.example.com has address www.xxx.yyy.zzz

cert-manager をデプロイする

次のステップは、cert-manager の最新バージョンをデプロイすることです。ここでも、デプロイメントには Helm を使用します。

Helm リポジトリを追加します。

$ helm repo add jetstack https://charts.jetstack.io  "jetstack" has been added to your repositories

リポジトリを更新します。

$ helm repo update  Hang tight while we grab the latest from your chart repositories...
  ...Successfully got an update from the "nginx-stable" chart repository
  ...Successfully got an update from the "jetstack" chart repository
  Update Complete. ⎈Happy Helming!⎈

cert-manager をデプロイします。

$ helm install cert-manager jetstack/cert-manager \  --namespace cert-manager --create-namespace \
  --version v1.9.1  --set installCRDs=true 
  NAME: cert-manager
  LAST DEPLOYED: Thu Sep  1 16:01:52 2022 
  NAMESPACE: cert-manager
  STATUS: deployed
  REVISION: 1 
  TEST SUITE: None
  NOTES:
  cert-manager v1.9.1 has been deployed successfully!

  In order to begin issuing certificates, you will need to set up a ClusterIssuer
  or Issuer resource (for example, by creating a 'letsencrypt-staging' issuer).

  More information on the different types of issuers and how to configure them
  can be found in our documentation:

  https://cert-manager.io/docs/configuration/

  For information on how to configure cert-manager to automatically provision
  Certificates for Ingress resources, take a look at the `ingress-shim`
  documentation:

  https://cert-manager.io/docs/usage/ingress/

デプロイメントを検証します。

$ kubectl get deployments --namespace cert-manager  NAME                      READY   UP-TO-DATE   AVAILABLE   AGE
  cert-manager              1/1     1            1           4m30s
  cert-manager-cainjector   1/1     1            1           4m30s
  cert-manager-webhook      1/1     1            1           4m30s

NGINX Cafe サンプルをデプロイする

バックエンドのデプロイメントとサービスを提供するために、NGINX Cafe の例を使用します。これは、NGINX が提供するドキュメント内で使用される一般的な例です。この一部として Ingress をデプロイすることはありません。

NGINX Ingress GitHub プロジェクトをクローンします。

$ git clone https://github.com/nginxinc/kubernetes-ingress.git  Cloning into 'kubernetes-ingress'...
  remote: Enumerating objects: 44979, done.
  remote: Counting objects: 100% (172/172), done.
  remote: Compressing objects: 100% (108/108), done.
  remote: Total 44979 (delta 87), reused 120 (delta 63), pack-reused 44807
  Receiving objects: 100% (44979/44979), 60.27 MiB | 27.33 MiB/s, done.
  Resolving deltas: 100% (26508/26508), done.

サンプルディレクトリに変更します。このディレクトリには、Ingress コントローラーのさまざまな構成を示すいくつかの例が含まれています。ここでは、complete-example ディレクトリで提供されている例を使用します。

$ cd ./kubernetes-ingress/examples/ingress-resources/complete-example

NGINX Cafe の例をデプロイします。

$ kubectl apply -f ./cafe.yaml
  deployment.apps/coffee created
  service/coffee-svc created
  deployment.apps/tea created
  service/tea-svc created

kubectl get コマンドを使用して、デプロイメントとサービスを検証します。 Pod がREADYとして表示され、サービスがrunningとして表示されていることを確認します。以下の例は、あなたが探しているものの代表的なサンプルを示しています。 kubernetesサービスは、NGINX Cafe の例と同じ名前空間 (デフォルト) で実行されるシステムサービスであることに注意してください。

$ kubectl get deployments,services  --namespace default  NAME                     READY   UP-TO-DATE   AVAILABLE   AGE
  deployment.apps/coffee   2/2     2            2           69s
  deployment.apps/tea      3/3     3            3           68s
NAME                 TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)   AGE
  service/coffee-svc   ClusterIP   10.128.154.225   <none>        80/TCP    68s
  service/kubernetes   ClusterIP   10.128.0.1       <none>        443/TCP   29m
	service/tea-svc      ClusterIP   10.128.96.145    <none>        80/TCP    68s

ClusterIssuerをデプロイする

cert-manager 内では、 ClusterIssuer を使用して証明書を発行できます。これは、任意の名前空間から参照でき、定義された証明書発行機関による任意の証明書要求で使用できるクラスタースコープのオブジェクトです。この例では、Let's Encrypt 証明書のすべての証明書要求がこの ClusterIssuer によって処理されます。

選択したチャレンジタイプに合わせて ClusterIssuer をデプロイします。この投稿の範囲外ですが、ClusterIssuer で複数のリゾルバー (セレクターフィールドに基づいて選択) を指定できる高度な構成オプションがあります。

ACMEチャレンジの基本

自動証明書管理環境 (ACME) プロトコルは、ドメイン名を所有しているかどうか、また Let’s Encrypt 証明書を発行できるかどうかを判断するために使用されます。このチャレンジでは、渡す必要があるパラメータは次のとおりです。

メタデータ名: ClusterIssuer 名。Kubernetes インストール内で一意である必要があります。この名前は、後で証明書を発行するときに例の中で使用されます。
スペック.acme.email : これは、証明書を生成する目的で Let's Encrypt に登録するメールアドレスです。これはあなたのメールアドレスです。
spec.acme.privateKeySecretRef : プライベートキーシークレットリファレンス: これは、秘密鍵を保存するために使用する Kubernetes シークレットの名前です。
仕様.acme.solvers : これはそのままにしておく必要があります。これは、使用しているチャレンジのタイプ (または、ACME ではソルバーと呼ばれます) (HTTP-01 または DNS-01) と、どの Ingress クラスに適用する必要があるか (この場合は nginx) を示します。

HTTP-01の使用

この例では、HTTP-01 チャレンジを使用してドメインの所有権を証明し、証明書を受け取るように ClusterIssuer を設定する方法を示します。

チャレンジ用に HTTP-01 を使用して ClusterIssuer を作成します。

$ cat << EOF | kubectl apply -f   apiVersion: cert-manager.io/v1
  kind: ClusterIssuer
  metadata:
    name: prod-issuer
  spec:
    acme:
      email: example@example.com
      server: https://acme-v02.api.letsencrypt.org/directory
      privateKeySecretRef:
        name: prod-issuer-account-key
      solvers:
      - http01:
         ingress:
           class: nginx
  EOF
  clusterissuer.cert-manager.io/prod-issuer created

ClusterIssuer を検証します (準備完了として表示されます)。

$ kubectl get clusterissuer  NAME          READY   AGE
	prod-issuer   True    34s

DNS-01の使用

この例では、DNS-01 チャレンジを使用してドメインの所有権を認証するように ClusterIssuer を設定する方法を示します。 DNS プロバイダーによっては、トークンを保存するために Kubernetes Secret を使用する必要がある可能性があります。この例ではCloudflare を使用しています。名前空間の使用に注意してください。 cert-manager 名前空間にデプロイされる cert-manager アプリケーションは、 Secret にアクセスできる必要があります。

この例では、アカウントから作成できるCloudflare API トークンが必要になります。これを以下の行に入力する必要があります。 Cloudflare を使用していない場合は、プロバイダーのドキュメントに従う必要があります。

API トークンのシークレットを作成します。

$ cat << EOF | kubectl apply -f   apiVersion: v1
  kind: Secret
  metadata:
    name: cloudflare-api-token-secret
    namespace: cert-manager
  type: Opaque
  stringData:
    api-token: <API Token> 
  EOF

チャレンジ用に DNS-01 を使用して発行者を作成します。

$ cat << EOF | kubectl apply -f   apiVersion: cert-manager.io/v1
  kind: ClusterIssuer
  metadata:
    name: prod-issuer
  spec:
    acme:
      email: example@example.com
      server: https://acme-v02.api.letsencrypt.org/directory
      privateKeySecretRef:
        name: prod-issuer-account-key
      solvers:
        - dns01:
            cloudflare:
              apiTokenSecretRef:
                name: cloudflare-api-token-secret
                key: api-token
  EOF

発行者を検証します（準備完了として表示されます）。

$ kubectl get clusterissuer  NAME          READY   AGE
	prod-issuer   True    31m

Ingressをデプロイする

これが私たちが目指してきたポイント、つまりアプリケーション用の Ingress リソースのデプロイです。これにより、先ほどデプロイした NGINX Cafe アプリケーションにトラフィックがルーティングされます。

Kubernetes Ingressの使用

標準の Kubernetes Ingress リソースを使用している場合は、次のデプロイメント YAML を使用して Ingress を構成し、証明書を要求します。

apiVersion: networking.k8s.io/v1   kind: Ingress 
  metadata: 
    name: cafe-ingress 
    annotations: 
      cert-manager.io/cluster-issuer: prod-issuer 
      acme.cert-manager.io/http01-edit-in-place: "true" 
  spec: 
    ingressClassName: nginx 
    tls: 
    - hosts: 
      - cert.example.com 
      secretName: cafe-secret 
    rules: 
    - host: cert.example.com 
      http: 
        paths: 
        - path: /tea 
          pathType: Prefix 
          backend: 
            service: 
              name: tea-svc 
              port: 
                number: 80 
        - path: /coffee 
          pathType: Prefix 
          backend: 
            service: 
              name: coffee-svc 
              port: 
number: 80

マニフェストのいくつかの重要な部分を確認する価値があります。

呼び出される API は標準の Kubernetes Ingress です。
この構成の重要な部分は、 metadata.annotationsの下にあり、 acme.cert-manager.io /http01-edit-in-place を「true」に設定します。この値は必須であり、チャレンジの提供方法を調整します。詳細については、「サポートされている注釈」ドキュメントを参照してください。これは、マスター/ミニオン設定を使用して処理することもできます。
spec.ingressClassNameは、インストールして使用する NGINX Ingress コントローラーを参照します。
spec.tls.secret Kubernetes Secret リソースには、Let's Encrypt によって証明書が発行されたときに返される証明書キーが格納されます。
spec.tls.hostsとspec.rules.hostには、 cert.example.comのホスト名が指定されています。これは、ClusterIssuer が証明書を発行したホスト名です。
spec.rules.httpセクションでは、パスと、それらのパス上のリクエストを処理するバックエンドサービスを定義します。たとえば、 /teaへのトラフィックはtea-svcのポート 80 に送信されます。

インストールに合わせて上記のマニフェストを変更します。少なくとも、 spec.rules.hostとspec.tls.hostsの値を変更する必要がありますが、構成内のすべてのパラメータを確認する必要があります。
マニフェストを適用します。

$  kubectl apply -f ./cafe-virtual-server.yaml  virtualserver.k8s.nginx.org/cafe created

証明書が発行されるまでお待ちください。 READY フィールドの値が「True」であることを確認します。

$ kubectl get certificates  NAME                                      READY   SECRET        AGE
  certificate.cert-manager.io/cafe-secret   True    cafe-secret   37m

NGINX仮想サーバー/仮想ルートの使用

NGINX CRD を使用している場合は、次のデプロイメント YAML を使用して Ingress を構成する必要があります。

  apiVersion: k8s.nginx.org/v1 
  kind: VirtualServer 
  metadata: 
    name: cafe 
  spec: 
    host: cert.example.com 
    tls: 
      secret: cafe-secret 
      cert-manager: 
        cluster-issuer: prod-issuer 
    upstreams: 
      - name: tea 
        service: tea-svc 
        port: 80 
      - name: coffee 
        service: coffee-svc 
        port: 80 
    routes: 
      - path: /tea 
        action: 
          pass: tea 
      - path: /coffee 
        action: 
          pass: coffee

もう一度、マニフェストの重要な部分をいくつか確認しておく価値があります。

呼び出される API は、VirtualServer リソースの NGINX 固有の k8s.nginx.org/v1 です。
spec.tls.secret Kubernetes Secret リソースには、Let's Encrypt によって証明書が発行されたときに返される証明書キーが格納されます。
spec.hostには、ホスト名cert.example.comが指定されています。これは、ClusterIssuer が証明書を発行したホスト名です。
spec.upstreams の値は、ポートを含むバックエンドサービスを指します。
spec.routes は、ルートと、そのルートにヒットしたときに実行されるアクションの両方を定義します。

インストールに合わせて上記のマニフェストを変更します。少なくとも、 spec.host値の変更が必要になりますが、構成内のすべてのパラメータを確認する必要があります。
マニフェストを適用します。

$  kubectl apply -f ./cafe-virtual-server.yaml  virtualserver.k8s.nginx.org/cafe created

証明書が発行されるまでお待ちください。有効というステータスが表示されます。

$ kubectl get VirtualServers  NAME   STATE   HOST                    IP             PORTS      AGE
  cafe   Valid   cert.example.com   www.xxx.yyy.zzz   [80,443]   51m

証明書を見る

Kubernetes API を介して証明書を表示できます。これにより、証明書のサイズや関連付けられている秘密キーなど、証明書の詳細が表示されます。

$ kubectl describe secret cafe-secret  Name:         cafe-secret
  Namespace:    default
  Labels:       <none>
  Annotations:  cert-manager.io/alt-names: cert.example.com
                cert-manager.io/certificate-name: cafe-secret
                cert-manager.io/common-name: cert.example.com
                cert-manager.io/ip-sans:
                cert-manager.io/issuer-group:
                cert-manager.io/issuer-kind: ClusterIssuer
                cert-manager.io/issuer-name: prod-issuer
                cert-manager.io/uri-sans:Type:  kubernetes.io/tlsData
  ====
  tls.crt:  5607 bytes
  tls.key:  1675 bytes

実際の証明書とキーを確認したい場合は、次のコマンドを実行します。（注記：これは、Kubernetes Secrets の弱点を示しています。つまり、必要なアクセス権限を持つ人なら誰でも読み取ることができます。

$ kubectl get secret cafe-secret -o yaml

イングレスをテストする

証明書をテストします。ここでは任意の方法を使用できます。以下の例ではcURLを使用します。成功は、サーバー名、サーバーの内部アドレス、日付、選択された URI (ルート) (コーヒーまたは紅茶)、およびリクエスト ID を含む、前に示したものと同様のブロックによって示されます。失敗は、HTTP エラーコードの形式 (ほとんどの場合、400 または 301) になります。

$ curl https://cert.example.com/tea
  Server address: 10.2.0.6:8080
  Server name: tea-5c457db9-l4pvq
  Date: 02/Sep/2022:15:21:06 +0000
  URI: /tea
  Request ID: d736db9f696423c6212ffc70cd7ebecf
  $ curl https://cert.example.com/coffee
  Server address: 10.2.2.6:8080
  Server name: coffee-7c86d7d67c-kjddk
  Date: 02/Sep/2022:15:21:10 +0000
  URI: /coffee
Request ID: 4ea3aa1c87d2f1d80a706dde91f31d54

証明書の更新

当初、このアプローチにより証明書の更新を管理する必要がなくなると約束しました。ただし、その方法についてはまだ説明していません。なぜ？これは cert-manager のコアの組み込み部分だからです。この自動プロセスでは、証明書が存在しない、期限が切れている、有効期限が 15 日以内である、またはユーザーが CLI 経由で新しい証明書を要求していることを cert-manager が認識すると、新しい証明書が自動的に要求されます。それ以上に簡単なことはありません。

よくある質問

NGINX Plus についてはどうですか?

NGINX Plus サブスクライバーの場合、唯一の違いは NGINX Ingress Controller をインストールすることです。これを実現するために上記の Helm コマンドを変更する方法については、NGINX ドキュメントの「Helm のインストール」セクションを参照してください。

どのチャレンジタイプを使用すればよいですか?

これは主に使用事例によって異なります。

HTTP-01 チャレンジメソッドでは、ポート 80 がインターネットに対して開かれており、Ingress コントローラーの IP アドレスに対して DNS A レコードが適切に構成されている必要があります。この方法では、A レコードを作成する以外に DNS プロバイダーにアクセスする必要はありません。

DNS-01 チャレンジメソッドは、ポート 80 をインターネットに公開できない場合に使用でき、cert-manager が DNS プロバイダーへの出力アクセス権を持っていることのみが必要です。ただし、この方法では DNS プロバイダーの API にアクセスできる必要がありますが、必要なアクセスレベルはプロバイダーによって異なります。

問題をトラブルシューティングするにはどうすればよいですか?

Kubernetes は非常に複雑なため、対象を絞ったトラブルシューティング情報を提供することは困難です。問題が発生した場合は、 NGINX コミュニティ Slackで質問してください (NGINX Plus サブスクライバーは通常のサポートオプションを使用できます)。

今すぐ始めましょう

まずは、NGINX App Protect WAF および DoS を備えた NGINX Ingress Controller の30 日間無料トライアルをリクエストし、常時無料の NGINX Service Meshをダウンロードしてください。

F5 NGINX に関するブログ投稿をもっと読む ›

「このブログ投稿には、入手できなくなった製品やサポートされなくなった製品が参照されている場合があります。利用可能な F5 NGINX 製品およびソリューションに関する最新情報については、 NGINX 製品ファミリーをご覧ください。 NGINX は現在 F5 の一部です。 q。"

検索結果の提案

Kubernetes 環境での証明書管理の自動化

Kubernetes 環境における証明書

cert-manager の紹介

2つのチャレンジタイプ

イングレスコントローラ

証明書管理の例

NGINX Ingress Controller をデプロイする

DNS Aレコードを追加する

cert-manager をデプロイする

NGINX Cafe サンプルをデプロイする

ClusterIssuerをデプロイする

ACMEチャレンジの基本

HTTP-01の使用

DNS-01の使用

Ingressをデプロイする

Kubernetes Ingressの使用

NGINX仮想サーバー/仮想ルートの使用

証明書を見る

イングレスをテストする

証明書の更新

よくある質問

NGINX Plus についてはどうですか?

どのチャレンジタイプを使用すればよいですか?

問題をトラブルシューティングするにはどうすればよいですか?

今すぐ始めましょう

あらゆるアプリを安全に配信しましょう

Kubernetes 環境での証明書管理の自動化

Kubernetes 環境における証明書

cert-manager の紹介

2つのチャレンジタイプ

イングレス コントローラ

証明書管理の例

NGINX Ingress Controller をデプロイする

DNS Aレコードを追加する

cert-manager をデプロイする

NGINX Cafe サンプルをデプロイする

ClusterIssuerをデプロイする

ACMEチャレンジの基本

HTTP-01の使用

DNS-01の使用

Ingressをデプロイする

Kubernetes Ingressの使用

NGINX仮想サーバー/仮想ルートの使用

証明書を見る

イングレスをテストする

証明書の更新

よくある質問

NGINX Plus についてはどうですか?

どのチャレンジタイプを使用すればよいですか?

問題をトラブルシューティングするにはどうすればよいですか?

今すぐ始めましょう

あらゆるアプリを安全に配信しましょう

F5の情報を入手

イングレスコントローラ