Citrix ADC ingress controller

証明書マネージャーを使用して、Citrix ingress controller と HashiCorp Vault を使用して Kubernetes に HTTPS ウェブアプリケーションをデプロイする

Citrix イングレスコントローラーでデプロイされたイングレスリソースの場合、cert-manager と HashiCorp Vault を使用して TLS 証明書のプロビジョニング、失効、および更新を自動化できます。このトピックでは、cert-manager からの証明書署名要求に対して HashiCorp Vault を自己署名認証局として使用するワークフローの例を示します。

具体的には、Vault PKI シークレットエンジンを使用して認証局 (CA) を作成します。このチュートリアルでは、Vault サーバがインストールされ、Kubernetes クラスタから到達可能であることを前提としています。Vault の PKI シークレットエンジンは、内部アプリケーションに適しています。パブリックトラストを必要とする外部向けアプリケーションについては、 Let’s Encrypt CA を使用した TLS 証明書の自動化を参照してください

このワークフローでは、Vault シークレットエンジンと認証方法を使用します。Vault の全機能の一覧については、次の Vault ドキュメントを参照してください。

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

前提条件

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

  • Vault サーバがインストールされ、シール解除され、Kubernetes クラスタから到達可能になります。Vault サーバのインストールについては、Vault のインストールに関するドキュメントを参照してください。

  • Kubernetes クラスターで RBAC を有効にしました。

  • Citrix ADC MPX、VPX、またはCPXをティア1またはティア2の展開モデルで展開しました。

    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 を展開しました。 さまざまな展開シナリオについては、「展開トポロジ 」を参照してください。

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

注:

次の手順は、Citrix ADC CPX をイングレスデバイスとして使用して、Vaultを認証局として構成する手順を示しています。Citrix ADC VPXまたはMPXを入力デバイスとして使用する場合、Citrix ADCでイングレス構成を確認する手順を除いて手順は同じです。

マニフェストファイルを使用して cert-manager をデプロイする

提供された YAML マニフェストファイルを使用して cert-manager をデプロイするには、次の手順を実行します。

  1. 証明書マネージャをインストールします。cert-manager のインストールについては、 cert-manager のドキュメントを参照してください

    kubectl apply -f https://github.com/jetstack/cert-manager/releases/download/vx.x.x/cert-manager.yaml
    

    Helm で証明書マネージャをインストールすることもできます。詳細については、 cert-manager のドキュメントを参照してください

  2. 以下のコマンドを使用して、cert-manager が稼働中であることを確認します。

    % kubectl -n cert-manager get all
    NAME                                       READY   STATUS    RESTARTS   AGE
    pod/cert-manager-77fd74fb64-d68v7          1/1     Running   0          4m41s
    pod/cert-manager-webhook-67bf86d45-k77jj   1/1     Running   0          4m41s
    
    NAME                           TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)   AGE
    service/cert-manager-webhook   ClusterIP   10.108.161.154   <none>        443/TCP   13d
    
    NAME                                   READY   UP-TO-DATE   AVAILABLE   AGE
    deployment.apps/cert-manager           1/1     1            1           13d
    deployment.apps/cert-manager-webhook   1/1     1            1           13d
    
    NAME                                             DESIRED   CURRENT   READY   AGE
    replicaset.apps/cert-manager-77fd74fb64          1         1         1       13d
    replicaset.apps/cert-manager-webhook-67bf86d45   1         1         1       13d
    
    NAME                                                COMPLETIONS   DURATION   AGE
    job.batch/cert-manager-webhook-ca-sync              1/1           22s        13d
    job.batch/cert-manager-webhook-ca-sync-1549756800   1/1           21s        10d
    job.batch/cert-manager-webhook-ca-sync-1550361600   1/1           19s        3d8h
    
    NAME                                         SCHEDULE   SUSPEND   ACTIVE   LAST SCHEDULE   AGE
    cronjob.batch/cert-manager-webhook-ca-sync   @weekly    False     0        3d8h            13d
    

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

