Vanilla Kubernetes

Kubernetes kontrolna ravan zavisi od više međusobno povezanih trust lanaca. API server dokazuje identitet klijentima, komponente se klijentskim sertifikatima autentikuju prema API serveru, API server koristi poseban klijentski identitet prema etcd-u i kubeletima, etcd članovi koriste uzajamni TLS, a aggregation layer ima sopstveni front-proxy lanac poverenja. Istek jednog leaf sertifikata može prekinuti samo jednu putanju ili učiniti kontrolnu ravan praktično neupotrebljivom; kompromitovan CA privatni ključ može ugroziti identitet čitavog klastera.

Lekcija se oslanja na verifikovani inventar iz lekcije 43 i priprema bezbednu osnovu za kubeadm nadogradnju iz lekcije 45. Ovde cilj nije „produžiti sve što ističe”, već tačno utvrditi ko je vlasnik svakog kredencijala, ko ga potpisuje, gde je privatni ključ, kako se obnova aktivira, kojim dokazom se potvrđuje uspeh i gde se završava mogućnost rollback-a. Posebno se razlikuju kubeadm-managed sertifikati kontrolne ravni, automatska kubelet client rotacija, kubeconfig kredencijali, external CA režim i puna CA rotacija.

PKI kao sistem poverenja, identiteta i rokova

X.509 sertifikat povezuje javni ključ sa identitetom koji je potpisao izdavalac kome druga strana veruje. Sertifikat sadrži period važenja, issuer, subject, proširenja za namenu ključa i, kod serverskih sertifikata, DNS imena i IP adrese u Subject Alternative Name polju. Privatni ključ nije deo sertifikata i nikada se ne dokazuje kopiranjem njegovog sadržaja. TLS provera obuhvata ceo lanac: potpis, važenje, odgovarajuću namenu ključa, hostname/SAN i lokalno pouzdani CA bundle.

Autentikacija i autorizacija nisu isto. Na primer, klijentski sertifikat sa subject organizacijom system:masters može kroz podrazumevani RBAC binding dobiti izuzetno široka prava, dok serverski sertifikat API servera ne daje njegovom posedniku administratorski RBAC identitet. Incident se zato ne klasifikuje samo prema nazivu fajla, već prema privatnom ključu, Extended Key Usage vrednostima, subject-u, CA lancu i mestima na kojima se kredencijal prihvata.

Kubeadm PKI inventar i vlasništvo nad sertifikatima

U standardnom stacked-etcd kubeadm klasteru većina PKI materijala nalazi se pod /etc/kubernetes/pki, a komponentni kubeconfig fajlovi pod /etc/kubernetes. Putanja može biti promenjena kroz certificatesDir ili --cert-dir. Kod external etcd topologije kubeadm ne upravlja etcd CA i pripadajućim sertifikatima. Kod external CA režima lokalni cluster CA privatni ključ nije prisutan, pa kubeadm može proveriti stanje, ali ne može sam potpisati obnovljene sertifikate.

Kubeadm podrazumevano izdaje leaf sertifikate sa rokom od jedne godine i CA sertifikate sa rokom od deset godina. U aktuelnom kubeadm konfiguracionom API-ju kubeadm.k8s.io/v1beta4 mogu se postaviti certificateValidityPeriod i caCertificateValidityPeriod, u Go duration formatu čija je najduža jedinica h. Duži rok smanjuje učestalost obnove, ali povećava period u kome ukradeni kredencijal može važiti; kraći rok traži pouzdanu automatizaciju, monitoring i operativnu disciplinu. Rok nije zamena za opoziv, rotaciju i least privilege.

apiVersion: kubeadm.k8s.io/v1beta4
kind: ClusterConfiguration
certificatesDir: /etc/kubernetes/pki
encryptionAlgorithm: RSA-3072
certificateValidityPeriod: 8760h
caCertificateValidityPeriod: 87600h

Ovaj primer je projektna konfiguracija za buduće generisanje kredencijala, a ne komanda koja retroaktivno menja rok postojećih sertifikata. Podržani algoritmi u ovom API-ju uključuju RSA-2048 kao podrazumevani, RSA-3072, RSA-4096 i ECDSA-P256. Izbor mora biti usklađen sa organizacionim kriptografskim standardom i svim potrošačima.

