如何在 Kubernetes 中使用 Vault HA 执行滚动更新?
How perform a rolling update with Vault HA in Kubernetes?
我是 运行 K8s 中的 HashiCorp Vault 无状态集,在三个节点上有 3 pods。
部署后我手动解封 Vault。然后保险库一直保持未密封状态。
问题是当其中一个节点重新启动时,Vault pod 以未密封模式重新启动。
有没有办法通过与已经解封的 pods 之一的服务器-服务器通信自动解封 Vault 节点?
我不想在我的 Kubernetes 环境更新并且所有节点重新启动(滚动更新 - 一个接一个)时手动解封 Vault pods。
我也不想将解封密钥存储在 K8s 秘密甚至文件中,因为这会使我的秘密加密变得无用。
这是我的 yaml:
apiVersion: v1
kind: Service
metadata:
name: vault
spec:
clusterIP: None
ports:
- name: http
port: 8200
- name: server
port: 8201
selector:
xyz.service: vault
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: vault
labels:
xyz.service: vault
spec:
serviceName: "vault"
selector:
matchLabels:
xyz.service: vault
replicas: 3
template:
metadata:
labels:
xyz.service: vault
spec:
imagePullSecrets:
- name: reg-dhc-xyzoms-pull-secret
securityContext:
runAsUser: 100
fsGroup: 1000
affinity:
podAntiAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- key: xyz.service
operator: In
values:
- vault
topologyKey: kubernetes.io/hostname
containers:
- name: vault
image: vault:0.11.0
resources:
requests:
memory: "100Mi"
env:
- name: SKIP_SETCAP
value: dontcare
- name: POD_IP
valueFrom:
fieldRef:
fieldPath: "status.podIP"
- name: "VAULT_CLUSTER_ADDR"
value: "https://$(POD_IP):8201"
ports:
- name: http
containerPort: 8200
protocol: "TCP"
- name: server
containerPort: 8201
protocol: "TCP"
经过更多的挖掘我了解到,我想要的是不可能的。
每当 Vault 实例重新启动时,它将首先被解封,并且无法使用 Vault 自己的技术自动解封它。
您可以在 GitHub 和 Docker store 中找到很多 "vault-unsealer" 实现,它们试图通过定期检查 Vault 来填补这个空白pods 声明并在必要时开封。
建议使用 K8s readinessprobe 来避免服务访问密封的 Vault pod。
由于没有官方 "vault-unsealer" 图像,因此必须谨慎使用 public 实现。我最终编写了自己的 "vault-unsealer" 以避免安全漏洞和许可问题。
我的解决方案是每个 Vault pod 都有一个 sidecar-container。解封密钥首先必须在一个 sidecar 中使用 kubectl exec ...
手动输入一次。
sidecars 定期检查所有 Vault pods 并在密封时将解封密钥传达给另一个 sidecars。如果 Sidecar 收到解封密钥,它们将存储在内存中并用于解封其自己的 Vault 实例。
kubect aply -f vault.yaml
-> vault-0 开始
kubectl exec vault-0 -c sidecar ...
输入解封密钥 -> vault-0 sidecar 解封 vault-0 并准备就绪
- vault-1 开始
- vault-0 sidecar 检测到 vault-1 已解封并调用 vault-1 sidecar 来传输解封密钥。 -> vault-1 sidecar 解封 vault-0 并准备就绪
- 等等...
我是 运行 K8s 中的 HashiCorp Vault 无状态集,在三个节点上有 3 pods。
部署后我手动解封 Vault。然后保险库一直保持未密封状态。
问题是当其中一个节点重新启动时,Vault pod 以未密封模式重新启动。 有没有办法通过与已经解封的 pods 之一的服务器-服务器通信自动解封 Vault 节点?
我不想在我的 Kubernetes 环境更新并且所有节点重新启动(滚动更新 - 一个接一个)时手动解封 Vault pods。
我也不想将解封密钥存储在 K8s 秘密甚至文件中,因为这会使我的秘密加密变得无用。
这是我的 yaml:
apiVersion: v1
kind: Service
metadata:
name: vault
spec:
clusterIP: None
ports:
- name: http
port: 8200
- name: server
port: 8201
selector:
xyz.service: vault
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: vault
labels:
xyz.service: vault
spec:
serviceName: "vault"
selector:
matchLabels:
xyz.service: vault
replicas: 3
template:
metadata:
labels:
xyz.service: vault
spec:
imagePullSecrets:
- name: reg-dhc-xyzoms-pull-secret
securityContext:
runAsUser: 100
fsGroup: 1000
affinity:
podAntiAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- key: xyz.service
operator: In
values:
- vault
topologyKey: kubernetes.io/hostname
containers:
- name: vault
image: vault:0.11.0
resources:
requests:
memory: "100Mi"
env:
- name: SKIP_SETCAP
value: dontcare
- name: POD_IP
valueFrom:
fieldRef:
fieldPath: "status.podIP"
- name: "VAULT_CLUSTER_ADDR"
value: "https://$(POD_IP):8201"
ports:
- name: http
containerPort: 8200
protocol: "TCP"
- name: server
containerPort: 8201
protocol: "TCP"
经过更多的挖掘我了解到,我想要的是不可能的。 每当 Vault 实例重新启动时,它将首先被解封,并且无法使用 Vault 自己的技术自动解封它。
您可以在 GitHub 和 Docker store 中找到很多 "vault-unsealer" 实现,它们试图通过定期检查 Vault 来填补这个空白pods 声明并在必要时开封。
建议使用 K8s readinessprobe 来避免服务访问密封的 Vault pod。
由于没有官方 "vault-unsealer" 图像,因此必须谨慎使用 public 实现。我最终编写了自己的 "vault-unsealer" 以避免安全漏洞和许可问题。
我的解决方案是每个 Vault pod 都有一个 sidecar-container。解封密钥首先必须在一个 sidecar 中使用 kubectl exec ...
手动输入一次。
sidecars 定期检查所有 Vault pods 并在密封时将解封密钥传达给另一个 sidecars。如果 Sidecar 收到解封密钥,它们将存储在内存中并用于解封其自己的 Vault 实例。
kubect aply -f vault.yaml
-> vault-0 开始kubectl exec vault-0 -c sidecar ...
输入解封密钥 -> vault-0 sidecar 解封 vault-0 并准备就绪- vault-1 开始
- vault-0 sidecar 检测到 vault-1 已解封并调用 vault-1 sidecar 来传输解封密钥。 -> vault-1 sidecar 解封 vault-0 并准备就绪
- 等等...