サンプル Web アプリケーションをデプロイするには、次の手順を実行します。

注:

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

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

    
            apiVersion: apps/v1
            kind: Deployment
            metadata:
              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
    <!--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
     <!--NeedCopy-->
    

    注:

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

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

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

    kubectl exec -it cpx-ingress-5b85d7c69d-ngd72 /bin/bash
    root@cpx-ingress-5b85d7c69d-ngd72:/# cli_script.sh 'sh cs vs'
    exec: sh cs vs
    1) k8s-10.244.1.50:80:http (10.244.1.50:80) - HTTP Type: CONTENT
      State: UP
      Last state change was at Thu Feb 21 09:02:14 2019
      Time since last state change: 0 days, 00:00:41.140
      Client Idle Timeout: 180 sec
      Down state flush: ENABLED
      Disable Primary Vserver On Down : DISABLED
      Comment: uid=75VBGFO7NZXV7SCI4LSDJML2Q5X6FSNK6NXQPWGMDOYGBW2IMOGQ====
      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
      Listen Policy: NONE
      IcmpResponse: PASSIVE
      RHIstate:  PASSIVE
      Traffic Domain: 0
    Done
    root@cpx-ingress-5b85d7c69d-ngd72:/# exit
    exit
    
  8. curl コマンドを使用して、要求されたときに、ページが正しく提供されているかどうかを確認します。

    % 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 アプリケーションをデプロイしたら、HTTPS 経由でアプリケーションを使用できるようにすることができます。ここで、Vault サーバは cert-manager によって生成された CSR に署名し、アプリケーション用のサーバ証明書が自動的に生成されます。

次の手順では、設定された Vault を認証局として使用し、証明書マネージャが Vault を CSR の署名機関として使用するように設定します。

HashiCorp ボールトを認証局として設定する

この手順では、HashiCorp Vault を使用して中間 CA 証明書署名要求をセットアップします。この Vault エンドポイントは、証明書マネージャが Ingress リソースの証明書に署名するために使用されます。

注:

これらの手順を実行する前に、 jq ユーティリティがインストールされていることを確認してください。

ルート CA を作成する

サンプルワークフローでは、Vault 内に独自のルート認証局を生成できます。実稼働環境では、外部ルート CA を使用して、Vault が証明書を生成するために使用する中間 CA に署名する必要があります。ルート CA が別の場所で生成されている場合は、この手順を省略してください。

注:

PKI_ROOTはルート CA をマウントするパスで、通常はpkiです 。このプロシージャの $ {DOMAIN} は example.comです


% export DOMAIN=example.com
% export PKI_ROOT=pki

% vault secrets enable -path="${PKI_ROOT}" pki

# Set the max TTL for the root CA to 10 years
% vault secrets tune -max-lease-ttl=87600h "${PKI_ROOT}"

% vault write -format=json "${PKI_ROOT}"/root/generate/internal \
 common_name="${DOMAIN} CA root" ttl=87600h | tee \
>(jq -r .data.certificate > ca.pem) \
>(jq -r .data.issuing_ca > issuing_ca.pem) \
>(jq -r .data.private_key > ca-key.pem)

#Configure the CA and CRL URLs:

% vault write "${PKI_ROOT}"/config/urls \
       issuing_certificates="${VAULT_ADDR}/v1/${PKI_ROOT}/ca" \
       crl_distribution_points="${VAULT_ADDR}/v1/${PKI_ROOT}/crl"
<!--NeedCopy-->

中間 CA を生成する