Provera rokova, lanca, namene i vremenske sinhronizacije

Prva produkciona provera je read-only. Na svakom control-plane nodu administrator sa sudo pravom izvršava lokalnu kubeadm proveru, jer jedan node ne dokazuje stanje fajlova na drugim nodovima. Komanda prikazuje expiry kubeadm-managed sertifikata, preostalo vreme, CA i da li je sertifikat eksterno upravljan. Ne pokriva sve moguće sertifikate klastera, naročito kubelet sertifikate, sertifikate eksternih dodataka i kredencijale koje kubeadm ne poznaje.

sudo kubeadm certs check-expiration
sudo kubeadm certs check-expiration -o json

sudo openssl x509 \
  -in /etc/kubernetes/pki/apiserver.crt \
  -noout -subject -issuer -serial -dates -fingerprint -sha256

sudo openssl x509 \
  -in /etc/kubernetes/pki/apiserver.crt \
  -noout -ext subjectAltName -ext extendedKeyUsage

check-expiration i openssl x509 samo čitaju lokalne fajlove. JSON izlaz je pogodniji za automatizovanu obradu, ali pre primene parsera treba potvrditi šemu za instaliranu verziju kubeadm-a. Ne koristiti openssl rsa -text niti ispisivati kubeconfig sa --raw u tiket: takav izlaz može otkriti privatni ključ. Bezbedan dokaz sadrži metapodatke sertifikata i SHA-256 fingerprint, ne tajni materijal.

# Read-only provera sertifikata koji udaljeni API endpoint zaista servira.
openssl s_client -connect api.k8s.example:6443 \
  -servername api.k8s.example \
  -showcerts </dev/null 2>/dev/null |
openssl x509 -noout -subject -issuer -serial -dates -fingerprint -sha256

# Provera vremena; naziv servisa zavisi od distribucije.
timedatectl status
systemctl status chronyd --no-pager

Lokalni fajl i sertifikat koji endpoint servira mogu se razlikovati ako static Pod još koristi prethodno učitani materijal, ako je load balancer poslao zahtev drugoj instanci ili ako TLS terminira na spoljnom uređaju. Zato se porede serial/fingerprint i proverava svaka control-plane instanca na način koji ne zaobilazi odobreni mrežni model. Greške certificate has expired or is not yet valid mogu nastati i zbog pogrešnog sata; NTP/chrony stanje se proverava pre obnove.

Obnova kubeadm-managed sertifikata i aktiviranje promene

Kubeadm obnavlja control-plane sertifikate tokom dokumentovane nadogradnje kontrolne ravni. Ako se redovno nadograđuje pre godišnjeg isteka, to često održava sertifikate važećim. Ručna obnova je potrebna kada se upgrade ciklus ne poklapa sa rokom, kada monitoring pokaže prag upozorenja ili kada politika zahteva kontrolisanu rotaciju. Komande kubeadm certs renew menjaju stanje i obnavljaju bez obzira na preostali rok; ne predstavljaju read-only „probni” poziv.

Pre promene potvrđuju se zdrav API, etcd quorum i snapshot politika, dovoljan broj dostupnih control-plane instanci, verzija kubeadm-a, stvarni certificatesDir, prisustvo odgovarajućih CA privatnih ključeva, backup konkretnih PKI i kubeconfig fajlova u šifrovanom i strogo kontrolisanom skladištu i rollback postupak. Backup privatnih ključeva nije običan support bundle: mora imati najmanji krug pristupa, evidenciju, rok čuvanja i provereno uništavanje.

# STATE-CHANGING: izvršava se na jednom kubeadm control-plane nodu.
sudo kubeadm certs renew apiserver
sudo kubeadm certs renew apiserver-kubelet-client
sudo kubeadm certs renew apiserver-etcd-client
sudo kubeadm certs renew front-proxy-client

# Šira promena; koristi se samo kada je planom obuhvaćen ceo lokalni skup.
sudo kubeadm certs renew all

