Citrix ADC ingress controller

Citrix ingress controller を使用して Kubernetes に HTTPS Web アプリケーションをデプロイし、証明書マネージャーを使用して Let`s Encrypt を実行する

Let’s Encrypt と ACME (自動証明書管理環境) プロトコルを使用すると、HTTPS サーバーをセットアップし、ブラウザで信頼される証明書を自動的に取得できます。Let’s Encrypt からウェブサイトのドメインの証明書を取得するには、特定の課題を達成してドメインを管理していることを実証する必要があります。チャレンジとは、ドメインを管理している人だけが達成できる、指定されたタスクのリストの 1 つです。

現在、次の 2 種類の課題があります。

  • HTTP-01 チャレンジ:HTTP-01 チャレンジは、Web サイトの指定された場所に指定されたファイルを投稿することで完了します。Encrypt CA は、チャレンジを満たすために HTTP URI に HTTP リクエストを送信してファイルを検証してみましょう。

  • DNS-01 チャレンジ: DNS01 チャレンジは、DNS TXT レコードに存在する計算キーを提供することで完了します。この TXT レコードがインターネットに伝播されると、ACME サーバーは DNS ルックアップを通じてこのキーを正常に取得できます。ACME サーバーは、要求された証明書のドメインをクライアントが所有していることを検証できます。cert-manager は、適切な権限で、指定した DNS プロバイダーに対してこの TXT レコードを自動的に提示します。

チャレンジの検証に成功すると、ドメインの証明書が付与されます。

このトピックでは、以下を使用して HTTPS Web アプリケーションを Kubernetes クラスタに安全にデプロイする方法について説明します。

前提条件

以下を用意してください:

  • 証明書が要求されたドメインはパブリックにアクセス可能です。
  • Kubernetes クラスターで RBAC を有効にしました。
  • 階層1または階層2の展開モデルで展開されたCitrix ADC MPX、VPX、またはCPX。

    Tier 1展開モデルでは、Citrix ADC MPXまたはVPXがアプリケーションDelivery Controller(ADC)として使用されます。Kubernetes クラスターで実行されている Citrix ingress controller は、Kubernetes クラスターで実行されているサービスの仮想サービスを構成します。Citrix ADCは、Let’s Encryptが生成した証明書を使用して、パブリックにルーティング可能なIPアドレスで仮想サービスを実行し、クライアントトラフィックのSSLをオフロードします。

    Tier 2展開モデルでは、Kubernetesクラスターの外部で実行されているCitrix ADC(VPX/MPX)にTCPサービスが構成されます。このサービスは、Kubernetesクラスターで実行されているCitrix ADC CPXインスタンスにトラフィックを転送するために作成されます。Citrix ADC CPX はSSLセッションを終了し、トラフィックを実際のサービスポッドに負荷分散します。

  • Citrix ingress controller を展開しました。さまざまな導入シナリオについては、 ここをクリックしてください

  • Let’s Encrypt CA のファイアウォールの仮想 IP アドレスのポート 80 を開放し、HTTP01 チャレンジのドメインを検証しました。

  • ACME DNS01 チャレンジ用のウェブアプリケーションをホストする、ユーザーが管理する DNS ドメイン。

  • すべての展開ステップに対する管理者権限。権限が原因で障害が発生した場合は、管理者権限があることを確認してください。

証明書マネージャをインストールする

cert-manager をインストールするには、 cert-manager のインストールに関するドキュメントを参照してください

cert-manager は、マニフェストファイルまたは Helm チャートを使用してインストールできます。

cert-manager をインストールしたら、 インストールの確認の説明に従って、cert-manager が稼働していることを確認します

サンプル Web アプリケーションのデプロイ

以下を実行して、サンプル Web アプリケーションをデプロイします。

注:

このトピックでは、Kubernetes デモアプリケーションであるKuardを参考に使用します。

  1. 以下の設定で Kuard 用のデプロイ YAML ファイル (kuard-deployment.yaml) を作成します。

    
            apiVersion: apps/v1
            kind: Deployment
            metadata:
              labels:
                app: kuard
              name: kuard
            spec:
              replicas: 1
              selector:
                matchLabels:
                  app: kuard
              template:
                metadata:
                  labels:
                    app: kuard
                spec:
                  containers:
                  - image: gcr.io/kuar-demo/kuard-amd64:1
                    imagePullPolicy: Always
                    name: kuard
                    ports:
                    - containerPort: 8080
                      protocol: TCP
    <!--NeedCopy-->
    
  2. 次のコマンドを使用して、Kuard デプロイファイル (kuard-deployment.yaml) をクラスターにデプロイします。

    % kubectl create -f kuard-deployment.yaml

    deployment.extensions/kuard created
    

    % kubectl get pod -l app=kuard

    NAME                     READY   STATUS    RESTARTS   AGE
            
    kuard-6fc4d89bfb-djljt   1/1     Running   0          24s
    
  3. デプロイメント用のサービスを作成します。以下の設定で、service.yamlというファイルを作成します。

              apiVersion: v1
              kind: Service
              metadata:
                name: kuard
              spec:
                ports:
                - port: 80
                  targetPort: 8080
                  protocol: TCP
                selector:
                  app: kuard
      <!--NeedCopy-->
    
  4. 以下のコマンドを使用して、サービスをデプロイして検証します。

    % kubectl create -f service.yaml
    
    service/kuard created
    % kubectl get svc kuard
    NAME    TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE
    kuard   ClusterIP   10.103.49.171   <none>        80/TCP    13s
    
  5. Citrix ADC CPXまたはVPXにコンテンツスイッチング仮想サーバーとして展開されるIngressを作成して、このサービスを外部に公開します。

    注:

    kubernetes.io/ingress.classの値を、Citrix Ingressコントローラーが起動するIngressクラスに変更するようにします。

        apiVersion: networking.k8s.io/v1
        kind: Ingress
        metadata:
          annotations:
            kubernetes.io/ingress.class: citrix
          name: kuard
        spec:
          rules:
          - host: kuard.example.com
            http:
              paths:
              - backend:
                  service:
                    name: kuard
                    port:
                      number: 80
                path: /
                pathType: Prefix
    

注:

spec.rules.hostの値は、自分が管理するドメインに変更する必要があります。 トラフィックをCitrix ADC CPXまたはVPXにルーティングするためのDNSエントリが存在することを確認します。

  1. 以下のコマンドを使用して Ingress をデプロイします。

    % kubectl apply -f ingress.yml
    ingress.extensions/kuard created
    
    root@ubuntu-:~/cert-manager# kubectl get ingress
    NAME    HOSTS               ADDRESS   PORTS   AGE
    kuard   kuard.example.com             80      7s
    
  2. 次のコマンドを使用して、Citrix ADC CPXまたはVPXでIngressが構成されていることを確認します。

    $ kubectl exec -it cpx-ingress-5b85d7c69d-ngd72 /bin/bash
    
    root@cpx-ingress-55c88788fd-qd4rg:/# cli_script.sh 'show cs vserver'
    exec: show cs vserver
    1)  k8s-192.168.8.178_80_http (192.168.8.178:80) - HTTP Type: CONTENT
      State: UP
      Last state change was at Sat Jan  4 13:36:14 2020
      Time since last state change: 0 days, 00:18:01.950
      Client Idle Timeout: 180 sec
      Down state flush: ENABLED
      Disable Primary Vserver On Down : DISABLED
      Comment: uid=MPPL57E3AFY6NMNDGDKN2VT57HEZVOV53Z7DWKH44X2SGLIH4ZWQ====
      Appflow logging: ENABLED
      Port Rewrite : DISABLED
      State Update: DISABLED
      Default:  Content Precedence: RULE
      Vserver IP and Port insertion: OFF
      L2Conn: OFF Case Sensitivity: ON
      Authentication: OFF
      401 Based Authentication: OFF
      Push: DISABLED  Push VServer:
      Push Label Rule: none
      Persistence: NONE
      Listen Policy: NONE
      IcmpResponse: PASSIVE
      RHIstate:  PASSIVE
      Traffic Domain: 0
    Done
    
    root@cpx-ingress-55c88788fd-qd4rg/# exit
    exit
    
  3. curl コマンドを使用して、要求されたときに Web ページが正しく提供されていることを確認します。

    % curl -sS -D - kuard.example.com -o /dev/null
    HTTP/1.1 200 OK
    Content-Length: 1458
    Content-Type: text/html
    Date: Thu, 21 Feb 2019 09:09:05 GMT
    

HTTP チャレンジを使用して ACME 証明書の発行を設定する

このセクションでは、HTTP 検証を使用して ACME 証明書を発行する方法について説明します。DNS 検証を使用する場合は、 このセクションをスキップして次のセクションに進んでください

cert-manager を使用した HTTP 検証は、Let’s Encrypt からドメインの証明書を取得する簡単な方法です。この方法では、特定のファイルがドメインに存在することを確認して、ドメインの所有権を証明します。指定したパスで指定したファイルをパブリッシュできる場合は、ドメインを管理しているものとみなされます。

HTTP01 チャレンジプロバイダーで暗号化しよう ClusterIssuer をデプロイする

cert-manager は、設定用に 2 つの異なる CRD をサポートします。1つは1つの名前空間にスコープされるIssuer、もう1つはクラスター全体のスコープを持つClusterIssuerです。

Citrix ingress controller で任意の名前空間の Ingress を使用するには、を使用します ClusterIssuer。または、Ingressリソースを作成する名前空間ごとにIssuerを作成することもできます。

詳細については、 HTTP 検証に関するcert-manager のドキュメントを参照してください。

  1. 以下の設定で、issuer-letsencrypt-staging.yamlというファイルを作成します。

    apiVersion: cert-manager.io/v1alpha2
    kind: ClusterIssuer
    metadata:
      name: letsencrypt-staging
    spec:
      acme:
        # You must replace this email address with your own.
        # Let's Encrypt will use this to contact you about expiring
        # certificates, and issues related to your account.
        email: user@example.com
        server: https://acme-staging-v02.api.letsencrypt.org/directory
        privateKeySecretRef:
          # Secret resource used to store the account's private key.
          name: example-issuer-account-key
        # Add a single challenge solver, HTTP01 using citrix
        solvers:
        - http01:
            ingress:
              class: citrix
    

    spec.acme.solvers[].http01.ingress.class は、Citrix イングレスコントローラーの Ingress クラスを指します。Citrix ingress controller にIngressクラスがない場合は、このフィールドを指定する必要はありません。 注: これは cert-manager.io/v1alpha2 リソースのサンプルClusterissuerです。詳細については、 cert-manager http01 のドキュメントを参照してください

    ステージング Let’s Encrypt サーバーは偽の証明書を発行しますが、 本番サーバーの API レート制限に拘束されません。このアプローチにより、レート制限を気にせずに環境をセットアップしてテストすることができます。Let’s Encrypt プロダクションサーバでも同じ手順を繰り返すことができます。

  2. ファイルを編集して保存したら、以下のコマンドを使用してファイルをデプロイします。

    % kubectl apply -f issuer-letsencrypt-staging.yaml
    clusterissuer "letsencrypt-staging" created
    
  3. 発行者が作成され、ACME サーバーに登録されていることを確認します。

    % kubectl get issuer
    NAME                  AGE
    letsencrypt-staging   8d
    
  4. コマンドkubectl describe issuer letsencrypt-stagingを使用して、ClusterIssuerが正しく登録されていることを確認します:

    % kubectl describe issuer letsencrypt-staging
    
    Status:
      Acme:
        Uri:  https://acme-staging-v02.api.letsencrypt.org/acme/acct/8200869
      Conditions:
        Last Transition Time:  2019-02-11T12:06:31Z
        Message:               The ACME account was registered with the ACME server
        Reason:                ACMEAccountRegistered
        Status:                True
        Type:                  Ready
    

Ingress オブジェクトの証明書の発行

ClusterIssuerが正常に登録されると、Ingress ドメイン「kuard.example.com」の証明書を取得できます。

指定した Ingress リソースの証明書をリクエストするには、次の方法を使用します。

  • IngressオブジェクトにIngress-shim注釈を追加する。

  • certificate CRD オブジェクトを作成します。

1 つ目の方法はすばやく簡単ですが、証明書の更新に関してさらにカスタマイズと細分性が必要な場合は、2 番目の方法を選択できます。必要に応じて方法を選択できます。

IngressオブジェクトにIngress-shim注釈を追加する

この方法では、ACME サーバーに証明書をリクエストする Ingress オブジェクトに次の 2 つの注釈を追加します。

certmanager.io/cluster-issuer: "letsencrypt-staging"

注:

サポートされているすべての注釈は、supported-annotationsIngress-shimの cert-managerから入手できます。

また、シークレットを指定して TLS を使用するようにingress.yamlを変更します。

  apiVersion: networking.k8s.io/v1
  kind: Ingress
  metadata:
    annotations:
      certmanager.io/cluster-issuer: letsencrypt-staging
      kubernetes.io/ingress.class: citrix
    name: kuard
  spec:
    rules:
    - host: kuard.example.com
      http:
        paths:
        - backend:
            service:
              name: kuard
              port:
                number: 80
          pathType: Prefix
          path: /
    tls:
    - hosts:
      - kuard.example.com
      secretName: kuard-example-tls

cert-manager.io/cluster-issuer: "letsencrypt-staging"アノテーションは、Cert-manager に、 letsencrypt-staging クラスター全体の発行者を使用して Let’s Encrypt のステージングサーバーに証明書を要求するように指示します。Cert-Manager は、kuard.example.comの証明書のライフサイクルを管理するために使用するcertificateオブジェクトを作成します 。証明書オブジェクトのドメイン名とチャレンジメソッドの値は、Ingress オブジェクトから取得されます。Ingress がクラスターに存在する限り、Cert-Manager はシークレットの内容を管理します。

以下のコマンドを使用して、 ingress.yaml ファイルをデプロイします。

% kubectl apply -f ingress.yml

ingress.extensions/kuard configured
% kubectl get ingress kuard
NAME    HOSTS               ADDRESS   PORTS     AGE
kuard   kuard.example.com             80, 443   4h39m

証明書 CRD リソースを作成する

または、Ingress オブジェクトから独立した証明書 CRD オブジェクトを展開することもできます。「証明書」CRD のドキュメントは HTTP 検証にあります

  1. 次の設定でcertificate.yamlファイルを作成します。
        apiVersion: cert-manager.io/v1alpha2
        kind: Certificate
        metadata:
          name: example-com
          namespace: default
        spec:
          secretName: kuard-example-tls
          issuerRef:
            name: letsencrypt-staging
          commonName: kuard.example.com
          dnsNames:
          - www.kuard.example.com
   <!--NeedCopy-->
 `spec.secretName` キーは、証明書が正常に発行された際に証明書が保存されるシークレットの名前です。
  1. Kubernetesクラスタにcertificate.yamlファイルをデプロイします。

    kubectl create -f certificate.yaml
    certificate.cert-manager.io/example-com created
    
  2. 証明書カスタムリソースが、Ingress で指定された証明書を表す cert-manager によって作成されていることを確認します。数分後に ACME 検証がうまくいけば、証明書の「READY」ステータスが true に設定されます。

    % kubectl get certificates.cert-manager.io kuard-example-tls
    NAME                READY   SECRET              AGE
    kuard-example-tls   True    kuard-example-tls   3m44s
    
    
    % kubectl get certificates.cert-manager.io kuard-example-tls
    Name:         kuard-example-tls
    Namespace:    default
    Labels:       <none>
    Annotations:  <none>
    API Version:  cert-manager.io/v1alpha2
    Kind:         Certificate
    Metadata:
      Creation Timestamp:  2020-01-04T17:36:26Z
      Generation:          1
      Owner References:
        API Version:           extensions/v1beta1
        Block Owner Deletion:  true
        Controller:            true
        Kind:                  Ingress
        Name:                  kuard
        UID:                   2cafa1b4-2ef7-11ea-8ba9-06bea3f4b04a
      Resource Version:        81263
      Self Link:               /apis/cert-manager.io/v1alpha2/namespaces/default/certificates/kuard-example-tls
      UID:                     bbfa5e51-2f18-11ea-8ba9-06bea3f4b04a
    Spec:
      Dns Names:
        acme.cloudpst.net
      Issuer Ref:
        Group:      cert-manager.io
        Kind:       ClusterIssuer
        Name:       letsencrypt-staging
      Secret Name:  kuard-example-tls
    Status:
      Conditions:
        Last Transition Time:  2020-01-04T17:36:28Z
        Message:               Certificate is up to date and has not expired
        Reason:                Ready
        Status:                True
        Type:                  Ready
      Not After:               2020-04-03T16:36:27Z
    Events:
      Type    Reason        Age   From          Message
      ----    ------        ----  ----          -------
      Normal  GeneratedKey  24m   cert-manager  Generated a new private key
      Normal  Requested     24m   cert-manager  Created new CertificateRequest resource "kuard-example-tls-3030465986"
      Normal  Issued        24m   cert-manager  Certificate issued successfully
    
  3. シークレットリソースが作成されていることを確認します。

    % kubectl get secret  kuard-example-tls
      NAME                TYPE                DATA   AGE
      kuard-example-tls   kubernetes.io/tls   3      3m13s
    

DNS チャレンジを使用した ACME 証明書の発行

このセクションでは、DNS 検証を使用して Let’sEncrypt CA から ACME 証明書を取得する方法について説明します。DNS-01 チャレンジでは、DNS レコードを管理していることを証明することで、ドメインの所有権を証明できます。そのためには、ドメインの DNS レコードを管理できることを証明する特定のコンテンツを含む TXT レコードを作成します。DNS チャレンジと DNS チャレンジを展開する際のベストプラクティスの詳細については、「 技術的な詳細:ACME DNS チャレンジ検証の自動化の保護」を参照してください。

注:

この手順では 、route53を DNS プロバイダーとして使用します。他のプロバイダーについては、 DNS 検証の cert-manager ドキュメントを参照してください

DNS01 チャレンジプロバイダーで Let’s Encrypt ClusterIssuer をデプロイする

以下を実行して、DNS01チャレンジプロバイダーで Let’s Encrypt ClusterIssuerをデプロイします。

  1. AWS IAM ユーザーアカウントを作成し、シークレットアクセスキー ID とシークレットアクセスキーをダウンロードします。
  2. 次の IAM ポリシーをユーザーに付与します。

    Route53 アクセスポリシー

  3. Kubernetesシークレットacme-route53kube-system名前空間に作成します。

    % kubectl create secret generic acme-route53 --from-literal secret-access-key=<secret_access_key>
    
  4. DNS01 チャレンジプロバイダーでIssuerまたはClusterIssuerを作成します。

    DNS01 で複数のプロバイダーを指定し、証明書の作成時に使用するプロバイダーを指定できます。 cert-manager が TXT レコードを作成するには、DNS プロバイダーにアクセスできる必要があります。認証情報は、spec.dns01.secretAccessKeySecretRefで指定された Kubernetes シークレットに保存されます。認証情報の取得方法の詳細については、DNS プロバイダーのドキュメントを参照してください。

          apiVersion: cert-manager.io/v1alpha2
          kind: ClusterIssuer
          metadata:
            name: letsencrypt-staging
            spec:
              acme:
              # You must replace this email address with your own.
              # Let's Encrypt will use this to contact you about expiring
              # certificates, and issues related to your account.
                email: user@example.com
                server: https://acme-staging-v02.api.letsencrypt.org/directory
                privateKeySecretRef:
                  name: example-issuer-account-key
                solvers:
                - dns01:
                    route53:
                      region: us-west-2
                      accessKeyID: <IAMKEY>
                      secretAccessKeySecretRef:
                        name: acme-route53
                        key: secret-access-key
    <!--NeedCopy-->
    

    注:

    user@example.com を自分のメールアドレスに置き換えます。DNS01 スタンザで指定されたドメインごとに、cert-manager は参照された Issuer からのプロバイダの認証情報を使用して、_acme-challengeという名前の TXT レコードを作成します。このレコードは ACME サーバーによって検証され、証明書が発行されます。DNS プロバイダーの構成、およびサポートされるプロバイダーの一覧の詳細については、 DNS01 リファレンスドキュメントを参照してください

  5. ファイルを編集して保存したら、以下のコマンドを使用してファイルをデプロイします。

    % kubectl apply -f acme_clusterissuer_dns.yaml
    clusterissuer "letsencrypt-staging" created
    
  6. 以下のコマンドを使用して、発行者が作成され、ACME サーバーに登録されているかどうかを確認します。

    % kubectl get issuer
    NAME                  AGE
    letsencrypt-staging   8d
    
  7. kubectl describe issuer letsencrypt-stagingコマンドを使用して、ClusterIssuerが正しく登録されているかどうかを確認します:

    Status:
      Acme:
        Uri:  https://acme-staging-v02.api.letsencrypt.org/acme/acct/8200869
      Conditions:
        Last Transition Time:  2019-02-11T12:06:31Z
        Message:               The ACME account was registered with the ACME server
        Reason:                ACMEAccountRegistered
        Status:                True
        Type:                  Ready
    

Ingress リソースの証明書の発行

発行者が正常に登録されると、Ingress ドメインkuard.example.comの証明書を取得できます。HTTP01 チャレンジと同様に、指定した Ingress リソースの証明書をリクエストする方法は 2 つあります。

  • IngressオブジェクトにIngress-shim注釈を追加する。

  • certificate CRD オブジェクトを作成します。詳細な手順については、「 証明書 CRD リソースを作成する」を参照してください。

IngressオブジェクトへのIngress-shimアノテーションの追加

Ingressオブジェクトに次の注釈をspec.tlsセクションとともに追加します。

certmanager.io/cluster-issuer: "letsencrypt-staging"
<!--NeedCopy-->
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    cert-manager.io/cluster-issuer: letsencrypt-staging
    kubernetes.io/ingress.class: citrix
  name: kuard
spec:
  rules:
  - host: kuard.example.com
    http:
      paths:
      - backend:
          service:
            name: kuard
            port:
              number: 80
        pathType: Prefix
        path: /
  tls:
  - hosts:
    - kuard.example.com
    secretName: kuard-example-tls
<!--NeedCopy-->

証明書マネージャは DNS01 チャレンジで Certificate CRD リソースを作成します。ClusterIssuerで指定された認証情報を使用して、所有するドメインの TXT レコードを DNS サーバに作成します。その後、Let’s Encrypt CA は TXT レコードの内容を検証してチャレンジを完了します。

Certificate CRD リソース**を追加する

または、証明書カスタムリソース定義リソースを明示的に作成して、証明書の自動生成をトリガーすることもできます。

  1. 次の設定でcertificate.yamlファイルを作成します。

            apiVersion: cert-manager.io/v1alpha2
            kind: Certificate
            metadata:
              name: example-com
              namespace: default
            spec:
              secretName: kuard-example-tls
              issuerRef:
                name: letsencrypt-staging
              commonName: kuard.example.com
              dnsNames:
              - www.kuard.example.com
    <!--NeedCopy-->
    

    ドメイン名の検証に成功すると、証明書の READY ステータスは True に設定されます。

  2. 証明書が発行されたことを確認します。

    % kubectl get certificate kuard-example-tls
    
       NAME           READY   SECRET              AGE
       -example-tls   True    kuard-example-tls   10m
    

    次のコマンドを使用して、発行された証明書の進行状況を確認できます。

    % kubectl describe certificates kuard-example-tls | tail -n 6

       Not After:               2020-04-04T13:34:23Z
       Events:
       Type    Reason     Age    From          Message
       ----    ------     ----   ----          -------
       Normal  Requested  11m    cert-manager  Created new CertificateRequest resource "kuard-example-tls-3030465986"
       Normal  Issued     7m21s  cert-manager  Certificate issued successfully
    

Citrix ADCで証明書を確認する

Letsencrypt CA はドメインを正常に検証し、ドメインの新しい証明書を発行しました。 kubernetes.io/tls シークレットは、Ingressのtls:フィールドで指定されたsecretNameで作成されます。また、cert-manager は有効期限の 30 日前に自動的に更新を開始します。

HTTP チャレンジの場合、証明書マネージャーは一時的な Ingress リソースを作成し、Let’s Encrypt CA が生成したトラフィックを証明書マネージャーポッドにルーティングします。ドメインの検証に成功すると、この一時的な Ingress は削除されます。

  1. 以下のコマンドを使用して、シークレットが作成されたことを確認します。

    % kubectl get secret kuard-example-tls
    
    NAME                TYPE                DATA   AGE
    kuard-example-tls   kubernetes.io/tls   3      30m
    

    Citrix ingress controller はシークレットを取得し、証明書をCitrix ADC CPX上のコンテンツスイッチング仮想サーバーにバインドします。中間 CA 証明書がある場合は、SSL ネゴシエーション中にサーバ証明書に自動的にリンクされ、クライアントに提示されます。

  2. Citrix ADC CPX にログオンし、証明書がSSL仮想サーバーにバインドされているかどうかを確認します。

    % kubectl exec -it cpx-ingress-55c88788fd-n2x9r bash -c cpx-ingress
    Defaulting container name to cpx-ingress.
    Use 'kubectl describe pod/cpx-ingress-55c88788fd-n2x9r -n default' to see all of the containers in this pod.
    
    % cli_script.sh 'sh ssl vs k8s-192.168.8.178_443_ssl'
    exec: sh ssl vs k8s-192.168.8.178_443_ssl
    
      Advanced SSL configuration for VServer k8s-192.168.8.178_443_ssl:
      DH: DISABLED
      DH Private-Key Exponent Size Limit: DISABLED Ephemeral RSA: ENABLED  Refresh Count: 0
      Session Reuse: ENABLED  Timeout: 120 seconds
      Cipher Redirect: DISABLED
      ClearText Port: 0
      Client Auth: DISABLED
      SSL Redirect: DISABLED
      Non FIPS Ciphers: DISABLED
      SNI: ENABLED
      OCSP Stapling: DISABLED
      HSTS: DISABLED
      HSTS IncludeSubDomains: NO
      HSTS Max-Age: 0
      HSTS Preload: NO
      SSLv3: ENABLED  TLSv1.0: ENABLED  TLSv1.1: ENABLED  TLSv1.2: ENABLED  TLSv1.3: DISABLED
      Push Encryption Trigger: Always
      Send Close-Notify: YES
      Strict Sig-Digest Check: DISABLED
      Zero RTT Early Data: DISABLED
      DHE Key Exchange With PSK: NO
      Tickets Per Authentication Context: 1
    , P_256, P_384, P_224, P_5216) CertKey Name: k8s-GVWNYGVZKKRHKF7MZVTLOAEZYBS Server Certificate for SNI
    
    7) Cipher Name: DEFAULT
      Description: Default cipher list with encryption strength >= 128bit
    Done
    
    % cli_script.sh 'sh certkey'
    1) Name: k8s-GVWNYGVZKKRHKF7MZVTLOAEZYBS
      Cert Path: k8s-GVWNYGVZKKRHKF7MZVTLOAEZYBS.crt
      Key Path: k8s-GVWNYGVZKKRHKF7MZVTLOAEZYBS.key
      Format: PEM
      Status: Valid,   Days to expiration:89
      Certificate Expiry Monitor: ENABLED
      Expiry Notification period: 30 days
      Certificate Type: "Client Certificate" "Server Certificate"
      Version: 3
      Serial Number: 03B2B57EA9E61A93F1D05EA3272FA95203C2
      Signature Algorithm: sha256WithRSAEncryption
      Issuer:  C=US,O=Let's Encrypt,CN=Let's Encrypt Authority X3
      Validity
        Not Before: Jan  5 13:34:23 2020 GMT
        Not After : Apr  4 13:34:23 2020 GMT
      Subject:  CN=acme.cloudpst.net
      Public Key Algorithm: rsaEncryption
      Public Key size: 2048
      Ocsp Response Status: NONE
    2) Name: k8s-GVWNYGVZKKRHKF7MZVTLOAEZYBS_ic1
      Cert Path: k8s-GVWNYGVZKKRHKF7MZVTLOAEZYBS.crt_ic1
      Format: PEM
      Status: Valid,   Days to expiration:437
      Certificate Expiry Monitor: ENABLED
      Expiry Notification period: 30 days
      Certificate Type: "Intermediate CA"
      Version: 3
      Serial Number: 0A0141420000015385736A0B85ECA708
      Signature Algorithm: sha256WithRSAEncryption
      Issuer:  O=Digital Signature Trust Co.,CN=DST Root CA X3
      Validity
        Not Before: Mar 17 16:40:46 2016 GMT
        Not After : Mar 17 16:40:46 2021 GMT
      Subject:  C=US,O=Let's Encrypt,CN=Let's Encrypt Authority X3
      Public Key Algorithm: rsaEncryption
      Public Key size: 2048
      Ocsp Response Status: NONE
    Done
    

HTTPS ウェブサーバーは、偽の LE 署名付き証明書で稼働しています。次のステップは、実際の Let’s Encrypt 証明書を使用して本番環境に移行することです。

本番環境に移行

Let’s Encrypt-Staging でテストに成功すると、実際の Let’s Encrypt 証明書を取得できます。

Let’s Encryptエンドポイントをhttps:acme-staging-v02.api.letsencrypt.org/directoryからhttps:acme-v02.api.letsencrypt.org/directoryに変更する必要があります

次に、ClusterIssuerの名前をletsencrypt-stagingからletsencrypt-productionに変更します。


apiVersion: cert-manager.io/v1alpha2
kind: ClusterIssuer
metadata:
  name: letsencrypt-prod
spec:
  acme:
    # You must replace this email address with your own.
    # Let's Encrypt will use this to contact you about expiring
    # certificates, and issues related to your account.
    email: user@example.com
    server: https://acme-v02.api.letsencrypt.org/directory
    privateKeySecretRef:
      # Secret resource used to store the account's private key.
      name: example-issuer-account-key
    # Add a single challenge solver, HTTP01 using citrix
    solvers:
    - http01:
        ingress:
          class: citrix
<!--NeedCopy-->

注:

user@example.com を自分のメールアドレスに置き換えます。

以下のコマンドを使用して、ファイルをデプロイします。

% kubectl apply -f letsencrypt-prod.yaml

 clusterissuer "letsencrypt-prod" created

ここで、Ingress で注釈を変更するか、新しい証明書の生成をトリガーする CRD 証明書を作成する手順を繰り返します。

cert-manager が実稼働 CA との新しいチャレンジを開始できるように、必ず古いシークレットを削除してください。

% kubectl delete secret kuard-example-tls

 secret "kuard-example-tls" deleted

HTTP Web サイトが起動したら、Ingress オブジェクトのアノテーションingress.citrix.com/insecure-termination: redirectを使用して HTTP から HTTPSにトラフィックをリダイレクトできます。

トラブルシューティング

証明書の生成には複数のコンポーネントが含まれるため、この項では障害が発生した場合に使用できるトラブルシューティング手法についてまとめます。

証明書生成のステータスを確認する

証明書 CRD オブジェクトは、証明書の生成と更新のライフサイクル管理を定義します。証明書の状態は、以下のkubectl describeコマンドを使用して表示できます。

% kubectl get certificate

NAME                READY   SECRET              AGE
kuard-example-tls   False   kuard-example-tls   9s

%  kubectl describe certificate kuard-example-tls

Status:
  Conditions:
    Last Transition Time:  2019-03-05T09:50:29Z
    Message:               Certificate does not exist
    Reason:                NotFound
    Status:                False
    Type:                  Ready
Events:
  Type    Reason        Age   From          Message
  ----    ------        ----  ----          -------
  Normal  OrderCreated  22s   cert-manager  Created Order resource "kuard-example-tls-1754626579"

また、kubectl eventsコマンドを使用して、主要な証明書イベントを表示することもできます。

kubectl get events

LAST SEEN   TYPE     REASON              KIND          MESSAGE
36s         Normal   Started             Challenge     Challenge scheduled for processing
36s         Normal   Created             Order         Created Challenge resource "kuard-example-tls-1754626579-0" for domain "acme.cloudpst.net"
38s         Normal   OrderCreated        Certificate   Created Order resource "kuard-example-tls-1754626579"
38s         Normal   CreateCertificate   Ingress       Successfully created Certificate "kuard-example-tls"

証明書マネージャーからのログを分析する

障害が発生した場合、まず cert-manager コンポーネントのログを分析します。以下のコマンドを使用して cert-manager Pod を特定します。

% kubectl get po -n cert-manager

NAME                                    READY   STATUS      RESTARTS   AGE
cert-manager-76d48d47bf-5w4vx           1/1     Running     0          23h
cert-manager-webhook-67cfb86d56-6qtxr   1/1     Running     0          23h
cert-manager-webhook-ca-sync-x4q6f      0/1     Completed   4          23h

cert-manager-76d48d47bf-5w4vxがメインの証明書マネージャ Pod で、他の 2 つの Pod は証明書マネージャ Webhook Pod です。

以下のコマンドを使用して cert-manager のログを取得します。

% kubectl logs -f cert-manager-76d48d47bf-5w4vx -n cert-manager

証明書の取得に失敗した場合は、エラーログにその失敗に関する詳細が記録されます。

Kubernetes シークレットを確認する

kubectl describe コマンドを使用して、証明書とキーの両方が Kubernetes secret に入力されているかどうかを確認します。

% kubectl describe secret kuard-example-tls

Name:         kuard-example-tls
Namespace:    default
Labels:       certmanager.k8s.io/certificate-name=kuard-example-tls
Annotations:  certmanager.k8s.io/alt-names: acme.cloudpst.net
              certmanager.k8s.io/common-name: acme.cloudpst.net
              certmanager.k8s.io/issuer-kind: ClusterIssuer
              certmanager.k8s.io/issuer-name: letsencrypt-staging

Type:  kubernetes.io/tls

Data
====
tls.crt:  3553 bytes
tls.key:  1679 bytes
ca.crt:   0 bytes

tls.crttls.keyの両方が Kubernetes シークレットに入力されていれば、証明書の生成は完了です。 tls.key のみが存在する場合、証明書の生成は不完全です。証明書マネージャのログを分析して、問題の詳細を確認します。

Citrix ingress controller からのログを分析する

Kubernetesシークレットが生成され完了してもCitrix ADCにアップロードされない場合は、次のコマンドを使用してCitrix ingress controller からのログを分析できます。

% kubectl logs -f cpx-ingress-685c8bc976-zgz8q
Citrix ingress controller を使用して Kubernetes に HTTPS Web アプリケーションをデプロイし、証明書マネージャーを使用して Let`s Encrypt を実行する