ルート CA を作成したら、次の手順を実行して、ルート CA を使用して中間 CSR を作成します。

  1. ルート CA、通常pki\_int、とは異なるパスPKI_INTから pki を有効にします。次のコマンドを使用します:

        % export PKI_INT=pki_int
        % vault secrets enable -path=${PKI_INT} pki
    
        # Set the max TTL to 3 year
    
        % vault secrets tune -max-lease-ttl=26280h ${PKI_INT}
       <!--NeedCopy-->
    
  2. ルート CAによって署名される必要がある${DOMAIN}の CSR を生成します。キーは Vault の内部に保存されます。次のコマンドを使用します:

          % vault write -format=json "${PKI_INT}"/intermediate/generate/internal \
          common_name="${DOMAIN} CA intermediate" ttl=26280h | tee \
          >(jq -r .data.csr > pki_int.csr) \
          >(jq -r .data.private_key > pki_int.pem)
    
       <!--NeedCopy-->
    
  3. ルート CAを使用して${DOMAIN}証明書を中間 CA として生成して署名し、intermediate.cert.pemとして保存します。次のコマンドを使用します:

        % vault write -format=json "${PKI_ROOT}"/root/sign-intermediate csr=@pki_int.csr
                format=pem_bundle ttl=26280h \
                | jq -r '.data.certificate' > intermediate.cert.pem
      <!--NeedCopy-->
    

    外部ルート CA を使用している場合は、前の手順をスキップして、ルート CA を使用して CSR に手動で署名します。

  4. CSR が署名され、ルート CA が証明書を返したら、次のコマンドを使用して、証明書を Vault に再度追加する必要があります。

        % vault write "${PKI_INT}"/intermediate/set-signed certificate=@intermediate.cert.pem
      <!--NeedCopy-->
    
  5. 次のコマンドを使用して CA と CRL の場所を設定します。

        vault write "${PKI_INT}"/config/urls issuing_certificates="${VAULT_ADDR}/v1/${PKI_INT}/ca" crl_distribution_points="${VAULT_ADDR}/v1/${PKI_INT}/crl"
      <!--NeedCopy-->
    

中間 CA が設定され、Ingress リソースの証明書に署名するために使用できます。

ロールを構成する

ロールは、ポリシーにマッピングされる論理名です。管理者は、ロールを通じて証明書の生成を制御できます。

この CA を使用して証明書を発行または署名するための一連のポリシーを提供する中間 CA のロールを作成します。

ロールの作成時に構成できる構成は多数あります。詳細については、 Vault ロールのドキュメントを参照してください

ワークフローでは、90 日の TTLで、${DOMAIN}の証明書とそのサブドメインに署名できるロールkube-ingressを作成します。

    # with a Max TTL of 90 days
    vault write ${PKI_INT}/roles/kube-ingress \
              allowed_domains=${DOMAIN} \
              allow_subdomains=true \
              max_ttl="2160h" \
              require_cn=false
  <!--NeedCopy-->

Approle ベースの認証を作成する

証明書に署名するように中間 CA を設定したら、証明書マネージャが Vault を使用して証明書に署名するための認証メカニズムを提供する必要があります。Cert-Manager は、アプリケーションが Vault で定義されたロールにアクセスする方法を提供する Approle 認証方法をサポートしています。

AppRole は、一連の Vault ポリシーとログイン制約を表し、これらのポリシーを含むトークンを受け取るために満たす必要がある。この認証方法の詳細については、 Approle のドキュメントを参照してください

承認者を作成する

Kube-roleという名前のApproleを作成します。この Approle を認証に使用する場合は、証明書マネージャのsecret_idの有効期限が切れてはいけません。したがって、TTL を設定したり、0 に設定したりしないでください。

% vault auth enable approle

% vault write auth/approle/role/kube-role token_ttl=0

ポリシーをApproleに関連付ける

ポリシーを承認に関連付けるには、次の手順を実行します。

  1. 次の設定でファイルpki_int.hclを作成し、中間 CA の署名エンドポイントを許可します。

        path "${PKI_INT}/sign/*" {
              capabilities = ["create","update"]
            }
    <!--NeedCopy-->
    
  2. 次のコマンドを使用して、kube_allow_signという新しいポリシーにファイルを追加します。

    vault policy write kube-allow-sign pki_int.hcl
    
  3. 次のコマンドを使用して、このポリシーを Approle に更新します。

    vault write auth/approle/role/kube-role policies=kube-allow-sign
    

