使用 Kubernetes CSR 集成自定义 CA

 5 分钟阅读     页面测试

此功能需要 Kubernetes 版本 >= 1.18。

此任务展示了如何使用与 Kubernetes CSR API 集成的自定义证书颁发机构来配置工作负载证书。不同的工作负载可以从不同的 cert-signer 获取其证书签名。每个 cert-signer 实际上都是一个不同的 CA。预期来自同一 cert-signer 颁发的证书的工作负载可以相互进行 mTLS 通信，而由不同签名者签名的工作负载则无法通信。此功能利用了 Chiron，这是一个与 Istiod 链接的轻量级组件，它使用 Kubernetes CSR API 签名证书。

在本例中，我们使用 开源 cert-manager。Cert-manager 从 1.4 版本开始添加了对 Kubernetes CertificateSigningRequests 的 实验性支持。

在 Kubernetes 集群中部署自定义 CA 控制器

  1. 根据 安装文档 部署 cert-manager。

    $ helm repo add jetstack https://charts.jetstack.io
$ helm repo update
$ helm install cert-manager jetstack/cert-manager --namespace cert-manager --create-namespace --set featureGates="ExperimentalCertificateSigningRequestControllers=true" --set installCRDs=true

  2. 为 cert-manager 创建三个自签名集群颁发者 istio-system、foo 和 bar。注意：也可以使用命名空间颁发者和其他类型的颁发者。

    $ cat <<EOF > ./selfsigned-issuer.yaml
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: selfsigned-bar-issuer
spec:
  selfSigned: {}
---
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: bar-ca
  namespace: cert-manager
spec:
  isCA: true
  commonName: bar
  secretName: bar-ca-selfsigned
  issuerRef:
    name: selfsigned-bar-issuer
    kind: ClusterIssuer
    group: cert-manager.io
---
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: bar
spec:
  ca:
    secretName: bar-ca-selfsigned
---
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: selfsigned-foo-issuer
spec:
  selfSigned: {}
---
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: foo-ca
  namespace: cert-manager
spec:
  isCA: true
  commonName: foo
  secretName: foo-ca-selfsigned
  issuerRef:
    name: selfsigned-foo-issuer
    kind: ClusterIssuer
    group: cert-manager.io
---
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: foo
spec:
  ca:
    secretName: foo-ca-selfsigned
---
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: selfsigned-istio-issuer
spec:
  selfSigned: {}
---
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: istio-ca
  namespace: cert-manager
spec:
  isCA: true
  commonName: istio-system
  secretName: istio-ca-selfsigned
  issuerRef:
    name: selfsigned-istio-issuer
    kind: ClusterIssuer
    group: cert-manager.io
---
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: istio-system
spec:
  ca:
    secretName: istio-ca-selfsigned
EOF
$ kubectl apply -f ./selfsigned-issuer.yaml

验证为每个集群颁发者创建的密钥

$ kubectl get secret -n cert-manager -l controller.cert-manager.io/fao=true
NAME                  TYPE                DATA   AGE
bar-ca-selfsigned     kubernetes.io/tls   3      3m36s
foo-ca-selfsigned     kubernetes.io/tls   3      3m36s
istio-ca-selfsigned   kubernetes.io/tls   3      3m38s

导出每个集群颁发者的根证书

$ export ISTIOCA=$(kubectl get clusterissuers istio-system -o jsonpath='{.spec.ca.secretName}' | xargs kubectl get secret -n cert-manager -o jsonpath='{.data.ca\.crt}' | base64 -d | sed 's/^/        /')
$ export FOOCA=$(kubectl get clusterissuers foo -o jsonpath='{.spec.ca.secretName}' | xargs kubectl get secret -n cert-manager -o jsonpath='{.data.ca\.crt}' | base64 -d | sed 's/^/        /')
$ export BARCA=$(kubectl get clusterissuers bar -o jsonpath='{.spec.ca.secretName}' | xargs kubectl get secret -n cert-manager -o jsonpath='{.data.ca\.crt}' | base64 -d | sed 's/^/        /')

使用默认 cert-signer 信息部署 Istio

  1. 使用 istioctl 和以下配置在集群上部署 Istio。ISTIO_META_CERT_SIGNER 是工作负载的默认 cert-signer。

    $ cat <<EOF > ./istio.yaml
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  values:
    pilot:
      env:
        EXTERNAL_CA: ISTIOD_RA_KUBERNETES_API
  meshConfig:
    defaultConfig:
      proxyMetadata:
        ISTIO_META_CERT_SIGNER: istio-system
    caCertificates:
    - pem: |
$ISTIOCA
      certSigners:
      - clusterissuers.cert-manager.io/istio-system
    - pem: |
$FOOCA
      certSigners:
      - clusterissuers.cert-manager.io/foo
    - pem: |