Obnova se zasniva na postojećem sertifikatu: dodatni atributi kao SAN preuzimaju se iz njega. Ako je cilj promena API endpoint DNS/IP imena, slepa obnova neće projektovati novu SAN listu; potreban je poseban, testiran postupak regenerisanja sa ispravnom kubeadm konfiguracijom. U replicated control-plane topologiji renew all se izvršava na svim control-plane nodovima, jer PKI fajlovi nisu magično zajednički. Postupak se radi jedan node odjednom, uz validaciju između nodova.

Static Pod procesi ne moraju automatski ponovo učitati zamenjeni fajl. Zvanični kubeadm postupak zahteva restart control-plane Pod-ova; jedan praktičan način je privremeno uklanjanje pojedinačnog manifesta iz /etc/kubernetes/manifests, čekanje da kubelet ukloni Pod, pa vraćanje manifesta i čekanje oporavka. Ovo je rizična state-changing operacija: manifest se ne ostavlja kao backup u istom direktorijumu, jer kubelet skenira sve fajlove bez obzira na ekstenziju.

# LAB/ODOBRENI CHANGE: restart jednog static Pod-a na jednom nodu.
sudo mkdir -p /var/lib/kubernetes-manifest-hold
sudo mv /etc/kubernetes/manifests/kube-apiserver.yaml \
  /var/lib/kubernetes-manifest-hold/kube-apiserver.yaml

# Sačekati najmanje jedan kubelet fileCheckFrequency ciklus i potvrditi uklanjanje.
sudo crictl ps --name kube-apiserver

sudo mv /var/lib/kubernetes-manifest-hold/kube-apiserver.yaml \
  /etc/kubernetes/manifests/kube-apiserver.yaml

# Sačekati ponovno kreiranje i potvrditi health pre prelaska na sledeći node.
sudo crictl ps --name kube-apiserver
kubectl get --raw='/readyz?verbose'

Tačna CRI konfiguracija i vreme čekanja zavise od noda. U HA produkciji se nikada istovremeno ne restartuju svi API serveri ili svi etcd članovi. Ako je obnovljen etcd peer/server sertifikat, procedura mora čuvati quorum i potvrditi endpoint health posle svakog člana. Ako validacija ne uspe, prekida se rad na ostalim nodovima, čuvaju se logovi i vraća tačno definisan prethodni par sertifikat–ključ; nasumično mešanje starog sertifikata i novog ključa neće raditi.

Kubeconfig lifecycle: ugrađeni ključevi, kopije i konteksti

Kubeconfig nije samo lista endpointa. Može sadržati CA podatke, client sertifikat i privatni ključ ugrađene kao base64 polja, reference na fajlove, bearer token ili exec plugin koji pokreće spoljašnji proces. Zato se tretira kao izvršiva i poverljiva konfiguracija. Kubernetes dokumentacija upozorava da zlonamerno napravljen kubeconfig može dovesti do izvršavanja koda ili otkrivanja fajlova; nepoznat fajl se ne otvara komandama kubectl pre pažljivog statičkog pregleda.

Podrazumevani $HOME/.kube/config, eksplicitni --kubeconfig i lista iz KUBECONFIG mogu dati različitu efektivnu konfiguraciju. Kod merge-a prvi fajl koji postavi određeni ključ pobeđuje. Administrator zato pre promene beleži izvor, trenutni context, cluster, user i namespace, a zatim koristi eksplicitni fajl kad je potreban determinističan rezultat.

# Read-only; podrazumevano rediguje osetljive vrednosti.
kubectl config current-context
kubectl config get-contexts
kubectl config view --minify
kubectl config view --flatten

# Bez prikaza privatnog ključa: izdvajanje ugrađenog client sertifikata.
kubectl config view --raw --minify \
  -o jsonpath='{.users[0].user.client-certificate-data}' |
base64 -d |
openssl x509 -noout -subject -issuer -serial -dates -fingerprint -sha256

