Geheim delen tussen naamruimten

Is er een manier om geheimen te delen tussen naamruimten in Kubernetes?

Mijn gebruiksvoorbeeld is: ik heb hetzelfde privéregister voor al mijn naamruimten en ik wil voorkomen dat ik voor elke naamruimte hetzelfde geheim maak.


Antwoord 1, autoriteit 100%

Geheime API-objecten bevinden zich in een naamruimte. Er kan alleen naar worden verwezen door pods in dezelfde naamruimte. Kortom, u moet het geheim voor elke naamruimte maken.

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


Antwoord 2, autoriteit 95%

Er kan alleen naar worden verwezen door pods in dezelfde naamruimte. Maar u kunt het geheim gewoon van de ene naamruimte naar de andere kopiëren. Hier is een voorbeeld van het kopiëren van localdockerreggeheim van defaultnaamruimte naar dev:

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

###UPDATE###
In Kubernetes v1.14 is de --exportvlag verouderd. Het volgende commando met de vlag -oyamlwerkt dus zonder waarschuwing in toekomstige versies.

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

of hieronder als de bronnaamruimte niet noodzakelijk standaard is

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

Antwoord 3, autoriteit 30%

Het geaccepteerde antwoord is correct: naar geheimen kan alleen worden verwezen door pods in dezelfde naamruimte. Dus hier is een hint als je de “synchronisatie” wilt automatiseren of gewoon het geheim tussen naamruimten wilt kopiëren.

Geautomatiseerd (operator)

Gebruik de ClusterSecret-operator voor het automatiseren van het delen of synchroniseren van het geheim tussen naamruimten:

https://github.com/zakkg3/ClusterSecret

Sed gebruiken:

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

Gebruik jq

Als je jq hebt, kunnen we de @Evans Tucker-oplossing gebruiken

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 -

Antwoord 4, autoriteit 11%

Geheimen zijn resources met een naamruimte, maar u kunt een Kubernetes-extensie gebruiken om ze te repliceren. We gebruiken dit om referenties of certificaten die in geheimen zijn opgeslagen automatisch door te geven aan alle naamruimten en ze synchroon te houden (wijzig de bron en alle kopieën worden bijgewerkt).
Zie Kubernetes Reflector (https://github.com/EmberStack/kubernetes-reflector).

Met de extensie kunt u automatisch een geheim kopiëren en synchroniseren tussen naamruimten via annotaties:

Voeg de annotaties toe aan het brongeheim:

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

Hiermee wordt een kopie van het geheim in alle naamruimten gemaakt. U kunt de naamruimten waarin een kopie wordt gemaakt, beperken met:

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

De extensie ondersteunt ook ConfigMaps- en cert-manager-certificaten.
Dislainer: ik ben de auteur van de Kubernetes Reflector-extensie.


Antwoord 5, autoriteit 11%

--exportis verouderd

sedis niet de juiste tool voor het bewerken van YAML of JSON.

Hier is een voorbeeld dat jqgebruikt om de naamruimte en andere metadata die we niet willen verwijderen:

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 -

Antwoord 6, autoriteit 5%

Een andere optie zou zijn om kubed te gebruiken, zoals aanbevolen door de aardige mensen van Jetstack die ons cert-manager gaf. Dit is waar ze naar linken.


Antwoord 7, autoriteit 2%

Zoals beantwoord door Innocent Anigbo, moet je het geheim in dezelfde naamruimte hebben. Als u dat dynamisch moet ondersteunen of het creëren van geheimen niet vergeet, is het misschien mogelijk om een ​​initialisatie voor naamruimteobject https://kubernetes.io/docs/admin/extensible-admission-controllers/(heb dat niet alleen gedaan, dus kan het niet met zekerheid zeggen)


Antwoord 8, autoriteit 2%

Verbeteren van @NicoKowe

Eén voering om alle geheimen van de ene naamruimte naar de andere te kopiëren

$ 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

Antwoord 9, autoriteit 2%

Gebaseerd op het antwoord van @Evans Tucker, maar gebruikt whitelisting in plaats van verwijdering binnen het jq-filter om alleen te behouden wat we willen.

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 -

In wezen hetzelfde, maar met behoud van labels.

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 -


Antwoord 10

Gebruik RBAC om de serviceaccount te autoriseren om het geheim op de oorspronkelijke naamruimten te gebruiken. Maar dit wordt niet aanbevolen om een ​​gedeeld geheim te hebben tussen nameapces.


Antwoord 11

Oplossing voor het kopiëren van alle geheimen.

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 -;

Antwoord 12

yqis een handig opdrachtregelprogramma voor het bewerken van YAML bestanden. Ik heb dit in combinatie met de andere antwoorden gebruikt om dit te krijgen:

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

Antwoord 13

Je kunt ook overwegen om GoDaddy’s Kubernetes External Secrets te gebruiken ! waar je je geheimen opslaat in AWS Secret Manager (ASM) en GoDaddy’s geheime controller zal de geheimen automatisch creëren. Bovendien zou er synchronisatie zijn tussen ASM- en K8S-cluster.


Antwoord 14

kubectl get secret gitlab-registry –namespace=revsys-com –export -o yaml |\
kubectl apply –namespace=devspectrum-dev -f –

Other episodes