Kubernetes
Kopiér link til siden “Kubernetes”
Fornyer Kubernetes TLS Secrets og JKS/PKCS12-stores og kontrollerer certifikatet, som Ingress eller applikationen serverer.
Sådan forløber det
- Appliancen forbinder til Kubernetes gennem Kubernetes HTTPS API på port 6443.
- Finder eksisterende certifikater, keystore-identiteter og Ingress-forbrugere. Secrets, som cert-manager eller en anden controller ejer, ændres ikke.
- Validerer certifikat, nøgle og kæde og opdaterer kun den valgte TLS-identitet eller keystore-alias i en eksisterende, mutabel Secret. Andre data, aliases og metadata bevares.
- Den eksisterende Ingress-controller eller applikation indlæser ændringen via sin reload-mekanisme. Agenten kontrollerer det serverede leaf-certifikat og hele den mellemliggende kæde mod betroede rødder. Hvis det fejler: Ved fejl gendannes de forrige målrettede data, hvis de stadig svarer til agentens ændring, og det forrige serverede certifikat kontrolleres. Samtidige ændringer af målrettede data overskrives ikke.
Tekniske detaljer
- Forbindelse
- Pakken kører på appliancen, som forbinder over HTTPS til Kubernetes HTTPS API, port 6443. Der installeres ingen agent.
- I skal bruge
- ServiceAccount-token med get/patch på den udpegede Secret, læseadgang til relevante Ingress-ressourcer og API-discovery. Namespace-inventar kræver list; cert-manager kræver list af Certificates i samme namespace. En Role med resourceNames kan begrænse Secret-adgang til ét navn.
- Handlinger
- Discovery, Installation, Kontrol, Rollback
- Pakker
-
kubernetes-api1.0.0 - Bemærk
-
- Angiv API_URL med clusterets HTTPS-port (normalt 6443 eller 443 via proxy), NAMESPACE og SECRET_NAME. INGRESS_NAME kan begrænse læsning til én Ingress. Agenten vælger den API-version, clusteret annoncerer; TLS-bindinger ændres ikke, og immutable Secrets slettes eller genskabes ikke.
- API-TLS verificeres som standard; privat CA, MANAGEMENT_TLS_PIN_SHA256 eller eksplicit ignore kan vælges. Det serverede certifikat bruger separat VERIFY_CA_BUNDLE eller systemets rødder. Ved fornyelse af selve API-certifikatet bruges CA-tillid til automatisk fornyelse; et leaf-pin skal holdes ajour.
- En enkelt konkret Ingress-vært kan vælges automatisk til kontrol. Ellers angives VERIFY_HOST, eventuelt VERIFY_PORT og VERIFY_SERVER_NAME til SNI. Wildcard-bindinger kræver en konkret vært. Kontrol venter normalt op til 180 sekunder; VERIFY_TIMEOUT kan være 1–420 sekunder.
- JKS/PKCS12 kræver Java keytool med password-file-understøttelse og OpenSSL på appliancen. Angiv SECRET_DATA_KEY, store-password og ved flere identiteter KEYSTORE_ALIAS. Password kan læses fra en anden data-entry i samme Secret. Eksisterende passwords bevares; tegn skal understøttes af Java-provider. Java 17 SunJCE bruger printable ASCII til PKCS12-passwords. Ældre og moderne PKCS12-beskyttelse vælges fra den fundne store.
- Eksplicit rollback kræver det forrige certifikat og nøgle eller den forrige keystore samt en kontrol af den aktuelle certifikatidentitet. Historik-storen kan indeholde kun den valgte identitet; dens base64-input kan rumme 768 KiB decoded. Agenten genstarter ikke workloads; Ingress-controlleren eller applikationen skal allerede kunne indlæse ændrede Secrets.