安裝 istio-csr

安裝步驟

本指南將逐步說明如何從頭開始安裝和使用 istio-csr。我們將使用 kind 在 Docker 中於本機建立新的叢集，但只要執行相關的 Istio 平台設定，本指南應適用於任何叢集。

請注意，如果您正在遵循 OpenShift 的平台設定指南，請勿執行該指南中列出的 istioctl install 命令；稍後我們將執行自己的命令。

0. 背景

Issuer 設定

istio-csr 使用 cert-manager 來簽發 Istio 憑證，並且需要能夠參考 issuer 資源才能執行此操作。

您可以選擇在使用 Helm 圖表安裝時設定 issuer，和/或設定要監看的 ConfigMap，然後該 ConfigMap 可用於在執行時設定 issuer。

為 issuer 詳細資訊設定 ConfigMap 稱為「執行階段設定」，如果 Helm 圖表中未指定任何 issuer，則必須進行此設定。

如果您在圖表中設定 issuer，您可以在 istio-csr pod 上線後立即開始簽發憑證，但您需要先安裝 cert-manager 並建立 issuer。

如果您未在圖表中設定 issuer，istio-csr 將不會就緒，直到透過執行階段設定指定 issuer 為止，但您可以同時安裝 cert-manager 和 istio-csr。

請注意，圖表包含預設的 issuer 名稱，因此使用執行階段設定需要明確選擇加入。以下指南假設您將在設定 issuer 而不使用執行階段設定之後安裝 istio-csr；底部有執行階段設定的注意事項。

Istio Ambient

從 v0.12.0 開始，istio-csr 支援 Istio Ambient 模式，此模式允許將 pod 包含在 Istio 網格中，而無需 side-car 容器。

若要啟用 Istio Ambient 模式支援，請傳遞 app.server.caTrustedNodeAccounts Helm 值，此值是以逗號分隔的 namespace/service-accounts 值清單，表示允許哪些服務帳戶使用節點驗證。

範例為 --set app.server.caTrustedNodeAccounts=istio-system/ztunnel

1. 初始設定

您需要在您的電腦上安裝下列工具

istioctl
kind 和 docker（如果您使用 kind）
helm
kubectl
jq

此外，您的叢集中不得已安裝 Istio。不支援在安裝 Istio 之後安裝 istio-csr。

2. 建立叢集並安裝 cert-manager

Kind 會自動設定 kubectl 以指向新建立的叢集。

我們在此使用 helm 安裝 cert-manager，但如果您有偏好的方法，可以使用任何方式安裝。

kind create cluster

# Helm setup
helm repo add jetstack https://charts.jetstack.io --force-update

# install cert-manager; this might take a little time
helm install \
  cert-manager jetstack/cert-manager \
  --namespace cert-manager \
  --create-namespace \
  --version v1.16.1 \
  --set crds.enabled=true

# We need this namespace to exist since our cert will be placed there
kubectl create namespace istio-system

3. 建立 cert-manager Issuer 並簽發憑證

Issuer 會告知 cert-manager 如何簽發憑證；我們將在我們的叢集中建立自我簽署的根 CA，因為其設定非常簡單。

使用本機產生的根憑證的方法也適用於生產部署，但 cert-manager 中也有其他幾個簽發者可供使用。請注意，ACME 簽發者將無法運作，因為它無法將所需欄位新增至已簽發的憑證。

關於 example-issuer 也有一些註解，提供更多詳細資訊。另請注意，本指南僅使用 Issuer，而不是 ClusterIssuer - 使用 ClusterIssuer 並非直接替代方案，而且無論如何，我們建議生產部署使用 Issuers 以便於存取控制和範圍設定。

kubectl apply -f https://raw.githubusercontent.com/cert-manager/website/7f5b2be9dd67831574b9bde2407bed4a920b691c/content/docs/tutorials/istio-csr/example/example-issuer.yaml

4. 將根 CA 匯出至本機檔案

雖然可以設定 Istio，使其可以自動「探索」根 CA，但在某些涉及其他安全漏洞的特定情況下，這可能會很危險，從而導致簽署者劫持攻擊。

因此，我們將匯出我們的根 CA，並稍後使用該靜態憑證設定 Istio。

# Export our cert from the secret it's stored in, and base64 decode to get the PEM data.
kubectl get -n istio-system secret istio-ca -ogo-template='{{index .data "tls.crt"}}' | base64 -d > ca.pem