Poslednja komanda koristi --raw, ali JSONPath izdvaja samo javni sertifikat; mora se pažljivo prekopirati bez zamene polja sa client-key-data. Kubeconfig kopiran iz /etc/kubernetes/admin.conf neće se automatski promeniti kada se original obnovi. Posle kubeadm certs renew admin.conf odobrena kopija se redistribuira bezbednim kanalom ili se, još bolje, za svakodnevni ljudski pristup koriste kratkotrajni individualni identiteti preko OIDC/exec integracije umesto deljenog cluster-admin client ključa.

Fajlovi controller-manager.conf i scheduler.conf pripadaju komponentama i ne distribuiraju se ljudima. admin.conf je veoma privilegovan, a super-admin.conf je break-glass kredencijal koji može zaobići uobičajene RBAC zabrane zahvaljujući system:masters grupi. Njegov pristup, upotreba i svako kopiranje moraju biti strogo kontrolisani i auditovani. Generičko slanje ovih fajlova elektronskom poštom ili čuvanje u Git-u predstavlja incident, ne administrativnu pogodnost.

Kubelet client rotacija, serving sertifikati i CSR tok

Kubelet client kredencijali imaju odvojen lifecycle. Kada je uključena rotateCertificates mogućnost i controller manager ima odgovarajući signer i signing duration, kubelet pre isteka podnosi CSR, dobija novi sertifikat i prebacuje aktivnu referencu u /var/lib/kubelet/pki. Kubeadm tipično konfiguriše ovaj tok. Fajl /etc/kubernetes/kubelet.conf nakon bootstrap faze treba da referencira rotirajući kubelet client cert/key, a ne statički ugrađeni godišnji kredencijal.

kubectl get csr
kubectl get csr -o wide
kubectl describe csr <ime-csr-a>

sudo grep -E 'rotateCertificates|serverTLSBootstrap' \
  /var/lib/kubelet/config.yaml
sudo readlink -f /var/lib/kubelet/pki/kubelet-client-current.pem
sudo openssl x509 \
  -in /var/lib/kubelet/pki/kubelet-client-current.pem \
  -noout -subject -issuer -serial -dates -fingerprint -sha256

CSR se ne odobrava samo zato što ima status Pending. Proveravaju se signerName, username, groups, usages, zahtevani subject/SAN, stvarni node identitet i audit trag. Automatski approval kontroleri imaju ograničenu, dokumentovanu svrhu. Ručno kubectl certificate approve menja stanje i može izdati identitet napadaču ako je zahtev lažan.

Kubelet serving sertifikat je druga putanja. Self-signed serving sertifikat nije dovoljan kada API server ili monitoring klijent treba da potvrdi kubelet identitet kroz pouzdani CA. serverTLSBootstrap: true omogućava CSR zahtev, ali core controller manager ne odobrava automatski serving CSR; potreban je bezbedan eksterni approver ili ručna procedura koja strogo proverava node DNS/IP SAN-ove. Klijentski i serverski CSR ne smeju se mešati.

External CA, offline ključevi i CA rotacija

External CA režim smanjuje prisustvo cluster CA privatnog ključa na control-plane nodovima. Ako je prisutan ca.crt, ali ne i ca.key, a ostali potrebni sertifikati i kubeconfig fajlovi postoje, kubeadm prepoznaje external CA režim. Kubeadm može generisati ključeve i CSR fajlove komandom kubeadm certs generate-csr; zahtevi se zatim potpisuju odobrenim eksternim CA procesom, a potpisani sertifikati vraćaju na propisana mesta.

# LAB/ODOBRENI OFFLINE PKI PROCES: generiše nove privatne ključeve i CSR fajlove.
sudo kubeadm certs generate-csr \
  --kubeconfig-dir /secure-staging/etc-kubernetes \
  --cert-dir /secure-staging/etc-kubernetes/pki \
  --config /secure-staging/kubeadm-config.yaml

Ovo nije bezbedna dijagnostička komanda: stvara privatne ključeve. Staging lokacija mora biti šifrovana, izolovana, sa umask 077, kontrolom pristupa i postupkom sigurnog brisanja. CSR nije tajan kao privatni ključ, ali sadrži identitet i SAN-ove koji otkrivaju topologiju. Potpisnik mora primeniti tačan CA profil, key usage, rok i identitet; „sertifikat se kriptografski verifikuje” nije dovoljno ako je potpisan pogrešan subject ili preširoka namena.