kube-roleAppRoleにより、中間 CA で CSR に署名できます。

ロール ID とシークレット ID を生成する

ロール ID とシークレット ID は、証明書マネージャが Vault で認証するために使用されます。

ロール ID とシークレット ID を生成し、シークレット ID を Base64 でエンコードします。以下の手順に従います。

% vault read auth/approle/role/kube-role/role-id
role_id     db02de05-fa39-4855-059b-67221c5c2f63

% vault write -f auth/approle/role/kube-role/secret-id
secret_id               6a174c20-f6de-a53c-74d2-6018fcceff64
secret_id_accessor      c454f7e5-996e-7230-6074-6ef26b7bcf86

# encode secret_id with base64
% echo 6a174c20-f6de-a53c-74d2-6018fcceff64 | base64
NmExNzRjMjAtZjZkZS1hNTNjLTc0ZDItNjAxOGZjY2VmZjY0Cg==

Kubernetes で証明書の発行を設定する

Vault を中間 CA として設定し、証明書マネージャが Vault にアクセスするための Approle 認証方法を設定したら、イングレス用の証明書を設定する必要があります。

Approle シークレット ID でシークレットを作成する

Approle シークレット ID を持つシークレットを作成するには、次の手順を実行します。

  1. 以下の設定で、 secretid.yaml というシークレットファイルを作成します。

    apiVersion: v1
    kind: Secret
    type: Opaque
    metadata:
      name: cert-manager-vault-approle
      namespace: cert-manager
    data:
      secretId: "NmExNzRjMjAtZjZkZS1hNTNjLTc0ZDItNjAxOGZjY2VmZjY0Cg=="
    

    注:

    シークレット ID data.secretId は、 ロール ID とシークレット ID を生成するで生成された base64 でエンコードされたシークレット IDです。次のステップで Issuer リソースを使用する場合、シークレットはIssuerと同じ名前空間に存在する必要があります 。ClusterIssuerでは 、シークレットはcert-manager名前空間になければなりません。

  2. 以下のコマンドを使用して、シークレットファイル (secretid.yaml) をデプロイします。

    % kubectl create -f secretid.yaml
    

Vault クラスタ発行者をデプロイする

cert-manager は設定用に 2 つの異なる CRD をサポートします。1 つは単一の名前空間にスコープされるIssuer、もう1つはクラスター全体に適用されるClusterIssuer。ワークフローでは、ClusterIssuerを使用する必要があります 。

Vault クラスタ発行者をデプロイするには、次の手順を実行します。

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

    apiVersion: cert-manager.io/v1
    kind: ClusterIssuer
    metadata:
      name: vault-issuer
    spec:
      vault:
        path: pki_int/sign/kube-ingress
        server: <vault-server-url>
        #caBundle: <base64 encoded caBundle PEM file>
        auth:
          appRole:
            path: approle
            roleId: "db02de05-fa39-4855-059b-67221c5c2f63"
            secretRef:
              name: cert-manager-vault-approle
              key: secretId
    

    SecretRef は前のステップで作成した Kubernetes シークレット名です。roleIdをVault から取得したrole_idと交換します。 Vault サーバへの TLS 接続を検証するために、オプションの base64 エンコードされた CABundle を PEM 形式で提供できます。CABundle が設定されると、証明書マネージャを実行しているコンテナ内の CA バンドルが置き換えられます。使用される接続がプレーン HTTP の場合、このパラメータは効果がありません。

  2. 次のコマンドを使用して file (issuer-vault.yaml) をデプロイします。

    % kubectl create -f issuer-vault.yaml
    
  3. 次のコマンドを使用して、Vault クラスタ発行者が Vault で正常に認証されたかどうかを確認します。

    % kubectl describe clusterIssuer vault-issuer  | tail -n 7
      Conditions:
        Last Transition Time:  2019-02-26T06:18:40Z
        Message:               Vault verified
        Reason:                VaultVerified
        Status:                True
        Type:                  Ready
    Events:                    <none>
    