$BARCA
      certSigners:
      - clusterissuers.cert-manager.io/bar
  components:
    pilot:
      k8s:
        env:
        - name: CERT_SIGNER_DOMAIN
          value: clusterissuers.cert-manager.io
        - name: PILOT_CERT_PROVIDER
          value: k8s.io/clusterissuers.cert-manager.io/istio-system
        overlays:
          - kind: ClusterRole
            name: istiod-clusterrole-istio-system
            patches:
              - path: rules[-1]
                value: |
                  apiGroups:
                  - certificates.k8s.io
                  resourceNames:
                  - clusterissuers.cert-manager.io/foo
                  - clusterissuers.cert-manager.io/bar
                  - clusterissuers.cert-manager.io/istio-system
                  resources:
                  - signers
                  verbs:
                  - approve
EOF
$ istioctl install --skip-confirmation -f ./istio.yaml

  2. 创建 bar 和 foo 命名空间。

    $ kubectl create ns bar
$ kubectl create ns foo

  3. 在 bar 命名空间中部署 proxyconfig-bar.yaml 以定义 bar 命名空间中工作负载的 cert-signer。

    $ cat <<EOF > ./proxyconfig-bar.yaml
apiVersion: networking.istio.io/v1beta1
kind: ProxyConfig
metadata:
  name: barpc
  namespace: bar
spec:
  environmentVariables:
    ISTIO_META_CERT_SIGNER: bar
EOF
$ kubectl apply  -f ./proxyconfig-bar.yaml

  4. 在 foo 命名空间中部署 proxyconfig-foo.yaml 以定义 foo 命名空间中工作负载的 cert-signer。

    $ cat <<EOF > ./proxyconfig-foo.yaml
apiVersion: networking.istio.io/v1beta1
kind: ProxyConfig
metadata:
  name: foopc
  namespace: foo
spec:
  environmentVariables:
    ISTIO_META_CERT_SIGNER: foo
EOF
$ kubectl apply  -f ./proxyconfig-foo.yaml

  5. 在 foo 和 bar 命名空间中部署 httpbin 和 curl 示例应用程序。

    $ kubectl label ns foo istio-injection=enabled
$ kubectl label ns bar istio-injection=enabled
$ kubectl apply -f samples/httpbin/httpbin.yaml -n foo
$ kubectl apply -f samples/curl/curl.yaml -n foo
$ kubectl apply -f samples/httpbin/httpbin.yaml -n bar

验证同一命名空间内 httpbin 和 curl 之间的网络连接

当工作负载部署后，它们会发送带有相关签名者信息的 CSR 请求。Istiod 将 CSR 请求转发到自定义 CA 进行签名。自定义 CA 将使用正确的集群颁发者签署证书。foo 命名空间下的工作负载将使用 foo 集群颁发者，而 bar 命名空间下的工作负载将使用 bar 集群颁发者。为了验证它们确实已由正确的集群颁发者签名，我们可以验证同一命名空间下的工作负载可以通信，而不同命名空间下的工作负载则无法通信。

  1. 将 CURL_POD_FOO 环境变量设置为 curl pod 的名称。

    $ export CURL_POD_FOO=$(kubectl get pod -n foo -l app=curl -o jsonpath={.items..metadata.name})

  2. 检查 foo 命名空间中服务 curl 和 httpbin 之间的网络连接。

    $ kubectl exec "$CURL_POD_FOO" -n foo -c curl -- curl http://httpbin.foo:8000/html
<!DOCTYPE html>
<html>
  <head>
  </head>
  <body>
      <h1>Herman Melville - Moby-Dick</h1>

      <div>
        <p>
          Availing himself of the mild...
        </p>
      </div>
  </body>

  3. 检查 foo 命名空间中的服务 curl 和 bar 命名空间中的 httpbin 之间的网络连接。

    $ kubectl exec "$CURL_POD_FOO" -n foo -c curl -- curl http://httpbin.bar:8000/html
upstream connect error or disconnect/reset before headers. reset reason: connection failure, transport failure reason: TLS error: 268435581:SSL routines:OPENSSL_internal:CERTIFICATE_VERIFY_FAILED

清理

  • 删除命名空间并卸载 Istio 和 cert-manager

    $ kubectl delete ns foo
$ kubectl delete ns bar
$ istioctl uninstall --purge -y
$ helm delete -n cert-manager cert-manager
$ kubectl delete ns istio-system cert-manager
$ unset ISTIOCA FOOCA BARCA
$ rm -rf istio.yaml proxyconfig-foo.yaml proxyconfig-bar.yaml selfsigned-issuer.yaml

使用此功能的原因

  • 自定义 CA 集成 - 通过在 Kubernetes CSR 请求中指定签名者名称，此功能允许 Istio 使用 Kubernetes CSR API 接口与自定义证书颁发机构集成。这确实需要自定义 CA 实现一个 Kubernetes 控制器来监视 CertificateSigningRequest 资源并对其进行操作。

  • 更好的多租户 - 通过为不同的工作负载指定不同的 cert-signer，不同租户的工作负载证书可以由不同的 CA 签名。

这些信息是否有用？
您对改进有任何建议吗？

感谢您的反馈！