CA rotacija je projekat migracije poverenja, a ne produženje datuma. Bezbedan konceptualni tok je: inventar svih trust bundle-ova i potrošača; generisanje novog CA ključa u odobrenom HSM/offline okruženju; distribucija bundle-a koji privremeno veruje starom i novom CA; izdavanje novih leaf sertifikata; kontrolisan restart i dokaz da svaki potrošač koristi novi lanac; prestanak izdavanja starim CA; uklanjanje starog trust anchor-a tek posle maksimalnog preostalog roka i potvrde da nema starih klijenata. Cluster CA, etcd CA i front-proxy CA imaju različite blast radius-e i ne rotiraju se nekritički istim postupkom.

Zaštita privatnih ključeva, distribucija i incident response

Dozvole 0600 i root vlasništvo su početak, ne kompletna zaštita. Control-plane host mora biti administrativno ograničen; backup šifrovan; tajne isključene iz shell history-ja, terminal snimaka i support bundle-ova; pristup beležen; privatni ključevi nikada u Git-u, image-u ili tiket prilogu. CA privatni ključevi se, gde model dopušta, drže offline ili u HSM/KMS procesu. Kopiranje CA ključeva na svaki control-plane node povećava dostupnost lokalne obnove, ali i blast radius kompromitacije.

Kod sumnje na kompromitaciju cilj nije samo „obnoviti sertifikat”. Obnova sa istim CA ne opoziva automatski ukradeni client sertifikat; Kubernetes X.509 autentikacija nema univerzalni online CRL/OCSP mehanizam koji će sam rešiti incident. Potrebno je utvrditi koji je ključ kompromitovan, obim identiteta i prava, gde je korišćen, da li je potpisnik kompromitovan i koliko dugo stari kredencijal može biti prihvaćen. Za leaf client ključ trajna mera može zahtevati promenu CA poverenja ili specifičnu autentikacionu/RBAC blokadu, dok kompromitovan CA ili ServiceAccount signing key zahteva širu rotaciju i reviziju svih izdatih identiteta/tokena.

Troubleshooting: od TLS simptoma do dokazanog uzroka

Logovi se korelišu u istom UTC prozoru. Za kubeadm static Pod komponente koriste se crictl logs nad tačnim container ID-jem i kubelet journal; za kubelet CSR tok proveravaju se kubelet i controller-manager logovi, CSR objekti i audit log API servera. Pre restartovanja beleže se trenutni container ID, start time, serial/fingerprint, poslednji change i health stanje.

sudo journalctl -u kubelet \
  --since '2026-07-20 09:00:00 UTC' \
  --until '2026-07-20 09:30:00 UTC' --no-pager

sudo crictl ps -a --name kube-apiserver
sudo crictl logs <container-id> 2>&1 |
  grep -Ei 'x509|certificate|tls|unauthorized|forbidden'

kubectl get events -A --sort-by=.metadata.creationTimestamp
kubectl auth whoami
kubectl auth can-i --list

Simptom je poruka klijenta ili nedostupna komponenta; obim je skup endpointa, nodova i identiteta koji ne rade; neposredni uzrok može biti istek konkretnog leaf sertifikata; osnovni uzrok je često odsustvo expiry monitoringa, nepotpuna HA procedura ili nekontrolisana kopija kubeconfig-a. Privremeni workaround ne sme biti trajno isključivanje TLS provere. Trajna mera obuhvata obnovu, aktivaciju, dokaz health-a, uklanjanje zastarele kopije, alarm i ispravku runbook-a.

Integrisani praktikum: kontrolisana PKI provera i laboratorijska obnova

Kontekst i cilj. Tim priprema tročlani kubeadm control plane za nadogradnju. Administrator treba da izradi redigovan PKI inventar, pronađe sertifikate unutar alarmnog praga, proveri kubeconfig i kubelet rotaciju, zatim u laboratoriji obnovi jedan API server sertifikat, aktivira ga i dokaže oporavak. Produkcioni deo praktikuma završava se pre state-changing vežbe; obnova se prenosi u produkciju samo kroz odobren change.