# Out of interest, we can check out what our CA looks like
openssl x509 -in ca.pem -noout -text

# Add our CA to a secret
kubectl create secret generic -n cert-manager istio-root-ca --from-file=ca.pem=ca.pem

5. 安裝 istio-csr

最好透過 Helm 安裝 istio-csr，安裝應簡單快速。helm 圖表還有許多其他設定選項，您可以在此處查看。

helm repo add jetstack https://charts.jetstack.io --force-update

# We set a few helm template values so we can point at our static root CA
helm upgrade cert-manager-istio-csr jetstack/cert-manager-istio-csr \
  --install \
  --namespace cert-manager \
  --wait \
  --set "app.tls.rootCAFile=/var/run/secrets/istio-csr/ca.pem" \
  --set "volumeMounts[0].name=root-ca" \
  --set "volumeMounts[0].mountPath=/var/run/secrets/istio-csr" \
  --set "volumes[0].name=root-ca" \
  --set "volumes[0].secret.secretName=istio-root-ca"

# Check to see that the istio-csr pod is running and ready
kubectl get pods -n cert-manager
NAME                                       READY   STATUS    RESTARTS   AGE
cert-manager-aaaaaaaaaa-11111              1/1     Running   0          9m46s
cert-manager-cainjector-aaaaaaaaaa-22222   1/1     Running   0          9m46s
cert-manager-istio-csr-bbbbbbbbbb-00000    1/1     Running   0          63s
cert-manager-webhook-aaaaaaaaa-33333       1/1     Running   0          9m46s

6. 安裝 Istio

如果您未在 kind 上執行，您可能需要先執行一些額外的設定工作，才能安裝 Istio。

我們使用 istioctl CLI 來安裝 Istio，並使用自訂的 IstioOperator 資訊清單進行設定。

自訂資訊清單執行下列操作

停用 istiod 中的 CA 伺服器，
確保 Istio 工作負載從 istio-csr 請求憑證，
確保 istiod 憑證和金鑰是從安裝 istio-csr 時建立的憑證掛載。

首先，我們下載我們的示範資訊清單，然後套用它。

curl -sSL https://raw.githubusercontent.com/cert-manager/website/7f5b2be9dd67831574b9bde2407bed4a920b691c/content/docs/tutorials/istio-csr/example/istio-config-getting-started.yaml > istio-install-config.yaml

如果您知道自己在做什麼，您可能需要檢查和調整 istio-install-config.yaml，但此資訊清單應可按原樣用於示範目的。

如果您在先前透過 helm 安裝 istio-csr 時設定了自訂的 app.tls.trustDomain，您需要確保 istio-install-config.yaml 中重複該值。

最後一個命令將安裝 Istio；您需要的確切命令可能會因不同平台而異，而且在 OpenShift 上肯定會有所不同。

# This takes a little time to complete
istioctl install -f istio-install-config.yaml

# If you're on OpenShift, you need a different profile:
# istioctl install --set profile=openshift -f istio-install-config.yaml

系統將提示您輸入以確認您選擇的 Istio 設定檔

This will install the Istio 1.14.1 demo profile with ["Istio core" "Istiod" "Ingress gateways" "Egress gateways"] components into the cluster. Proceed? (y/N)

輸入 y 到主控台中以確認您的選擇，以繼續安裝。

驗證安裝

以下步驟為可選，但可以遵循這些步驟來驗證所有項目是否正確連接

部署一個範例應用程式並觀察 certificaterequests.cert-manager.io 資源
驗證 cert-manager 的日誌，查看新的 certificaterequests 和回應
驗證 istio-proxy sidecar 容器中使用的 CA 端點
使用 istioctl 來獲取 istio-proxy 容器的憑證資訊

為了查看所有這些實際運作情況，讓我們從 Istio 範例中部署一個非常簡單的範例應用程式。

首先設定一些環境變數，如果需要，可以更改其值

# Set namespace for sample application
export NAMESPACE=default
# Set env var for the value of the app label in manifests
export APP=httpbin
# Grab the installed version of istio
export ISTIO_VERSION=$(istioctl version -o json | jq -r '.meshVersion[0].Info.version')

為了簡化，我們使用 default 命名空間，所以讓我們為 Istio 注入標記命名空間

kubectl label namespace $NAMESPACE istio-injection=enabled --overwrite

