使用 k8s/istio/cert-manager 和 vault 保障应用的 tls 安全

新钛云服已累计为您分享690篇技术干货

前言

Vault 是安全应用维护人员最喜欢的 hashcorp 产品之一 。Vault 是存储机密、证书、管理策略、加密数据等内容的安全工具。Vault 使用受信任的身份集中密码和控制访问权限，以此减少对静态、硬编码凭证的需求。它使用集中托管和受保护的加密密钥来动态和静态加密敏感数据，所有一切均可通过单个工作流和 API 实现。

Istio 非常重要的一个功能是能够锁定并且保护网格内的来往流量。本文的目的是基于 TLS 启动一个简单的 Web 应用程序，然后使用 Vault 生成对应的安全证书，从而保证 Istio 管理的服务安全。

简单点说，使用 TLS 时候，当您建立连接时，服务器会提供一个公钥，您可以使用此密钥对传输中的数据进行加密，一旦被目标服务器接收，数据将使用私钥解密。为了验证密钥是否有效，可以使用 CA（通常 CA 是付费服务），但我们可以通过 vault 创建一个自签名 CA）。

现在先让我们忽略 vault，让我们在系统上创建一个测试环境。为此使用 kind (https://kind.sigs.k8s.io/) 来快速创建一个测试环境。

用 kind 建立一个 kubernetes 集群

下载 kind 后，我们可以定义一个 kind 配置文件来启动 4 个 worker。我们还可以配置一些端口映射，以确保我们可以直接访问入口网关。

kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
nodes:
- role: control-plane
extraPortMappings:
- containerPort: 30725
  hostPort: 8080
  listenAddress: "127.0.0.1"
  protocol: TCP
- containerPort: 32652
  hostPort: 8443
  listenAddress: "127.0.0.1"
  protocol: TCP
- role: worker
- role: worker
- role: worker
- role: worker

使用 kind 来创建我们的集群

kind create cluster --name chris --config ~/kube.cfg

节点已启动

kubectl get nodes
NAME                  STATUS   ROLES           AGE   VERSION
chris-control-plane   Ready    control-plane   21h   v1.24.0
chris-worker          Ready    <none>          21h   v1.24.0
chris-worker2         Ready    <none>          21h   v1.24.0
chris-worker3         Ready    <none>          21h   v1.24.0
chris-worker4         Ready    <none>          21h   v1.24.0

使用istioctl (https://github.com/istio/istio/releases) 命令安装 istio 。首先让我们定义一下配置内容。因为我们在本地运行，所以我们降低了一些资源要求。

--- 
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
metadata:
  namespace: istio-system
  name: installed-state
spec: 
  components: 
    ingressGateways: 
      - 
        enabled: true
        name: istio-ingressgateway
        namespace: istio-system
    pilot: 
      k8s: 
        hpaSpec: 
          maxReplicas: 2
          minReplicas: 1
        resources: 
          requests: 
            cpu: 512m
            memory: 512Mi
  profile: default
  values:
    global:
      istioNamespace: istio-system

安装 istio

istioctl manifest install -f ~/istio.cfg

删除默认类型的 istio-ingressgateway 的 service。

kubectl delete svc istio-ingressgateway -n istio-system

创建一个 NodePort 服务，从而实现从节点端口访问 istio-ingressgateway 。

apiVersion: v1
kind: Service
metadata:
  labels:
    app: istio-ingressgateway
    istio: ingressgateway
  name: istio-ingressgateway
  namespace: istio-system
spec:
  type: NodePort
  ports:
  - name: http
    nodePort: 30725
    port: 8080
    protocol: TCP
    targetPort: 8080
  - name: https
    nodePort: 32652
    port: 443
    protocol: TCP
    targetPort: 8443
  selector:
    app: istio-ingressgateway

应用一下

kubectl apply -f svc.yml

此时，istio 应该正常运行。

kubectl get pods -n istio-system
NAME                                    READY   STATUS    RESTARTS   AGE
istio-ingressgateway-5f86977657-qfxrs   1/1     Running   0          21h
istiod-67db665bd9-4d8nl                 1/1     Running   0          21h

我们将创建一个虚拟网关进行测试

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: gateway
  namespace: istio-system
spec:
  selector:
    app: istio-ingressgateway
  servers:
  - port:
      number: 8080
      name: http
      protocol: HTTP
    hosts:
    - "*"

同时应用

kubectl apply -f gateway.yml

使用 curl，我们能够从我们客户端去访问 istio 入口。注意：404 是预期的结果，因为我们还没有配置任何应用程序或 istio 虚拟服务。

curl localhost:8080 -vs        
*   Trying 127.0.0.1...
* TCP_NODELAY set
* Connected to localhost (127.0.0.1) port 8080 (#0)
> GET / HTTP/1.1
> Host: localhost:8080
> User-Agent: curl/7.64.1
> Accept: */*
> 
< HTTP/1.1 404 Not Found
< date: Thu, 28 Jul 2022 21:44:50 GMT
< server: istio-envoy
< content-length: 0
< 
* Connection #0 to host localhost left intact
* Closing connection 0

我们不仅连接了（即使我们得到了 404 ），而且您可以看到服务器是 istio-envoy 响应，这意味着 envoy 正在处理流量。

最后一步，让我们创建一个命名空间并将其标记为 istio 注入以供将来工作。

kubectl create ns web
kubectl label namespace web istio-injection=enabled --overwrite

安装 Vault

如果这是一个生产环境，我们会按照严格标准去调整以及安装 vault，但当前只是一个一次性的测试环境，所以我们不做任何优化调整。

使用 helm 安装 Vault Chart

kubectl create namespace vault
helm repo add hashicorp https://helm.releases.hashicorp.com
helm install vault hashicorp/vault --namespace vault

Vault pod 启动了，但它还没有就绪，因为它当前处于锁定状态。在 pod 中执行以下命令以解封。

kubectl -n vault exec vault-0 -- vault operator init -key-shares=1 -key-threshold=1 -format=json > /tmp/token.json

从 /tmp/token.josn 中取出 unseal_keys_b64 密钥，并使用它来解封 vault。

kubectl exec -n vault vault-0 -- vault operator unseal <key>

现在，vault 应该已解封并处于就绪状态。

kubectl get pods -n vault
NAME                                    READY   STATUS    RESTARTS   AGE
vault-0                                 1/1     Running   0          6m28s
vault-agent-injector-5d4c695bf4-zzgq5   1/1     Running   0          6m29s

现在，我们可以使用 port-forward 来转发访问 vault，并使用可以在 /tmp/token.json 中找到的根令牌登录 vault。

kubectl port-forward vault-0 8200 -n vault
# Open a browser to localhost:8200

现在 vault 已准备就绪，让我们创建一个新的 secret engine，启用新 engine -> PKI Certificates，我使用的是 pki/ 路径。或者，如果启用了 cli，您可以使用以下命令

vault secrets enable pki

将 vault 二进制文件下载到您本地并设置 vault 地址和令牌。

brew install vault
export VAULT_ADDR=http://127.0.0.1:8200
export VAULT_TOKEN=<key>

现在我们可以从 cli 与 Vault 进行交互了

vault status    
Key             Value
---             -----
Seal Type       shamir
Initialized     true
Sealed          false
Total Shares    1
Threshold       1
Version         1.10.3
Build Date      n/a
Storage Type    file
Cluster Name    vault-cluster-d4e826eb
Cluster ID      76196d6e-0033-b892-4826-2674b6befe23
HA Enabled      false

我们想给 istio 一个证书以供 CA 验证，所以让我们在 Vault 中创建一个。首先调整一些租期时间（10 年）。

vault secrets tune -max-lease-ttl=87600h pki

创建一个名为 allowit 的角色，然后定义要发送到 CA 的 CSR 的路径。本处将使用域名 somecompany.com 进行所有测试。

# create a role
vault write pki/roles/allowit allow_any_name=true
# generate 
vault write -field=certificate pki/root/generate/internal \
     common_name="somecompany.com" \
     issuer_name="root" \
     ttl=87600h > ca.crt
# config
vault write pki/config/urls \
issuing_certificates="$VAULT_ADDR/v1/pki/ca" \
crl_distribution_points="$VAULT_ADDR/v1/pki/crl"

我们当前在做的是为访问路径设置角色以与 CA 一起使用。

现在是时候获得中间证书了。CA 虽然很不错，它确认了证书属于正确的人，但它有很大的权力。中间证书基本上是一种从另一个 CA 创建 CA 的方法。最佳做法是使用中间证书。根证书将能够撤销任何中间 CA。

但如下所见，步骤类似，我们现在使用的是 pki_int 路径。

vault secrets enable -path=pki_int pki
vault secrets tune -max-lease-ttl=43800h pki_int
vault write -format=json pki_int/intermediate/generate/internal \
     common_name="somecompany.com Intermediate Authority" \
     issuer_name="somecompany-intermediate" \
     | jq -r '.data.csr' > pki_intermediate.csr
vault write -format=json pki/root/sign-intermediate \
     issuer_ref="root" \
     csr=@pki_intermediate.csr \
     format=pem_bundle ttl="43800h" \
     | jq -r '.data.certificate' > intermediate.cert.pem

仍然使用 somecompany.com 域名，确保颁发者名称与根 CA 和中间 CA 的颁发者名称相同（在此示例中仅称为 root）。

将签名的证书写回 vault 。

vault write pki_int/intermediate/set-signed [email protected]

现在我们的 CA 和中间证书已经创建好了。我们应该为它创建一个角色。

vault write pki_int/roles/example-dot-com \
issuer_ref="$(vault read -field=default pki_int/config/issuers)" \
allowed_domains="somecompany.com" \
allow_subdomains=true \
max_ttl="720h"

目前，我们都准备好了！我们已经创建了一个带有 vault 的 CA 和中间 CA！

让我们测试一下！让我们向 vault 申请 chris.somecompany.com 的 24 小时有效证书。（这将返回 CA、证书和私钥）

vault write pki_int/issue/allowit common_name="chris.somecompany.com" ttl="24h"

本处只关心证书，所以将上面命令返回的base64复制并粘贴到一个临时文件中，然后使用openssl 进行检查。

openssl x509 -in site -text | head -n 10
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            4f:87:f9:6f:eb:68:db:2a:39:f5:06:1e:43:32:98:04:32:2e:df:4d
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: CN=somecompany.com Intermediate Authority
        Validity
            Not Before: Jul 29 20:32:09 2022 GMT
            Not After : Jul 30 20:32:39 2022 GMT
        Subject: CN=chris.somecompany.com
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption

从上面的输出可以看出，证书有效期为 24 小时，对 chris.somecompany.com 有效，包含我们要求的所有内容！

目前的操作都是通过命令行，忽略使用 vault UI，但我们也可以使用 UI 来执行上述所有步骤。例如，我们可以在 UI 上看到我们的证书。

Cert manager

helm repo add jetstack https://charts.jetstack.io
helm repo update
kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.9.1/cert-manager.crds.yaml
helm install \
  cert-manager jetstack/cert-manager \
  --namespace cert-manager \
  --create-namespace \
  --version v1.9.1

kubectl get crd | grep cert
certificaterequests.cert-manager.io        2022-07-29T20:59:11Z
certificates.cert-manager.io               2022-07-29T20:59:11Z
challenges.acme.cert-manager.io            2022-07-29T20:59:11Z
clusterissuers.cert-manager.io             2022-07-29T20:59:11Z
issuers.cert-manager.io                    2022-07-29T20:59:11Z
orders.acme.cert-manager.io                2022-07-29T20:59:11Z

vault auth enable approle

#policy.hcl
path "pki*" {  capabilities = ["create", "read", "update", "delete", "list", "sudo"]}

vault policy write pki_policy policy.hcl

vault write auth/approle/role/certmanager secret_id_ttl=8760h token_num_uses=0 token_ttl=20m token_max_ttl=30m secret_id_num_uses=0 policies=pki_policy

vault read auth/approle/role/certmanager/role-id
Key        Value
---        -----
role_id    bb3cdc37-9fe0-f99f-99d4-1ff80d26ab1d

vault write -f auth/approle/role/certmanager/secret-id

apiVersion: v1
kind: Secret
type: Opaque
metadata:
 name: cert-manager
 namespace: istio-system
data:
 secretId: <base64 key> 

配置 cert-manager

---
apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
   name: istio
   namespace: istio-system
spec:
   vault:
     path: pki_int/sign/allowit
     server: http://vault-internal.vault.svc.cluster.local:8200
     auth:
       appRole:
         path: approle
         roleId: "bb3cdc37-9fe0-f99f-99d4-1ff80d26ab1d"
         secretRef:
           name: cert-manager
           key: secretIda

---
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
 name: istio
 namespace: istio-system
spec:
 secretName: my-cert
 issuerRef:
   name: istio
 commonName: chris.somecompany.com
 dnsNames:
 - chris.somecompany.com

kubectl -n istio-system get Issuer
NAME    READY   AGE
istio   True    5m34s
kubectl -n istio-system get Certificate
NAME    READY   SECRET    AGE
istio   True    my-cert   5m57s

kubectl -n istio-system get secret my-certNAME      TYPE                DATA   AGEmy-cert   kubernetes.io/tls   3      6m43s

创建示例应用

kubectl -n web create deploy nginx --image=nginx --port 80
kubectl -n web expose deploy nginx --port 80

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: nginx
  namespace: web
spec:
  gateways:
  - istio-system/https
  hosts:
  - "chris.somecompany.com"
  http:
  - route:
    - destination:
        host: nginx

---
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: https
  namespace: istio-system
spec:
  selector:
    app: istio-ingressgateway
  servers:
  - port:
      number: 8443
      name: https
      protocol: HTTPS
    hosts:
    - "chris.somecompany.com"
    tls:
      mode: SIMPLE
      credentialName: my-cer

kubectl -n istio-system port-forward istio-ingressgateway-5f86977657-qfxrs 8443

kubectl -n istio-system get secret my-cert -o json | jq -r '.data["ca.crt"]' | base64 -d > ca.crt
open ca.crt
# mark as always trust

总结