これで、Vault の cert-manager を CA として正常にセットアップできました。次のステップでは、サーバー証明書を生成して Ingress を保護します。イングレスを保護するには、2 つの異なるオプションがあります。イングレスを保護するためのアプローチの 1 つを続行できます。

  • イングレス・シム・アプローチ
  • 証明書のcertificate CRD オブジェクトを手動で作成する。

イングレスシム・アプローチ

この方法では、cert-manager の Ingress アノテーションを変更して、指定されたホスト名の証明書を自動的に生成し、指定したシークレットに格納します。

  1. ホスト名とシークレットを指定するtlsセクションで Ingress を変更します。また、cert-managerアノテーションcert-manager.io/cluster-issuerを以下のように指定します。

            apiVersion: networking.k8s.io/v1
            kind: Ingress
            metadata:
              annotations:
                cert-manager.io/cluster-issuer: vault-issuer
                kubernetes.io/ingress.class: citrix
              name: kuard
            spec:
              rules:
              - host: kuard.example.com
                http:
                  paths:
                  - backend:
                      service:
                        name: kuard-service
                        port:
                          number: 80
                    path: /
                    pathType: Prefix
              tls:
              - hosts:
                - kuard.example.com
                secretName: kuard-example-tls
    <!--NeedCopy-->
    
  2. 変更した Ingress を次のように展開します。

      % kubectl apply -f ingress.yml
      ingress.extensions/kuard created
    
      % kubectl get ingress kuard
      NAME    HOSTS               ADDRESS   PORTS     AGE
      kuard   kuard.example.com             80, 443   12s
    

このステップでは、証明書マネージャがドメインkuard.example.comの証明書署名要求 (CSR)を作成するcertificateオブジェクトをトリガします。CSR の署名に成功すると、証明書は Ingressで指定されたシークレット名kuard-example-tlsに保存されます。

  1. 次のコマンドを使用して、証明書が正常に発行されたことを確認します。

      % kubectl describe certificates kuard-example-tls  | grep -A5 Events
      Events:
      Type    Reason      Age   From          Message
      ----    ------      ----  ----          -------
      Normal  CertIssued  48s   cert-manager  Certificate issued successfully
    

証明書の certificate CRD オブジェクトを作成する

発行者が正常に登録されたら、Ingress ドメインkuard.example.comの証明書を取得する必要があります。

commonNamednsNamesを使用してcertificateリソースを作成する必要があります。 詳細については、 cert-manager のドキュメントを参照してください。証明書の SAN フィールドに使用される DNSname を複数指定できます。

証明書の「証明書」CRD オブジェクトを作成するには、次の手順を実行します。

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

    apiVersion: cert-manager.io/v1
    kind: Certificate
    metadata:
      name: kuard-example-tls
      namespace: default
    spec:
      secretName: kuard-example-tls
      issuerRef:
        kind: ClusterIssuer
        name: vault-issuer
      commonName: kuard.example.com
      duration: 720h
      #Renew before 7 days of expiry
      renewBefore: 168h
      commonName: kuard.example.com
      dnsNames:
      - www.kuard.example.com
    

    証明書には CN=kuard.example.com と SAN = Kuard.example.com,www.kuard.example.comがあります。 spec.secretName は、証明書が正常に発行された後に証明書が保存されるシークレットの名前です。

  2. 次のコマンドを使用して Kubernetes クラスターにファイル (certificate.yaml) をデプロイします。

    % kubectl create -f certificate.yaml certificate.certmanager.k8s.io/kuard-example-tls created

証明書が発行されたか確認する

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

% kubectl describe certificates kuard-example-tls  | grep -A5 Events
Events:
  Type    Reason      Age   From          Message
  ----    ------      ----  ----          -------
  Normal  CertIssued  48s   cert-manager  Certificate issued successfully > **注** > > Vault ポリシーが原因でエラーが発生する場合があります。このようなエラーが発生した場合は、Vault に戻って修正してください。

