Mam projekt, w którym kontenery będą migrowane do GKE (to gdzie i jak działały wcześniej nie ma znaczenia) i pytanie jak najlepiej ugryźć temat security pod kątem trzymania&zaciągania secretów z Secret Managera. To, że secretów nie chcemy trzymać w kubernetesowych secretach to wiemy na pewno, bo jak zapewne każdy wie - są średnio bezpieczne. Chcemy do tego wykorzystać googlowski Secret Manager i teraz pytanie - jak najlepiej wdrożyć to, aby aplikacje potrafiły się z nim komunikować?
Jest kilka pomysłów : 1. Wymusić na deweloprach żeby do swoich apek dorzucili wspacie biblioteki Secret managera i dzięki temu aplikacje będą w prosty sposób sobie wstrzykiwały secrety do envów komunikując się po API googla. To rozwiązanie wydaje mi się najlepsze i najbezpieczniejsze, no ale wdrożenie tego rozwiązania będzię leżało po stronie zespołów konkretnych mikroserwsiów.
2. CSI Driver, to drugi (z dwóch xD) z rekomendowanych przez Google sposobów ogarnięcia tego problemu. Sprawdziliśmy to narzędzie i działa fajnie tylko połowicznie. Spoko to działa, gdy w Secret Managerze trzymane są secrety w postaci pilków, bo wtedy aplikacja bezpośrednio zasysa cały plik z secretami. Problem pojawia się natomiast, gdy w Secret Managerze trzyma się secrety klucz:wartość, bo wtedy CSI driver musi zaciągnąć i jednocześnie utworzyć secret na k8s - mija się to z celem (nie chcemy trzymać żadnych secretów w kubernetesie). Kolejnym minusem jest to, że nie jest to oficjalny projekt Googla i tego nie utrzymują. Tutaj widzę, że np AWS oficjalnie u siebie to wspiera i chyba lepiej to działa niż w GCP.
3. Init container który zasysa secrety i przekazuje je do apki - wydaje się to ultra anty praktyczne rozwiązanie i napewno nie chcemy tego.
4. External secret, jeszcze go nie testowałem, ale wygląda dobrze. Korzysta ktoś z tego produkcyjnie?
A jak to wygląda u Was? Programiści korzystają z libek do secretów, czy może np. nie przywiązujecie takiej uwagi do bezpieczeństwa i trzymacie secrety normalnie w kubernetesowych secretach?
@Gennwat U siebie od jakiegoś czasu korzystam z CSI drivera z secret providerem dla AWS'a i działa to spoko. Używam ze względu na łatwą integrację z gitopsowymi toolami. Należy pamiętać o jednym - dobrze zabezpieczony klaster to podstawa. Jak ogarnięty spec Ci się #!$%@? do środka to niezależnie od tego gdzie będą trzymane sekrety, to da radę je wyciągnąć tak czy siak.
@Gennwat: jeśli jesteście w stanie jednogłośnie stwierdzić, że chcecie się pożenić z GKE to rozwiązanie #1 ma największy sens, a każde inne będzie to po prostu jako tymczasowy work-around, bo domyślnie i tak będziecie chcieli mieć to maksymalnie uproszczone.
#3 to rozumiem trochę taki sidecar, nie musi być wcale głupie jeśli nie chcecie mieć extra bibliotek w swoich serwisach. Z tego co rozumiem to #4 jest trochę tego typu sidecarem, więc
@rippie: No właśnie AWS ma chyba lepiej wdrożonego tego CSI drivera jak tak patrze (nie testowałem na EKS). Największym minusem wdrożenia tego na GCP jest to, że jakbym chciał wykorzystywać SM do trzymania klucz:wartość, to CSI klonuje to i tak tworzy secret na klastrze :( w AWS też tak jest?
Co do bezpieczeństwa klastra, tak - masz rację :) Natomiast secrety, to jeden z elementów nad którym pracujemy żeby było wszystko
@Gennwat: Z tego co wiem AWS każdy pojedyńczy parametr, sekret, czy sekrety w formie par key-value trzyma jako sekrety w EKS. Nie da się chyba inaczej, bo CSI driver i tak tworzy volume, który wszystko zasysa z Secret Managerów. Jeśli da się inaczej, to chętnie się dowiem.
@BreathDeath: jeżeli dobrze rozumiem, to external secret domyślnie mirroruje secrety ze Secret Managera? Czyli tworzysz secret w Secret Managerze (bądź w AWS'owym odpowiedniku), spinasz to z external secretem na klastrze, a on zaciąga z Secret Managera i tworzy na podstawie tego kubernetesowy secret, który możesz wykorzystać jak chcesz?
Chcemy do tego wykorzystać googlowski Secret Manager i teraz pytanie - jak najlepiej wdrożyć to, aby aplikacje potrafiły się z nim komunikować?
Jest kilka pomysłów :
1. Wymusić na deweloprach żeby do swoich apek dorzucili wspacie biblioteki Secret managera i dzięki temu aplikacje będą w prosty sposób sobie wstrzykiwały secrety do envów komunikując się po API googla.
To rozwiązanie wydaje mi się najlepsze i najbezpieczniejsze, no ale wdrożenie tego rozwiązania będzię leżało po stronie zespołów konkretnych mikroserwsiów.
2. CSI Driver, to drugi (z dwóch xD) z rekomendowanych przez Google sposobów ogarnięcia tego problemu. Sprawdziliśmy to narzędzie i działa fajnie tylko połowicznie. Spoko to działa, gdy w Secret Managerze trzymane są secrety w postaci pilków, bo wtedy aplikacja bezpośrednio zasysa cały plik z secretami.
Problem pojawia się natomiast, gdy w Secret Managerze trzyma się secrety klucz:wartość, bo wtedy CSI driver musi zaciągnąć i jednocześnie utworzyć secret na k8s - mija się to z celem (nie chcemy trzymać żadnych secretów w kubernetesie). Kolejnym minusem jest to, że nie jest to oficjalny projekt Googla i tego nie utrzymują.
Tutaj widzę, że np AWS oficjalnie u siebie to wspiera i chyba lepiej to działa niż w GCP.
3. Init container który zasysa secrety i przekazuje je do apki - wydaje się to ultra anty praktyczne rozwiązanie i napewno nie chcemy tego.
4. External secret, jeszcze go nie testowałem, ale wygląda dobrze. Korzysta ktoś z tego produkcyjnie?
A jak to wygląda u Was? Programiści korzystają z libek do secretów, czy może np. nie przywiązujecie takiej uwagi do bezpieczeństwa i trzymacie secrety normalnie w kubernetesowych secretach?
#devops #gcp #google #programowanie #programista15k
Należy pamiętać o jednym - dobrze zabezpieczony klaster to podstawa. Jak ogarnięty spec Ci się #!$%@? do środka to niezależnie od tego gdzie będą trzymane sekrety, to da radę je wyciągnąć tak czy siak.
#3 to rozumiem trochę taki sidecar, nie musi być wcale głupie jeśli nie chcecie mieć extra bibliotek w swoich serwisach. Z tego co rozumiem to #4 jest trochę tego typu sidecarem, więc
Co do bezpieczeństwa klastra, tak - masz rację :) Natomiast secrety, to jeden z elementów nad którym pracujemy żeby było wszystko
Czyli tworzysz secret w Secret Managerze (bądź w AWS'owym odpowiedniku), spinasz to z external secretem na klastrze, a on zaciąga z Secret Managera i tworzy na podstawie tego kubernetesowy secret, który możesz wykorzystać jak chcesz?