在單獨的終端機中，您現在應該追蹤 cert-manager 的日誌

kubectl logs -n cert-manager $(kubectl get pods -n cert-manager -o jsonpath='{.items..metadata.name}' --selector app=cert-manager) --since 2m -f

在另一個單獨的終端機中，讓我們觀察 istio-system 命名空間中的 certificaterequests

kubectl get certificaterequests.cert-manager.io -n istio-system -w

現在在標記的命名空間中部署範例應用程式 httpbin。請注意使用變數來比對您的 Istio 安裝版本

kubectl apply -n $NAMESPACE -f https://raw.githubusercontent.com/istio/istio/$ISTIO_VERSION/samples/httpbin/httpbin.yaml

您應該看到類似於此處 certificaterequests 輸出的內容

NAME             APPROVED   DENIED   READY   ISSUER       REQUESTOR                                         AGE
istio-ca-74bnl   True                True    selfsigned   system:serviceaccount:cert-manager:cert-manager   2d2h
istiod-w9zh6     True                True    istio-ca     system:serviceaccount:cert-manager:cert-manager   27m
istio-csr-8ddcs                               istio-ca     system:serviceaccount:cert-manager:cert-manager-istio-csr   0s
istio-csr-8ddcs   True                        istio-ca     system:serviceaccount:cert-manager:cert-manager-istio-csr   0s
istio-csr-8ddcs   True                True    istio-ca     system:serviceaccount:cert-manager:cert-manager-istio-csr   0s
istio-csr-8ddcs   True                True    istio-ca     system:serviceaccount:cert-manager:cert-manager-istio-csr   0s

我們範例輸出中的主要請求是 istio-csr-8ddcs。然後您應該檢查您的 cert-manager 日誌輸出，其中應包含兩個關於此請求為「已核准」和「就緒」的日誌行

I0113 16:51:59.186482       1 conditions.go:261] Setting lastTransitionTime for CertificateRequest "istio-csr-8ddcs" condition "Approved" to 2022-01-13 16:51:59.186455713 +0000 UTC m=+3507.098466775
I0113 16:51:59.258876       1 conditions.go:261] Setting lastTransitionTime for CertificateRequest "istio-csr-8ddcs" condition "Ready" to 2022-01-13 16:51:59.258837897 +0000 UTC m=+3507.170859959

您現在應該看到應用程式正在執行，其中包含應用程式容器和 sidecar

~ kubectl get pods -n $NAMESPACE
NAME                       READY   STATUS    RESTARTS   AGE
httpbin-74fb669cc6-559cg   2/2     Running   0           4m

為了驗證 istio-proxy sidecar 容器是否已向正確的服務請求憑證，請檢查容器日誌

kubectl logs $(kubectl get pod -n $NAMESPACE -o jsonpath="{.items...metadata.name}" --selector app=$APP) -c istio-proxy

您應該會看到一些類似於此範例的早期日誌

Istio v1.12 和更早版本

2022-01-13T16:51:58.495493Z	info	CA Endpoint cert-manager-istio-csr.cert-manager.svc:443, provider Citadel
2022-01-13T16:51:58.495817Z	info	Using CA cert-manager-istio-csr.cert-manager.svc:443 cert with certs: var/run/secrets/istio/root-cert.pem
2022-01-13T16:51:58.495941Z	info	citadelclient	Citadel client using custom root cert: cert-manager-istio-csr.cert-manager.svc:443

Istio v1.13+

2022-01-13T16:51:58.495493Z	info	CA Endpoint cert-manager-istio-csr.cert-manager.svc:443, provider Citadel
2022-01-13T16:51:58.495817Z	info	Using CA cert-manager-istio-csr.cert-manager.svc:443 cert with certs: var/run/secrets/istio/root-cert.pem
2022-01-13T16:51:58.495941Z	info	citadelclient	Citadel client using custom root cert: var/run/secrets/istio/root-cert.pem

最後，我們可以檢查 Envoy 在記憶體中使用的憑證。此單行程式碼應會傳回正在使用的憑證

istioctl proxy-config secret $(kubectl get pods -n $NAMESPACE -o jsonpath='{.items..metadata.name}' --selector app=$APP) -o json | jq -r '.dynamicActiveSecrets[0].secret.tlsCertificate.certificateChain.inlineBytes' | base64 --decode | openssl x509 -text -noout

特別注意以下部分