Topologija, prava i rizik. Laboratorija ima najmanje jedan kubeadm control-plane node i jedan worker; poželjna HA kopija omogućava vežbanje node-po-node postupka. Potrebni su sudo, kubeadm, kubectl, openssl i crictl. Inventarski izlaz ne sme sadržati privatne ključeve ni raw kubeconfig. Obnova može prekinuti API; snapshot/backup i konzolni pristup moraju biti potvrđeni pre vežbe.

Vežba 1: redigovani PKI snapshot

umask 077
PKI_AUDIT_DIR="${PWD}/k8s-pki-audit-$(date -u +%Y%m%dT%H%M%SZ)"
mkdir -p "${PKI_AUDIT_DIR}"

date -u +'%Y-%m-%dT%H:%M:%SZ' \
  > "${PKI_AUDIT_DIR}/collected-at-utc.txt"
kubectl config current-context \
  > "${PKI_AUDIT_DIR}/context.txt"
sudo kubeadm certs check-expiration -o json \
  > "${PKI_AUDIT_DIR}/kubeadm-expiration.json"

sudo openssl x509 -in /etc/kubernetes/pki/apiserver.crt \
  -noout -subject -issuer -serial -dates -fingerprint -sha256 \
  > "${PKI_AUDIT_DIR}/apiserver-certificate-metadata.txt"

find "${PKI_AUDIT_DIR}" -maxdepth 1 -type f \
  -printf '%M %u:%g %s %f\n' | sort

Očekivani rezultat i validacija. Fajlovi nisu world-readable; kontekst odgovara laboratoriji; kubeadm izlaz ima stavke za lokalno upravljane sertifikate, a metadata fajl nema PEM privatni ključ. Ista provera se u HA laboratoriji ponavlja na svakom control-plane nodu i porede se serial, expiry i externally managed status. Razlika se prvo objašnjava topologijom i poslednjim change-om, ne automatski „popravlja”.

Vežba 2: provera kubeconfig-a i kubelet rotacije

kubectl config view --minify \
  > "${PKI_AUDIT_DIR}/effective-kubeconfig-redacted.yaml"

kubectl config view --raw --minify \
  -o jsonpath='{.users[0].user.client-certificate-data}' |
base64 -d |
openssl x509 -noout -subject -issuer -serial -dates -fingerprint -sha256 \
  > "${PKI_AUDIT_DIR}/client-certificate-metadata.txt"

kubectl get csr -o wide \
  > "${PKI_AUDIT_DIR}/csr-wide.txt"

sudo readlink -f /var/lib/kubelet/pki/kubelet-client-current.pem
sudo openssl x509 \
  -in /var/lib/kubelet/pki/kubelet-client-current.pem \
  -noout -subject -issuer -serial -dates -fingerprint -sha256

Kriterijum. Administrator ume da objasni da li kubeconfig koristi ugrađeni cert/key, reference ili exec plugin; potvrđuje rok bez čuvanja privatnog ključa u audit paketu; utvrđuje da kubelet koristi rotirajući client sertifikat i klasifikuje sve Pending/Denied/Failed CSR objekte. Ako base64 tok ne daje sertifikat, ne pretpostavlja se kvar: kubeconfig možda koristi drugi mehanizam autentikacije.

Vežba 3: laboratorijska obnova API server sertifikata

Pre promene se beleže stari serial i fingerprint, proveravaju /readyz i etcd health prema postojećem laboratorijskom runbook-u i pravi zaštićena kopija tačno određenog para apiserver.crt/key. Kopija se ne ostavlja u static Pod manifest direktorijumu. Sledeće komande menjaju PKI i procesno stanje i ne izvršavaju se u produkciji bez change odobrenja.

# LAB ONLY – STATE-CHANGING
sudo install -d -m 0700 /var/lib/kubernetes-pki-rollback
sudo cp -a /etc/kubernetes/pki/apiserver.crt \
  /etc/kubernetes/pki/apiserver.key \
  /var/lib/kubernetes-pki-rollback/

sudo kubeadm certs renew apiserver