署名に成功すると、Certificateリソースに指定されたsecretNameを使用してkubernetes.io/tlsシークレットが作成されます。

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

生成されたシークレットを使用するように Ingress を変更します

生成されたシークレットを使用するように Ingress を変更するには、次の手順を実行します。

  1. 元のイングレスを編集し、シークレットkuard-example-tlsを指定するspec.tlsセクションを以下のように追加します。

          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
                  pathType: Prefix
                  path: /
            tls:
            - hosts:
              - kuard.example.com
              secretName: kuard-example-tls
    
  2. 以下のコマンドを使用して Ingress をデプロイします。

    % kubectl apply -f ingress.yml
    ingress.extensions/kuard created
    
    % kubectl get ingress kuard
    NAME    HOSTS               ADDRESS   PORTS     AGE
    kuard   kuard.example.com             80, 443   12s
    

Citrix ADCでイングレス構成を確認する

証明書が正常に生成されると、Citrix ingress controller はこの証明書を使用してフロントエンドSSL仮想サーバーを構成します。次の手順で確認できます。

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

    % kubectl exec -it cpx-ingress-668bf6695f-4fwh8 bash
    cli_script.sh 'shsslvs'
    exec: shsslvs
    1) Vserver Name: k8s-10.244.3.148: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
      SSLv2 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
      SSLv2: DISABLED  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
    Done
    
    root@cpx-ingress-668bf6695f-4fwh8:/# cli_script.sh 'shsslvs k8s-10.244.3.148:443:ssl'
    exec: shsslvs k8s-10.244.3.148:443:ssl
    
      Advanced SSL configuration for VServer k8s-10.244.3.148: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
      SSLv2 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
      SSLv2: DISABLED  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-LMO3O3U6KC6WXKCBJAQY6K6X6JO Server Certificate for SNI
    
    7) Cipher Name: DEFAULT
      Description: Default cipher list with encryption strength >= 128bit
    Done
    
    root@cpx-ingress-668bf6695f-4fwh8:/# cli_script.sh 'sh certkey k8s-LMO3O3U6KC6WXKCBJAQY6K6X6JO'
    exec: sh certkey k8s-LMO3O3U6KC6WXKCBJAQY6K6X6JO
      Name: k8s-LMO3O3U6KC6WXKCBJAQY6K6X6JO Status: Valid,   Days to expiration:0
      Version: 3
      Serial Number: 524C1D9306F784A2F5277C05C2A120D5258D9A2F
      Signature Algorithm: sha256WithRSAEncryption
      Issuer:  CN=example.com CA intermediate
      Validity
        Not Before: Feb 26 06:48:39 2019 GMT
        Not After : Feb 27 06:49:09 2019 GMT
      Certificate Type: "Client Certificate" "Server Certificate"
      Subject:  CN=kuard.example.com
      Public Key Algorithm: rsaEncryption
      Public Key size: 2048
      Ocsp Response Status: NONE
      2) URI:http://127.0.0.1:8200/v1/pki_int/crl
      3) VServer name: k8s-10.244.3.148:443:ssl Server Certificate for SNI
    Done
    

    HTTPS Web サーバは Vault 署名付き証明書で稼働しています。Cert-Manager は、証明書の有効期限が切れる前に、 証明書のRenewBeforeパラメータで指定されたとおりに証明書を自動的に更新します。

    注:

    証明書の有効期限がルート CA または中間 CA の有効期限を超えると、証明書の Vault 署名は失敗します。CA 証明書は、有効期限が切れる前に事前に更新されていることを確認する必要があります。

  2. HTTPS プロトコルを使用してアプリケーションにアクセスできることを確認します。

    % curl -sS -D - https://kuard.example.com -k -o /dev/null
    HTTP/1.1 200 OK
    Content-Length: 1472
    Content-Type: text/html
    Date: Tue, 11 May 2021 20:39:23 GMT
    
証明書マネージャーを使用して、Citrix ingress controller と HashiCorp Vault を使用して Kubernetes に HTTPS ウェブアプリケーションをデプロイする