如何为所有名称空间更新Kubernetes机密

Bis*_*sec 0 docker google-cloud-platform gitlab-ci kubernetes

我正在通过Kubernetes引擎在Google Cloud Platform上使用docker和kubernetes。我有在app.yaml文件中配置的机密,如下所示:

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: app
  namespace: $CI_COMMIT_REF_SLUG
  labels:
    app: app
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: app
    spec:
      containers:
      - name: app
        image: gcr.io/engagement-org/app:$CI_COMMIT_SHA
        imagePullPolicy: Always
        ports:
        - containerPort: 9000
        env:
        - name: MAILJET_APIKEY_PUBLIC
          valueFrom:
            secretKeyRef:
              name: mailjet
              key: apikey_public
        - name: MAILJET_APIKEY_PRIVATE
          valueFrom:
            secretKeyRef:
              name: mailjet
              key: apikey_private
Run Code Online (Sandbox Code Playgroud)

每次我按下一个新分支时,都会通过gitlab-ci文件中的部署创建一个新的名称空间。秘密是这样创建的:

 - kubectl create secret generic mailjet --namespace=$CI_COMMIT_REF_SLUG --from-literal=apikey_public=$MAILJET_APIKEY_PUBLIC --from-literal=apikey_private=$MAILJET_APIKEY_PRIVATE || echo 'Secret already exist'; 
Run Code Online (Sandbox Code Playgroud)

现在,我已经更新了mailjet api密钥,并希望对所有名称空间进行更改。我可以通过在Pod上获得外壳并运行来编辑每个命名空间上的秘密kubectl edit secret mailjet --namespace=<namespace_name>

我想要的是将新的秘密值发送到将来将要创建的新容器中。当我部署一个新值时,它仍然使用旧值。

据我了解,gitlab-ci文件使用app.yaml文件将环境变量替换为值。但是我不明白app.yaml在哪里找到原始值。

谢谢您的帮助。

hel*_*ert 9

通常,Kubernetes命名空间旨在为在其中运行的组件提供隔离。因此,Kubernetes API并非真正旨在跨命名空间执行更新操作,或使秘密可用于命名空间。

话虽如此,有一些事情可以解决这个问题。

1.使用单个名称空间和Helm版本,而不是单独的名称空间

从外观上看,您正在使用Gitlab CI部署各个分支来审核环境(大概使用了Gitlab的Review App功能?)。通过将所有Review Apps部署到同一名称空间中,并使用Helm在单个名称空间中管理同一应用程序的多个部署(以Helm而言,“发布”),可以实现相同的结果。

在中gitlab-ci.yml,为新分支创建Helm版本可能类似于以下内容:

script:
- helm upgrade --namespace default --install review-$CI_COMMIT_REF_SLUG ./path/to/chart
Run Code Online (Sandbox Code Playgroud)

当然,这要求您为应用程序定义了一个Helm图表(从本质上讲,这是一组YAML模板,带有一组默认变量,然后可以为各个版本覆盖这些默认变量)。有关创建Helm图表的更多信息,请参阅文档(上面链接)。

2.使机密在名称空间之间保持同步

不久前,我们遇到了类似的问题,因此我们编写了一个自定义的Kubernetes控制器,该控制器在各个名称空间之间使机密保持同步。它是开源的,您可以在GitHub上找到它(请谨慎使用)。它基于注释,并提供来自单个权威父密钥的更改的单向传播:

apiVersion: v1
kind: Secret
metadata:
  name: mailjet
  namespace: some-kubernetes-namespace
  annotations:
    replicator.v1.mittwald.de/replicate-from: default/mailjet
Run Code Online (Sandbox Code Playgroud)

在您的集群中部署了秘密复制器后,使用此批注会将mailjetdefault名称空间中的秘密所做的所有更改传播到任何带名称空间的已注释的秘密,如上所示。