sudo openssl x509 -in /etc/kubernetes/pki/apiserver.crt \
  -noout -serial -dates -fingerprint -sha256

sudo install -d -m 0700 /var/lib/kubernetes-manifest-hold
sudo mv /etc/kubernetes/manifests/kube-apiserver.yaml \
  /var/lib/kubernetes-manifest-hold/
sudo crictl ps --name kube-apiserver

sudo mv /var/lib/kubernetes-manifest-hold/kube-apiserver.yaml \
  /etc/kubernetes/manifests/
sudo crictl ps --name kube-apiserver
kubectl get --raw='/readyz?verbose'

Očekivani rezultat. Novi serial/fingerprint razlikuje se od starog, notAfter je produžen prema politici, SAN ostaje odgovarajući, novi API server container je pokrenut i readyz prolazi. U HA scenariju udaljena TLS provera potvrđuje svaki backend, a sledeći node se menja tek kada je prethodni potpuno zdrav.

Troubleshooting grana. Ako static Pod ne startuje, ne prelazi se na sledeći node. Proveravaju se kubelet journal i crictl ps -a/logs, podudaranje cert-key para, dozvole, CA potpis, SAN i manifest putanje. Ako je uzrok novi materijal, vraćaju se oba prethodna fajla iz rollback kopije, ponavlja kontrolisani restart i potvrđuje stari fingerprint i health. Ako je CA ključ external ili nedostupan, ne generiše se improvizovani CA.

Vežba 4: simulacija incidenta bez izlaganja ključa

Umesto namernog isteka ili krađe stvarnog ključa, tim dobija hipotetički nalaz: kopija admin.conf završila je u internom Git repozitorijumu. Utvrđuju se vreme prvog commit-a, dostupnost repozitorijuma, subject/groups i RBAC moć sertifikata, audit zahtevi tog identiteta i sve kopije. Privremena mera je ograničavanje pristupa i čuvanje forenzičkih dokaza; samo brisanje commita nije dovoljno jer istorija i klonovi ostaju.

Trajna mera zavisi od rizika: izdavanje novog admin kredencijala i uklanjanje deljenih kopija ne čini nužno ukradeni X.509 sertifikat nevažećim. Tim procenjuje potrebu za promenom trust lanca ili drugim kompenzacionim kontrolama, rotira sve druge tajne pronađene u istom incidentu, pregledava audit trag, uvodi individualni IdP pristup i secret scanning. Kriterijum završetka je dokumentovan obim, containment, recovery, validacija i vlasnik preventivne mere.

Vežba 5: završna validacija, checksum i čišćenje

sudo kubeadm certs check-expiration
kubectl get nodes
kubectl get --raw='/livez?verbose'
kubectl get --raw='/readyz?verbose'

find "${PKI_AUDIT_DIR}" -maxdepth 1 -type f ! -name SHA256SUMS \
  -printf '%f\n' | sort | while IFS= read -r file; do
    sha256sum "${PKI_AUDIT_DIR}/${file}"
  done > "${PKI_AUDIT_DIR}/SHA256SUMS"

(cd "${PKI_AUDIT_DIR}" && sha256sum --check SHA256SUMS)

Kriterijum završetka i rollback laboratorije. API, nodovi i komponente su zdravi; endpoint servira očekivani novi sertifikat; audit paket sadrži samo redigovane metapodatke i checksum. Privremena rollback kopija sa privatnim ključem ne ulazi u audit paket: po isteku change/rollback prozora bezbedno se uklanja prema laboratorijskoj politici. Ako se laboratorija vraća na stari cert-key par radi ponavljanja vežbe, vraćaju se oba fajla i API server se ponovo kontrolisano restartuje i validira.

Administratorske prakse

