Generator Kubernetes Secret

Generator Kubernetes Secret

Secret przechowuje dane wrażliwe: hasła do baz, klucze API, certyfikaty. W odróżnieniu od ConfigMap wartości są kodowane base64 i mogą być dodatkowo szyfrowane w spoczynku.

Secret czy ConfigMap?

stringData czy data?

Pole data wymaga wartości zakodowanych base64. Pole stringData przyjmuje tekst jawny i samodzielnie go koduje — generator korzysta z niego dla wygody.

Jak używać?

1. Zapisz plik jako secret.yaml.
2. Zastosuj: kubectl apply -f secret.yaml.
3. W Deployment odwołaj się przez envFrom.secretRef lub valueFrom.secretKeyRef.

Jak działa generator manifestu Secret

Narzędzie przyjmuje nazwę obiektu, namespace, typ oraz pary klucz-wartość. Na tej podstawie buduje manifest YAML zgodny z API v1. Zamiast ręcznie kodować każdą wartość do base64, generator umieszcza ją w polu stringData. Kubernetes przy zapisie obiektu sam konwertuje stringData do data i wykonuje kodowanie base64.

Mechanizm base64 polega na podziale danych na grupy po 3 bajty, czyli 24 bity. Każda taka grupa jest zamieniana na 4 znaki z alfabetu 64 znaków. Dlatego 3 bajty dają 4 znaki, a rozmiar rośnie o jedną trzecią w stosunku do wejścia. Gdy długość danych nie jest wielokrotnością 3, ostatnia grupa jest dopełniana jednym lub dwoma znakami równości.

Typ Secret wpływa na wymagane klucze. Dla type: Opaque nie ma narzuconych nazw. Dla kubernetes.io/tls wymagane są klucze tls.crt i tls.key, a dla kubernetes.io/dockerconfigjson klucz .dockerconfigjson. Generator nie waliduje tych wymagań — ich poprawność sprawdzasz sam przed zastosowaniem manifestu.

Przykład: od hasła do gotowego manifestu

1. Wpisz nazwę Secret: baza-dane. Ustaw namespace: default i typ: Opaque.
2. Dodaj pierwszy klucz: DB_PASSWORD. Wartość to tajne123456, czyli 12 znaków ASCII, a więc 12 bajtów.
3. Dodaj drugi klucz: API_KEY. Wartość to kluczapi123456789012, czyli 20 znaków ASCII, a więc 20 bajtów.
4. Generator zapisuje oba wpisy w polu stringData, więc w YAML widnieje tekst jawny. Po stronie klastra Kubernetes zamieni je na pole data.
5. Dla 12 bajtów base64 daje 16 znaków, bo 12 dzielone przez 3 daje 4 pełne grupy po 4 znaki. Dla 20 bajtów powstaje 28 znaków: 6 pełnych trójek, czyli 18 bajtów, daje 24 znaki, a pozostałe 2 bajty dają 4 znaki z jednym znakiem równości na końcu.
6. W Deployment odwołujesz się przez envFrom.secretRef z nazwą baza-dane albo przez valueFrom.secretKeyRef dla pojedynczego klucza.

Ile znaków base64 dla danej długości wejścia

Praktyczne wskazówki

• Używaj stringData tam, gdzie to możliwe — unikasz ręcznego kodowania i błędów przy kopiowaniu base64. Pole data zostaw, gdy wartość już masz zakodowaną.
• Nie commituj manifestu z prawdziwymi sekretami — plik z stringData zawiera tekst jawny. Trzymaj go poza repozytorium albo stosuj Sealed Secrets lub External Secrets.
• Dobierz type do przeznaczenia — dla TLS użyj kubernetes.io/tls, dla rejestru Docker kubernetes.io/dockerconfigjson. Wtedy inne narzędzia rozpoznają strukturę kluczy.
• Nazwy kluczy bez spacji i znaków specjalnych — klucz w Secret musi pasować do wzorca nazwy, więc używaj liter, cyfr, myślnika, podkreślenia i kropki.
• Pamiętaj o namespace — Secret działa tylko w swojej przestrzeni nazw. Pod w innym namespace nie odczyta go bez dodatkowej konfiguracji.

Czego narzędzie nie robi

• Nie szyfruje wartości — base64 to kodowanie, nie szyfrowanie. O szyfrowaniu w etcd decyduje konfiguracja klastra, a nie generator manifestu.
• Nie generuje ani nie sprawdza haseł — wklejasz własną wartość. Narzędzie nie ocenia jej siły ani nie wykrywa znaków spoza ASCII, które zmieniają długość w bajtach.
• Nie waliduje typu względem kluczy — możesz wybrać kubernetes.io/tls i nie dodać tls.crt. Manifest powstanie, ale Kubernetes odrzuci obiekt przy apply.
• Nie zarządza rotacją ani dostępem — nie ustawia RBAC, nie pilnuje terminu ważności certyfikatów i nie aktualizuje działających podów po zmianie wartości.

Najczęstsze pytania