Kurum içi CA

Core'un sunduğu sertifika — native TLS ile kendi sonlandırdığı ya da önündeki bir reverse proxy/Ingress'in sunduğu — kurumunuzun kendi CA'sıyla imzalıysa tarayıcılar, CA kurumda zaten dağıtılmış olduğu için güvenir. Ama üç istemci işletim sisteminin kök deposunu kullanmaz ve bu sertifikayı kendi başına doğrulayamaz: agent (cluster'da çalışır), Shell (tarayıcıdan açılan toolbox kabuğu, içindeki kubectl/helm) ve CLI (yeke login/port-forward). Bu üçü için doğrulamayı atlamanın tek yolu -k/--insecure/NODE_TLS_REJECT_UNAUTHORIZED=0 gibi bir bayraktı; bu sayfa onun yerine geçen tek kaynağı anlatıyor.

YEKE_PUBLIC_CA_FILE verilmediği sürece davranış bugünküyle bayt bayt aynıdır: core hiçbir CA dağıtmaz, kurulum manifesti, kabuk önsözü ve kurulum komutu değişmez.

Değer bir dosya yoludur — PEM'in kendisi değil, YEKE_LICENSE_PATH ile aynı desen. Dosya compose'a salt-okunur bağlanır ve core'un çalıştığı kullanıcı (65532) okuyabilmelidir:

    environment:
      YEKE_PUBLIC_CA_FILE: /etc/yeke/public-ca.crt
    volumes:
      - ./yeke-ca.crt:/etc/yeke/public-ca.crt:ro

• PEM biçiminde bir ya da daha çok sertifika — en az biri kendi imzalı (kök) olmalı. Yalnız ara sertifika taşıyan bir dosyayla core açılışta durur: Node.js istemcileri (agent, CLI) bir ara sertifikayı çapa olarak kabul etmez. Öz-imzalı bir sunucu sertifikası kendi köküdür ve dosyaya doğrudan konabilir.
• En çok 16 kök kabul edilir — tünel protokolünün taşıma sınırı. Daha kalabalık bir dosya (tipik olarak işletim sisteminin genel sertifika paketi) da reddedilir.
• Mount eksikse ya da izin uymuyorsa core açılmaz; hata dosya yolunu, ortam değişkeni adını ve beklenen kullanıcıyı (65532) adıyla söyler.

Core bu dosyayı kendisi almaz ve yenilemez — sertifika gibi CA'yı da kurumunuz sağlar. Aynı değişken Kubernetes/HA kurulumunda da geçerlidir; oradaki fark dosyanın ConfigMap ile mount edilmesidir (bu yol ölçülmedi, aşağıya bakın).

• 1 · Komut kutusunun üstünde bir "CA'yı indir" bağlantısı çıkar — GET /api/public-ca, oturum ister (CA sır olduğu için değil, kurulum yapılandırmasını kimliksiz bir uçtan sunmamak için); dosya yeke-ca.crt adıyla iner.
• 2 · Ekrandaki komut piped-ca biçimine geçer — curl manifesti indirirken core'un sertifikasını CA ile doğrular, hiçbir adımda doğrulama atlanmaz:
  curl -fsSL --cacert yeke-ca.crt "<ekranda verilen bilet URL'i>" | kubectl apply -f -

  Komutu çalıştırmadan önce CA dosyasını komutu çalıştıracağınız dizine indirin.
• 3 · piped-insecure artık ekranda YOK. Doğrulanmış bir yol varken doğrulamayı atlayan bir yolu göstermek, güvenlik kararını kullanıcıya "kolay olan"la aldırmak olurdu.

direct biçim (kubectl apply -f <URL>) ekranda kalır: işletim sisteminiz CA'ya zaten güveniyorsa (kurumsal GPO/MDM ile yaygın) çalışır; güvenmiyorsa kubectl x509: certificate signed by unknown authority der — bu durumda piped-cayı kullanın.

Core yeniden başlayıp CA'yı dağıtmaya başladığında, henüz o CA'yı taşımayan her agent'ın envanter satırında agent · core CA'sı eksik çipi çıkar — bu bir sürüm uyarısı değildir, sürümler eşitken de görünebilir. Birden çok cluster etkileniyorsa envanterin üstünde "Agent'ları güncelle (N)" düğmesi belirir.

Düğme tek bir onay kartında üç adımlık bir plan kurar:

• ClusterRole — izinler zaten güncelse bu adım "değişiklik yok" der.
• ConfigMap/yeke-core-ca — core'un CA'sını taşır; yoksa yaratılır, varsa (rotasyonda) içeriği güncellenir.
• Deployment — agent container'ına YEKE_CORE_CA_FILE=/etc/yeke/core-ca/ca.crt ortam değişkeni ve ConfigMap'i salt-okunur bağlayan bir volume ekler.

