Kubernetes - udostępnianie hasła w przestrzeniach nazw

Czy istnieje sposób udostępniania wpisów tajnych w przestrzeniach nazw w Kubernetes?

Mój przypadek użycia jest następujący: mam ten sam prywatny rejestr dla wszystkich moich przestrzeni nazw i chcę uniknąć tworzenia tego samego klucza tajnego dla każdego.

Dzięki za pomoc.

Tajne obiekty API znajdują się w przestrzeni nazw. Mogą się do nich odwoływać tylko pody w tej samej przestrzeni nazw. Zasadniczo będziesz musiał utworzyć sekret dla każdej przestrzeni nazw.

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

Mogą się do nich odwoływać tylko pody w tej samej przestrzeni nazw. Ale możesz po prostu skopiować sekret z jednej przestrzeni nazw do drugiej. Oto przykład kopiowania klucza localdockerregtajnego z defaultprzestrzeni nazw do dev:

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

### UPDATE ### W Kubernetes v1.14 --exportflaga jest przestarzała . Tak więc następujące polecenie z -oyamlflagą będzie działać bez ostrzeżenia w przyszłych wersjach.

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

lub poniżej, jeśli źródłowa przestrzeń nazw niekoniecznie jest domyślna

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

Przyjęta odpowiedź jest prawidłowa, oto wskazówka, jeśli chcesz skopiować sekret między przestrzeniami nazw.

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

/ edytuj kwiecień 2020:

Teraz istnieje sposób na udostępnianie lub synchronizowanie klucza tajnego w przestrzeniach nazw i jego przy użyciu operatora ClusterSecret:

https://github.com/zakkg3/ClusterSecret

Sekrety to zasoby w przestrzeni nazw, ale do ich replikacji możesz użyć rozszerzenia Kubernetes. Używamy tego do automatycznego propagowania poświadczeń lub certyfikatów przechowywanych w tajemnicach do wszystkich przestrzeni nazw i utrzymywania ich synchronizacji (modyfikuj źródło, a wszystkie kopie są aktualizowane). Zobacz Kubernetes Reflector ( https://github.com/EmberStack/kubernetes-reflector ).

Rozszerzenie umożliwia automatyczne kopiowanie i synchronizowanie tajemnicy w przestrzeniach nazw za pośrednictwem adnotacji:

W tajemnicy źródłowej dodaj adnotacje:

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

Spowoduje to utworzenie kopii klucza we wszystkich przestrzeniach nazw. Możesz ograniczyć przestrzenie nazw, w których tworzona jest kopia, używając:

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

Rozszerzenie obsługuje również certyfikaty ConfigMaps i cert-manager. Disclainer: Jestem autorem rozszerzenia Kubernetes Reflector.

Jak odpowiedział Innocent Anigbo, musisz mieć sekret w tej samej przestrzeni nazw. Jeśli chcesz wspierać to dynamicznie lub unikać zapomnienia o tworzeniu sekretów, może być możliwe utworzenie inicjatora dla obiektu przestrzeni nazw https://kubernetes.io/docs/admin/extensible-admission-controllers/ (nie zrobiłem tego samodzielnie , więc nie mogę tego powiedzieć na pewno)

Poprawa z @NicoKowe

Jedna linijka do kopiowania wszystkich sekretów z jednej przestrzeni nazw do drugiej

$ 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

--export jest przestarzałe

sed nie jest odpowiednim narzędziem do edycji YAML lub JSON.

Oto przykład, który służy jqdo usuwania przestrzeni nazw i innych metadanych, których nie chcemy:

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 -

Oparty na odpowiedzi @Evans Tucker, ale używa białej listy zamiast usuwania w filtrze jq, aby zachować tylko to, co chcemy.

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 -

Zasadniczo to samo, ale zachowuje etykiety.

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 -

kubectl pobiera tajny rejestr gitlab --namespace = revsys-com --export -o yaml | \ kubectl apply --namespace = devspectrum-dev -f -

Użyj RBAC, aby autoryzować serviceaccoun do używania wpisu tajnego w oryginalnych przestrzeniach nazw. Nie zaleca się jednak posiadania wspólnego sekretu między zestawami nazw.

Rozwiązanie do kopiowania wszystkich sekretów.

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

yqto przydatne narzędzie wiersza poleceń do edycji plików YAML. Użyłem tego w połączeniu z innymi odpowiedziami, aby uzyskać to:

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

Możesz także pomyśleć o użyciu zewnętrznych sekretów Kubernetes firmy GoDaddy ! gdzie będziesz przechowywać swoje sekrety w AWS Secret Manager (ASM), a tajny kontroler GoDaddy automatycznie utworzy sekrety. Ponadto byłaby synchronizacja między klastrem ASM i K8S.

Inną opcją byłoby użycie kubed , zgodnie z zaleceniami ludzi z Jetstack, którzy przekazali nam cert-managera. Oto, do czego prowadzą linki.