Stworzyłem sekret za pomocą
kubectl create secret generic production-tls \
--from-file=./tls.key \
--from-file=./tls.crt
Jeśli chciałbym zaktualizować wartości - jak mogę to zrobić?
Stworzyłem sekret za pomocą
kubectl create secret generic production-tls \
--from-file=./tls.key \
--from-file=./tls.crt
Jeśli chciałbym zaktualizować wartości - jak mogę to zrobić?
Odpowiedzi:
To powinno działać:
kubectl create secret generic production-tls \
--from-file=./tls.key --from-file=./tls.crt --dry-run -o yaml |
kubectl apply -f -
--save-config
do kubectl create secret
, aby uniknąć ostrzeżenia CLI.
kubectl create secret tls my-domain-tls --namespace=default --key=./tls.key --cert=./tls.crt --dry-run -o yaml | kubectl apply -f -
certyfikaty były w postaci zwykłego tekstu.
--dry-run=client
z kubectl 1.18 lub nowszym.
Możesz usunąć i od razu odtworzyć sekret:
kubectl delete secret production-tls
kubectl create secret generic production-tls --from-file=./tls.key --from-file=./tls.crt
Umieściłem te polecenia w skrypcie, przy pierwszym wywołaniu otrzymasz ostrzeżenie o (jeszcze) istniejącym tajemnicy, ale to działa.
apply
ma o wiele więcej sensu, dzięki!
--namespace=kube-system
Alternatywnie, można również użyć jq
„s =
lub |=
operatorowi aktualizacji tajemnic w locie.
TLS_KEY=$(base64 < "./tls.key" | tr -d '\n')
TLS_CRT=$(base64 < "./tls.crt" | tr -d '\n')
kubectl get secrets production-tls -o json \
| jq '.data["tls.key"] |= "$TLS_KEY"' \
| jq '.data["tls.crt"] |= "$TLS_CRT"' \
| kubectl apply -f -
Chociaż może nie być tak eleganckie lub proste, jak to kubectl create secret generic --dry-run
podejście, technicznie podejście to polega na prawdziwej aktualizacji wartości, a nie ich usuwaniu / odtwarzaniu. Będziesz także potrzebował jq
i base64
(lub openssl enc -base64
) dostępnych poleceń, tr
jest to powszechnie dostępne narzędzie Linuksa do przycinania końcowych znaków nowej linii.
Zobacz tutaj, aby uzyskać więcej informacji na temat jq
operatora aktualizacji |=
.
Ponieważ nie byłem w stanie odpowiedzieć na powyższą odpowiedź Devy'ego, co mi się podoba, ponieważ zachowa własność, w przypadku gdy usunięcie i ponowne utworzenie może spowodować utratę dodatkowych informacji w rekordzie. Dodam to dla nowszych ludzi, którzy mogą nie od razu zrozumieć, dlaczego ich zmienne nie są interpolowane.
TLS_KEY=$(base64 < "./tls.key" | tr -d '\n')
TLS_CRT=$(base64 < "./tls.crt" | tr -d '\n')
kubectl get secrets production-tls -o json \
| jq ".data[\"tls.key\"] |= \"$TLS_KEY\"" \
| jq ".data[\"tls.crt\"] |= \"$TLS_CRT\"" \
| kubectl apply -f -
To doprowadziło mnie do próby użycia metody „patch” kubectl, która również wydaje się działać.
kubectl \
patch \
secret \
production-tls \
-p "{\"data\":{\"tls.key\":\"${TLS_KEY}\",\"tls.crt\":\"${TLS_CRT}\"}}"
Dzięki Devy za odpowiedź, która najlepiej spełniła moje potrzeby.
Aby rozwinąć te odpowiedzi, stwierdziłem, że dodanie `` --ignore-not-found '' do usunięcia pomogło w naszym CICD, ponieważ nie byłoby błędu, gdyby sekret nie istniał, po prostu kontynuowałby i tworzył go:
kubectl delete secret production-tls --ignore-not-found
kubectl create secret generic production-tls --from-file=./tls.key --from-file=./tls.crt.
W bardziej szczegółowych przypadkach może być konieczne określenie przestrzeni nazw, w której certyfikat należy odnowić, i usunięcie starego.
**For deletion of the cert **
kubectl delete secret -n `namespace`
**For creation of new cert to specific namespace **
kubectl create secret {your-cert-name} --key /etc/certs/{name}.com.key --cert /etc/certs/{name}.com.crt -n {namespace} ```