Uyguladıktan sonra pod yeniden başlar (rollout), tünel bir an düşüp CA'yı güvenilen köklere ekleyerek geri gelir ve çip kendiliğinden kaybolur.

CA'yı Shell'e ayrıca yapılandırmanız gerekmez: core, kabuk oturumunu açarken CA'yı biletle aynı doğrulanmış kanaldan — terminalin önsözünden — kabuğa kendisi iletir ve kabuk onu o oturuma özel kubeconfige yazar. Bu mekanizmayı okuyan betik toolbox imajının v4 sürümüyle geldi: v3 tabanlı bir imaj kabuğu açar ama içindeki kubectl/helm bugünkü gibi x509 hatası verir.

Kalıcı araç ya da air-gap için kendi toolbox imajınızı basıyorsanız FROM nairotech/yeke-toolbox:v4 kullanın. Core'un kendi CA'sı için imaja hiçbir şey eklemeniz gerekmez — CA imaja değil, oturuma yazılır; imaja CA koymak yalnız kabuktan erişilen başka kurum içi uçlar (bir Helm deposu, bir artifact sunucusu) için anlamlıdır.

yeke login https://yeke.ornek.com --ca-file kok-ca.pem

Dosyanın içeriği (yolu değil) ~/.config/yeke/config.jsone yazılır; sonraki komutlar (port-forward dâhil) oradan okur — dosya taşınır ya da silinirse login öncesi hiçbir şey bozulmaz. CA verilmeden yapılan bir login, core'un sertifikası kurum CA'sına imzalıysa bugünkü belirsiz hata yerine sebebini ve çaresini söyler:

Cannot verify the certificate of https://yeke.ornek.com: SELF_SIGNED_CERT_IN_CHAIN.
If YEKE uses a certificate signed by your organization's CA, run: yeke login https://yeke.ornek.com --ca-file <root-ca.pem>

CA her istemcide güvenilen köklere eklenir, yerine geçmez. Bu yüzden CA'yı dağıttıktan sonra core hâlâ eski sertifikayı sunarken bile istemciler bağlanmaya devam eder; sertifikayı CA'dan önce değiştirirseniz agent tüneli düşer, Shell açılmaz ve kurulum komutu x509 hatası verir.

• 1 · Dosyaya eski + yeni kökü birlikte yazıp core'u yeniden başlatın. CA dosyası yalnız açılışta okunur, canlı yeniden yükleme yoktur. Her cluster'ın envanter satırında çip çıkar ve "Agent'ları güncelle (N)" belirir.
• 2 · "Agent'ları güncelle (N)" ile uygulayın. Bu adımda yalnız ConfigMap değişir, Deployment'a dokunulmaz — pod yeniden başlamaz. Kubernetes ConfigMap'i pod'a gecikmeyle indirir (30 saniye ile birkaç dakika arası); sertifikayı ondan sonra değiştirin.
• 3 · Sertifikayı yeni köke alın. Tünel bir an düşüp geri gelir, çip kendiliğinden kaybolur. Sertifikayı erken değiştirirseniz agent kısa süre x509 hatası verir ve dosyayı her bağlanışta yeniden okuduğu için kendiliğinden toparlar.
• 4 · Bütün çipler düştükten sonra eski kökü dosyadan çıkarıp core'u tekrar başlatın. Agent'ların ConfigMap'inde kalan eski kök zararsızdır — süresi dolunca agent onu atlar.

Kamu sertifikasından kurum CA'sına ilk geçiş de aynı sıradır. Sırayı tersine çevirip tüneli düşürdüyseniz kurtarma yolu, agent'ın kurulum manifestini (token rotasyonuyla) yeniden üretip kubectl apply etmektir.

Kısıtlı erişim modundaki cluster'lar için ConfigMap yazma yetkisi varsayılmaz, bu yüzden ne CA-eksik çipi ne de güncelleme düğmesi çıkar — sürüm güncellemesinde de bugün böyledir. Yol burada elle işler: core'a CA verildikten sonra agent token'ını yenileyin; yeniden üretilen kurulum manifesti (ConfigMap + ortam değişkeni + mount hâlâ taşır) cluster'ın yöneticisi tarafından kubectl apply edilir, agent yeni token ve CA ile bağlanır. Sertifika ancak ondan sonra değiştirilir — rotasyonda da aynı yol.

• Hook ve AI sağlayıcı çıkışları bu değişkenle taşınmaz. Core'un kendi sertifikasına güven ile core'un üçüncü taraflara (ITSM, AI sağlayıcı) güveni ayrı konulardır.
• Ölçülmedi: depodaki compose dosyasının kendisi; native TLS ile birlikte kullanım; Kubernetes/HA kurulumunda CA dosyasının ConfigMap ile mount'u; Windows istemciler; işletim sisteminin sertifika deposuna kurulu CA ile direct kurulum biçiminin çalışması.