cert-managerを使用して、NetScaler Ingress ControllerとHashiCorp VaultでKubernetes上にHTTPSウェブアプリケーションをデプロイする
NetScaler Ingress Controllerでデプロイされたイングレスリソースの場合、cert-managerとHashiCorp Vaultを使用してTLS証明書のプロビジョニング、失効、更新を自動化できます。このトピックでは、cert-managerからの証明書署名要求に対して、HashiCorp Vaultを自己署名証明書認証局として使用するワークフローの例を示します。
具体的には、このワークフローはVault PKI Secrets Engineを使用して証明書認証局（CA）を作成します。このチュートリアルは、Vaultサーバーがインストールされており、Kubernetesクラスターから到達可能であることを前提としています。VaultのPKIシークレットエンジンは、内部アプリケーションに適しています。公開信頼が必要な外部向けアプリケーションについては、Let's Encrypt CAを使用したTLS証明書の自動化を参照してください。
このワークフローでは、Vaultシークレットエンジンと認証方法を使用します。Vaultの全機能については、以下のVaultドキュメントを参照してください。
このトピックでは、以下を使用してKubernetesクラスター上にHTTPSウェブアプリケーションをデプロイする方法に関する情報を提供します。
-
ネットスケーラー イングレスコントローラー
-
JetStackのcert-managerを使用してHashiCorp VaultからTLS証明書をプロビジョニングする
前提条件
以下を確認してください。
-
Vaultサーバーがインストールされ、アンシールされており、Kubernetesクラスターから到達可能であること。Vaultサーバーのインストールについては、Vaultのインストールに関するドキュメントを参照してください。
-
KubernetesクラスターでRBACが有効になっていること。
-
NetScaler MPX、VPX、またはCPXがTier 1またはTier 2デプロイモデルでデプロイされていること。Tier 1展開モデルでは、NetScaler MPXまたはVPXがアプリケーションデリバリーコントローラー (ADC) として使用されます。Kubernetesクラスターで実行されているNetScaler Ingress Controllerは、Kubernetesクラスターで実行されているサービス用の仮想サービスを構成します。NetScalerは、公開ルーティング可能なIPアドレスで仮想サービスを実行し、Let's Encryptによって生成された証明書を使用してクライアントトラフィックのSSLをオフロードします。Tier 2展開では、Kubernetesクラスターの外部で実行されているNetScaler (VPX/MPX) 上でTCPサービスが構成され、Kubernetesクラスターで実行されているNetScaler CPXインスタンスにトラフィックを転送します。NetScaler CPXはSSLセッションを終了し、実際のサービスポッドにトラフィックをロードバランスします。
-
NetScaler Ingress Controllerが展開されました。さまざまな展開シナリオについては、展開トポロジを参照してください。
-
すべての展開手順に対する管理者権限。権限が原因で障害が発生した場合は、管理者権限があることを確認してください。
注：
次の手順では、NetScaler CPXをイングレスデバイスとして使用して、Vaultを証明機関として構成する手順を示します。NetScaler VPXまたはMPXがイングレスデバイスとして使用される場合、NetScalerでのイングレス構成を確認する手順を除いて、手順は同じです。
マニフェストファイルを使用してcert-managerを展開する
提供されているYAMLマニフェストファイルを使用してcert-managerを展開するには、次の手順を実行します。
-
cert-managerをインストールします。cert-managerのインストールについては、cert-managerドキュメントを参照してください。
kubectl apply -f https://github.com/jetstack/cert-manager/releases/download/vx.x.x/cert-manager.yamlHelmを使用してcert-managerをインストールすることもできます。詳細については、cert-managerドキュメントを参照してください。 -
次のコマンドを使用して、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が参照用に使用されています。
-
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 -
以下のコマンドを使用して、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 -
デプロイメント用のサービスを作成します。
service.yamlという名前のファイルを以下の構成で作成します。apiVersion: v1
kind: Service
metadata:
name: kuard
spec:
ports:
- port: 80
targetPort: 8080
protocol: TCP
selector:
app: kuard -
以下のコマンドを使用してサービスをデプロイし、検証します。
% 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 -
NetScaler CPXまたはVPXにコンテンツスイッチング仮想サーバーとしてデプロイされるIngressを作成して、このサービスを外部に公開します。注:NetScaler Ingress Controllerが起動しているIngressクラスに
ingressClassName: citrixを変更してください。apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
name: kuard
spec:
ingressClassName: citrix
rules:
- host: kuard.example.com
http:
paths:
- backend:
service:
name: kuard
port:
number: 80
path: /
pathType: Prefix注:spec.rules.hostの値を、お客様が管理するドメインに変更してください。NetScaler CPXまたはVPXにトラフィックをルーティングするためのDNSエントリが存在することを確認してください。 -
以下のコマンドを使用して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 -
以下のコマンドを使用して、IngressがNetScaler 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 -
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を認証局として使用し、cert-managerがCSRの署名機関としてVaultを使用するように構成します。
HashiCorp Vaultを認証局として構成する
この手順では、HashiCorp Vault を使用して中間 CA 証明書署名要求を設定します。この Vault エンドポイントは、cert-manager によってイングレスリソースの証明書に署名するために使用されます。
注記：
これらの手順を実行する前に、
jq ユーティリティがインストールされていることを確認してください。
ルート CA を作成する
サンプルワークフローでは、Vault 内で独自のルート認証局を生成できます。本番環境では、Vault が証明書を生成するために使用する中間 CA に署名するために、外部ルート 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"中間 CA を生成する
ルート CA を作成した後、ルート CA を使用して中間 CSR を作成するには、次の手順を実行します。
-
ルート 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} -
ルート 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)
-
${DOMAIN}証明書を中間 CA としてルート 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外部ルート CA を使用している場合は、前の手順をスキップし、ルート CA を使用して CSR に手動で署名します。 -
CSR が署名され、ルート CA が証明書を返したら、次のコマンドを使用して Vault に戻す必要があります。
% vault write "${PKI_INT}"/intermediate/set-signed certificate=@intermediate.cert.pem -
次のコマンドを使用して、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"
中間CAが設定されており、イングレスリソースの証明書に署名するために使用できます。
ロールを構成する
ロールはポリシーにマッピングされる論理名です。管理者はロールを通じて証明書の生成を制御できます。
このCAを使用して証明書を発行または署名するためのポリシーセットを提供する、中間CAのロールを作成します。
ロールを作成する際に設定できる構成は多数あります。詳細については、Vaultロールのドキュメントを参照してください。
ワークフローのために、
${DOMAIN}とそのサブドメインの証明書に90日間のTTLで署名できるロール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
AppRoleベースの認証を作成する
証明書に署名するための中間CAを構成した後、cert-managerがVaultを使用して証明書に署名するための認証メカニズムを提供する必要があります。Cert-managerは、アプリケーションがVaultで定義されたロールにアクセスする方法を提供するAppRole認証メソッドをサポートしています。
AppRoleは、それらのポリシーを持つトークンを受け取るために満たされなければならないVaultポリシーとログイン制約のセットを表します。この認証方法の詳細については、AppRoleのドキュメントを参照してください。
AppRoleを作成する
Kube-roleという名前のAppRoleを作成します。cert-managerが認証にこのAppRoleを使用するためには、secret_idが期限切れになっていない必要があります。したがって、TTLを設定しないか、0に設定してください。
% vault auth enable approle
% vault write auth/approle/role/kube-role token_ttl=0
ポリシーをAppRoleに関連付ける
AppRoleにポリシーを関連付けるには、次の手順を実行します。
-
中間CAの署名エンドポイントを許可するために、次の構成でファイル
pki_int.hclを作成します。path "${PKI_INT}/sign/*" {
capabilities = ["create","update"]
} -
次のコマンドを使用して、ファイルを
kube_allow_signという新しいポリシーに追加します。vault policy write kube-allow-sign pki_int.hcl -
以下のコマンドを使用して、このポリシーをApproleに更新します。
vault write auth/approle/role/kube-role policies=kube-allow-sign
kube-role approleは、中間CAでCSRに署名することを可能にします。
ロールIDとシークレットIDを生成する
ロールIDとシークレットIDは、cert-managerが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として、またcert-managerがVaultにアクセスするためのApprole認証方法を設定した後、Ingress用の証明書を設定する必要があります。
ApproleシークレットIDでシークレットを作成する
ApproleシークレットIDでシークレットを作成するには、以下を実行します。
-
以下の構成で
secretid.yamlという名前のシークレットファイルを作成します。apiVersion: v1
kind: Secret
type: Opaque
metadata:
name: cert-manager-vault-approle
namespace: cert-manager
data:
secretId: "NmExNzRjMjAtZjZkZS1hNTNjLTc0ZDItNjAxOGZjY2VmZjY0Cg=="注記：シークレットIDdata.secretIdは、ロールIDとシークレットIDを生成する で生成されたBase64エンコードされたシークレットIDです。次のステップでIssuerリソースを使用する場合、シークレットはIssuerと同じ名前空間にある必要があります。ClusterIssuerの場合、シークレットはcert-manager名前空間にある必要があります。 -
以下のコマンドを使用して、シークレットファイル (
secretid.yaml) をデプロイします。% kubectl create -f secretid.yaml
Vaultクラスターイシューアーをデプロイする
cert-managerは、構成用に2つの異なるCRDをサポートしています。1つは単一の名前空間にスコープされた
Issuer、もう1つはクラスター全体にわたるClusterIssuerです。このワークフローでは、ClusterIssuer を使用する必要があります。
Vaultクラスター発行者をデプロイするには、次の手順を実行します。
-
次の構成で
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: secretIdSecretRefは、前の手順で作成したKubernetesシークレット名です。roleIdをVaultから取得したrole_idに置き換えます。 VaultサーバーへのTLS接続を検証するために、PEM形式のオプションのbase64エンコードされたcaBundleを提供できます。caBundleが設定されている場合、cert-managerを実行しているコンテナ内のCAバンドルを置き換えます。使用される接続がプレーンHTTPの場合、このパラメータは効果がありません。 -
次のコマンドを使用して、ファイル (
issuer-vault.yaml) をデプロイします。% kubectl create -f issuer-vault.yaml -
次のコマンドを使用して、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をCAとしてcert-managerのセットアップが正常に完了しました。次のステップは、サーバー証明書を生成してイングレスを保護することです。イングレスを保護するには2つの異なるオプションがあります。いずれかの方法でイングレスを保護できます。
-
Ingress Shimアプローチ
-
証明書用の
certificateCRDオブジェクトを手動で作成する。
Ingress-shimアプローチ
このアプローチでは、cert-managerのイングレスアノテーションを変更して、指定されたホスト名の証明書を自動的に生成し、指定されたシークレットに保存します。
-
ホスト名とシークレットを指定する
tlsセクションでイングレスを変更します。また、cert-managerアノテーションcert-manager.io/cluster-issuerを次のように指定します。apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
cert-manager.io/cluster-issuer: vault-issuer
name: kuard
spec:
ingressClassName: citrix
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 -
変更されたイングレスを次のようにデプロイします。
% 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
このステップは、cert-managerによって
certificateオブジェクトをトリガーし、ドメインkuard.example.comの証明書署名要求 (CSR) を作成します。CSRの署名が成功すると、証明書はイングレスで指定されたシークレット名kuard-example-tlsに保存されます。
-
次のコマンドを使用して、証明書が正常に発行されたことを確認します。
% 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オブジェクトを作成する
発行者が正常に登録されたら、イングレスドメイン
kuard.example.com の証明書を取得する必要があります。
commonName と dnsNames を使用して certificate リソースを作成する必要があります。詳細については、cert-manager documentation を参照してください。証明書の SAN フィールドに使用される複数の dnsNames を指定できます。
証明書用の「certificate」CRD オブジェクトを作成するには、以下を実行します。
-
次の構成で
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は、証明書が正常に発行された後に証明書が保存されるシークレットの名前です。 -
次のコマンドを使用して、ファイル (
certificate.yaml) を Kubernetes クラスターにデプロイします。% kubectl create -f certificate.yaml certificate.certmanager.k8s.io/kuard-example-tls 作成されました
証明書が発行されているか確認する
次のコマンドを使用して、証明書の発行状況を監視できます。
% 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
生成されたシークレットを使用するようにイングレスを変更する
生成されたシークレットを使用するようにイングレスを変更するには、次の手順を実行します。
-
元のイングレスを編集し、シークレット
kuard-example-tlsを指定するspec.tlsセクションを次のように追加します。apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
name: kuard
spec:
ingressClassName: citrix®
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 -
以下のコマンドを使用してイングレスをデプロイします。
% 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
NetScaler でイングレス構成を確認する
証明書が正常に生成されると、NetScaler Ingress Controller はこの証明書を使用してフロントエンド SSL 仮想サーバーを構成します。以下の手順で確認できます。
-
NetScaler 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
DoneHTTPS ウェブサーバーは、Vault で署名された証明書で稼働しています。Cert-manager は、証明書に指定されたRenewBeforeパラメーターに従って、証明書の有効期限が切れる前に自動的に証明書を更新します。注:証明書の有効期限がルート CA または中間 CA の有効期限を超えている場合、Vault による証明書の署名は失敗します。CA 証明書は、有効期限が切れる前に事前に更新されていることを確認する必要があります。 -
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