Kubernetes-在命名空间之间共享秘密


101

有没有一种方法可以在Kubernetes中的命名空间之间共享秘密?

我的用例是:我的所有名称空间都具有相同的私有注册表,并且我想避免为每个名称空间创建相同的秘密。

谢谢你的帮助。


这可以使秘密共享自动化: github.com/zakkg3/ClusterSecret
NicoKowe

Answers:


93

秘密API对象位于名称空间中。它们只能由同一名称空间中的pod引用。基本上,您将必须为每个名称空间创建秘密。

https://kubernetes.io/docs/concepts/configuration/secret/#details



1
这是正确的答案,值得一提的是,您可以通过kubectl + sed克隆到另一个名称空间,全部都在一行中,请参阅下面的答案。
NicoKowe

75

它们只能由同一名称空间中的pod引用。但是您可以将秘密从一个名称空间复制到另一个名称空间。这是将localdockerreg密钥从default名称空间复制到的示例dev

 kubectl get secret localdockerreg --namespace=default --export -o yaml | kubectl apply --namespace=dev -f -

### UPDATE ###不推荐使用Kubernetes v1.14--export标志。因此,以下带有标志的命令将在以后的版本中运行而不会发出警告。-oyaml

kubectl get secret localdockerreg --namespace=default -oyaml | kubectl apply --namespace=dev -f -

或以下(如果源名称空间不一定是默认值)

kubectl get secret localdockerreg --namespace=default -oyaml | grep -v '^\s*namespace:\s' | kubectl apply --namespace=dev -f -

1
如果要导出的机密不在默认名称空间中,则此方法将不起作用
gerasalus

1
对我的作品在任何两个命名空间上V1.13
Kshitij Saraogi

4
嗯,当我使用第二条命令时(无--export标志),我收到一条错误消息:“所提供选项的名称空间不匹配”。kubectl版本1.15。我认为您可能需要sed在这两个kubectl命令之间使用或之间的某种方式,以从输出yaml中删除名称空间
Matt Dodge

6
确切地说,您需要从中间的YAML中删除源名称空间:$ kubectl get secret <SECRET> --namespace <NS-SRC> -oyaml | grep -v '^\s*namespace:\s' | kubectl apply --namespace <NS-DST> -f - ps未经过其他对象类型的测试,但应能正常工作pps如果您要移动,请不要忘记删除源
Costa Shapiro

工作,并在集群之间使用kubectl使用上下文来更改上下文
Vincent Gerris

17

可接受的答案是正确的,如果您要在命名空间之间复制机密,则这里有个提示。

kubectl get secret <secret-name> -n <source-namespace> -o yaml \
| sed s/"namespace: <source-namespace>"/"namespace: <destination-namespace>"/\
| kubectl apply -n <destination-namespace> -f -

/ 2020年4月编辑:

现在,有了一种使用ClusterSecret运算符在名称空间之间共享或同步秘密的方法:

https://github.com/zakkg3/ClusterSecret


7

机密是命名空间资源,但是您可以使用Kubernetes扩展来复制它们。我们使用它来自动将存储在秘密中的凭据或证书传播到所有名称空间,并使它们保持同步(修改源并更新所有副本)。请参阅Kubernetes Reflector(https://github.com/EmberStack/kubernetes-reflector)。

通过扩展,您可以通过注释自动复制名称空间中的秘密并使其同步:

在源密钥上,添加注释:

 annotations:
   reflector.v1.k8s.emberstack.com/reflection-auto-enabled: "true"

这将在所有名称空间中创建密钥的副本。您可以使用以下方法限制创建副本的名称空间:

reflector.v1.k8s.emberstack.com/reflection-allowed-namespaces: "namespace-1,namespace-2,namespace-[0-9]*"

该扩展还支持ConfigMaps和证书管理器证书。声明:我是Kubernetes Reflector扩展的作者。


不错的插件。现在使用它。谢谢!
CTiPKA


1

@NicoKowe的改进

一线将所有机密从一个名称空间复制到另一个名称空间

$ for i in `kubectl get secrets | awk '{print $1}'`; do  kubectl get secret $1 -n <source-namespace> -o yaml | sed s/"namespace: <source-namespace>"/"namespace: <target-namespace>"/ | kubectl apply -n <target-namespace> -f -  ; done

1

--export 不推荐使用

sed 不是用于编辑YAML或JSON的适当工具。

这是一个jq用于删除名称空间和其他我们不想要的元数据的示例:

kubectl get secret cure-for-covid-19 -n china -o json | jq 'del(.metadata["namespace","creationTimestamp","resourceVersion","selfLink","uid"])' | kubectl apply -n rest-of-world -f -

1

基于@Evans Tucker的答案,但在jq过滤器中使用白名单而不是删除来仅保留我们想要的内容。

kubectl get secret cure-for-covid-19 -n china -o json | jq '{apiVersion,data,kind,metadata,type} | .metadata |= {"annotations", "name"}' | kubectl apply -n rest-of-world -f -

本质上是相同的,但是保留标签。

kubectl get secret cure-for-covid-19 -n china -o json | jq '{apiVersion,data,kind,metadata,type} | .metadata |= {"annotations", "name", "labels"}' | kubectl apply -n rest-of-world -f -


0

kubectl获取秘密gitlab-registry --namespace = revsys-com --export -o yaml | \ kubectl apply --namespace = devspectrum-dev -f-


0

使用RBAC来授权serviceaccoun在原始名称空间上使用秘密。但是,建议不要在名称空间之间使用共享的机密。


0

复制所有机密的解决方案。

kubectl delete secret --namespace $TARGET_NAMESPACE--all;
kubectl get secret --namespace default --output yaml \
    | sed "s/namespace: $SOURCE_NAMESPACE/namespace: $TARGET_NAMESPACE/" \
    | kubectl apply --namespace $TARGET_NAMESPACE --filename -;

0

yq是用于编辑YAML文件的有用的命令行工具。我将其与其他答案结合使用以获得此结果:

kubectl get secret <SECRET> -n <SOURCE_NAMESPACE> -o yaml | yq write - 'metadata.namespace' <TARGET_NAMESPACE> | kubectl apply -n <TARGET_NAMESPACE> -f -

0

您可能还会考虑使用GoDaddy的Kubernetes外部机密!您将在其中将机密存储在AWS Secret Manager(ASM)中的位置,GoDaddy的机密控制器将自动创建机密。而且,ASM和K8S集群之间将存在同步。


By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.