Signature Algorithm: ecdsa-with-SHA256
        Issuer: O=cert-manager, O=cluster.local, CN=istio-ca
        Validity
            Not Before: Jan 13 16:51:59 2022 GMT
            Not After : Jan 13 17:51:59 2022 GMT
...
            X509v3 Subject Alternative Name:
                URI:spiffe://cluster.local/ns/default/sa/httpbin

您應該會在簽發者中看到相關的信任網域。在預設情況下，它應該是： cluster.local，如上所示。請注意，如果您使用不同的命名空間或應用程式，SPIFFE URI 可能會有所不同。

清除

假設您在 kind 內執行，您可以簡單地移除叢集

kind delete cluster

使用執行階段組態安裝

有兩種選項可使用執行階段組態進行安裝

在 cert-manager 之後安裝，仍然在 Helm 圖表中提供明確的 issuerRef
清空 Helm 圖表中的 issuerRef，並使用純粹的執行階段組態

這兩個選項都需要建立一個 ConfigMap 來指向簽發者。此 ConfigMap 可以在安裝之前或之後建立，並且必須在與 istio-csr pod 相同的命名空間中建立。

建立 ConfigMap

需要三個鍵，指定簽發者的名稱、種類和群組。任何建立 ConfigMap 的方法都適用。例如

kubectl create configmap -n cert-manager istio-issuer \
  --from-literal=issuer-name=my-issuer-name \
  --from-literal=issuer-kind=ClusterIssuer \
  --from-literal=issuer-group=cert-manager.io

如果需要，Helm 圖表包含在安裝時建立執行階段組態 ConfigMap 的功能，透過 app.runtimeConfiguration.issuer 值

app:
  runtimeConfiguration:
    issuer:
      name: my-issuer-name
      kind: Issuer
      group: cert-manager.io

選項 1：在 cert-manager 之後安裝

如果已安裝 cert-manager，您可以使用與上述相同的 helm upgrade 命令，但也指定執行階段組態 ConfigMap 的名稱

helm upgrade cert-manager-istio-csr jetstack/cert-manager-istio-csr \
  --install \
  --namespace cert-manager \
  --wait \
  ...
  --set "app.runtimeConfiguration.name=istio-issuer"

在此情境中，將在啟動時使用在 app.certmanager.issuer 中定義的簽發者，並建立 istiod 憑證。

當 istio-csr 偵測到執行階段 ConfigMap 時，它將使用其中設定的簽發者。如果 ConfigMap 更新，istio-csr 將動態地尊重更新。

如果刪除執行階段 ConfigMap，istio-csr 將會還原為使用 app.certmanager.issuer 中的值。

選項 2：純粹的執行階段組態

純粹的執行階段組態僅適用於 istio-csr v0.11.0 或更新版本。

純粹的執行階段組態需要設定更多值

app.certmanager.issuer 值必須清空 (因為它們在圖表中設定為預設值)
istiod 憑證不能與 istio-csr 資源一起佈建。透過傳遞 app.tls.istiodCertificateEnable=dynamic，當執行階段組態可用時，將動態產生 istiod。
必須設定 app.runtimeConfiguration.name。

以下是純粹執行階段組態的 values.yaml 檔案範例

app:
  runtimeIssuanceConfigMap: istio-issuer
  certmanager:
    issuer:
      enabled: false # Important: the default issuer is enabled by default
  tls:
    rootCAFile: "/var/run/secrets/istio-csr/ca.pem"
    istiodCertificateEnable: dynamic
volumeMounts:
- name: root-ca
  mountPath: /var/run/secrets/istio-csr
volumes:
- name: root-ca
  secret:
    secretName: istio-root-ca

然後，此檔案可以與下列命令一起使用

helm upgrade cert-manager-istio-csr jetstack/cert-manager-istio-csr \
  --install \
  --namespace cert-manager \
  --wait \
  --values values.yaml

完成純粹的執行階段安裝

為了讓 istio-csr 更容易與 cert-manager 一起安裝，純粹的執行階段組態稍微修改了 istio-csr 的健康檢查行為。這是因為 Helm 在健康檢查通過之前不會完成安裝。

只有在使用純粹的執行階段組態時，istio-csr 的健康檢查才會回報為正常，直到第一次執行階段組態可用。

在執行階段組態第一次可用後，健康檢查將還原為正常運作。

使用方式

📖 閱讀 istio-csr 文件。