Názory k článku Bezpečné ukládání a externí správa konfiguračních hodnot v Kubernetes
-
Z alternativních řešení se nám osvědčil ještě SopsOperator
https://github.com/isindir/sops-secrets-operatorNarozdíl od obyčejného SOPSu, který je v článku zmíněn, umožńuje mít v repozitáři uložená šifrovaná hesla a rozšifrovávají se až po uložení do clusteru. Hraje to pěkně s CI/CD pipelinami.
Funguje podobně jako Sealed-Secrets Operator. V gitovém repozitáři jsou uložená přešifrované Secrets, a SealedSecrets operátor je v clusteru rozšifruje svým privátním klíčem.
Výhoda oproti Sealed-Secrets je, že hesla můžu na svém laptopu rozšifrovat, upravit a zase zašifrovat. V některých případech to může být ovšem i nevýhoda.
Pokud jsou u klienta ještě implementovány nějaké nástroje na správu hesel ( Hashicorp Vault, AWS SecretsManager ), tak SopsOperator je poměrně málo pracné a funkční řešení.
-
External-secrets používám též. Dospěl jsem v AWS k automatičtějšímu procesu. V rámci CDK pipeline se aplikaci definuje jak samotný k8s namespace, tak i servisní account pro přístup k secretům.
V k8s objektu SecretStore potom nastavuju, aby používal právě ten vytvořený service account. Pak už zafunguje IAM roles for Service Accounts (IRSA) a vygenerovaná IAM policy, která povolí external-secrets operátoru přístup do Secret Managera.Když mají všechny secrety aplikace (např. hesla od managed db) podle konvence nějaký prefix, může IAM policy omezit přístup jen k secretům s prefixem pomocí hvězdičky v atributu resource.
-
Moje zkušenost z projektu. Nejdříve jsme používali Sealed Secret a to mi teda vůbec nesedělo. Špatně se kontrolovalo co tam je, stávalo se, že secret někdo něco špatně zašifroval, víc namespace je taky naprd. Celé jsme to zmigrovali na AzureKeyVaultSecret což je obdoba External Secrets a od té doby máme pokoj. Zpětně bych šel asi taky do External Secrets, když to umí víc cloudu.