• ☐ Za cluster, etcd i front-proxy CA poznati su vlasnik, lokacija privatnog ključa, rok, potrošači i recovery postupak.
• ☐ ServiceAccount signing key pair nije pogrešno tretiran kao X.509 sertifikat sa istim lifecycle-om.
• ☐ kubeadm certs check-expiration izvršen je na svakom control-plane nodu i dopunjen proverom kredencijala koje kubeadm ne upravlja.
• ☐ Alarm prati notAfter dovoljno rano za change, external CA potpisivanje, test i rollback.
• ☐ Lokalni cert fingerprint upoređen je sa sertifikatom koji endpoint stvarno servira.
• ☐ Vreme i NTP stanje provereni su pre zaključka da je sertifikat istekao ili još nije važeći.
• ☐ Obnova leaf sertifikata jasno je odvojena od CA rotacije i promene SAN liste.
• ☐ U HA klasteru obnova i restart rade se jedan control-plane/etcd član odjednom, uz health dokaz između koraka.
• ☐ Posle obnove obnovljeni su samo potrebni kubeconfig fajlovi i kontrolisano zamenjene njihove odobrene kopije.
• ☐ admin.conf nije svakodnevni deljeni identitet, a super-admin.conf je break-glass kredencijal sa posebnim nadzorom.
• ☐ Kubelet client rotacija i serving CSR approval proveravaju se kao različiti tokovi.
• ☐ CSR se ne odobrava bez potvrde signer-a, usages, username/groups, subject/SAN i stvarnog podnosioca.
• ☐ Privatni ključevi nisu u Git-u, image-u, inventaru, shell history-ju, tiketima, chat-u ni nezaštićenom backup-u.
• ☐ Backup cert-key para je šifrovan, pristup auditovan, restore testiran i retention ograničen.
• ☐ Incident plan priznaje da obična obnova ne opoziva automatski ukradeni X.509 client sertifikat.
• ☐ Posle svake promene provereni su serial/fingerprint, SAN/EKU, endpoint TLS, component health, logovi i audit trag.

Završna kontrolna tačka

Lekcija je savladana kada administrator ume da nacrta odvojene cluster, etcd i front-proxy trust lance, objasni ulogu ServiceAccount signing ključa i klasifikuje svaki control-plane, kubelet i kubeconfig kredencijal prema vlasniku, potpisniku, nameni, lokaciji i načinu obnove. Mora umeti da proveri rok, issuer, subject, SAN, EKU, serial i fingerprint bez izlaganja privatnog ključa i da razlikuje lokalni fajl od sertifikata koji endpoint stvarno servira.

Praktični kriterijum je dokaziv PKI change paket: redigovani inventar sa svih control-plane nodova, alarmni pragovi, health i backup preduslovi, node-po-node plan, obnova i aktivacija, validacija endpointa i komponenti, rollback tačnog cert-key para i postupak čišćenja. Administrator ume da dijagnostikuje expiry, clock skew, unknown authority, SAN mismatch, RBAC grešku i Pending CSR; external CA i CA rotation eskalira u odgovarajući PKI proces umesto improvizovanja lokalnog potpisa.

Zaključak

Kubernetes PKI nije fascikla sertifikata, već živa mreža poverenja između API servera, etcd-a, kubeleta, kontrolera, agregiranih API-ja i administratora. Rok je samo jedna dimenzija. Jednako su važni pravi issuer, namena, SAN, zaštita ključa, mesto distribucije, proces ponovnog učitavanja i dokaz da je svaka instanca zaista prešla na novi materijal.

Kubeadm pojednostavljuje generisanje, proveru i obnovu control-plane sertifikata, ali ne ukida administratorsku odgovornost. Kubelet rotacija ima sopstveni CSR lifecycle; kubeconfig može sadržati privatni ključ ili izvršavati credential plugin; external CA zahteva kontrolisano potpisivanje; CA rotacija zahteva migraciju poverenja. Posebno opasna zabluda je da izdavanje novog client sertifikata automatski opoziva ukradeni stari kredencijal.

Zreo administrator zato radi od najmanje invazivne provere ka promeni, obnavlja samo poznati skup, aktivira ga kontrolisano, validira health i fingerprint, štiti rollback kopiju i dokumentuje sve udaljene kubeconfig kopije. Tako PKI prestaje da bude skriveni godišnji incident i postaje upravljan lifecycle proces – neophodan preduslov za kontrolisanu kubeadm nadogradnju u sledećoj lekciji i pouzdan oporavak kontrolne ravni koji sledi.