Ana içeriğe geç

Lisans durumları

DT Edge Platform license-gated gelir. API hangi lisansın yüklendiğine dayalı dört olası duruma sahiptir; operasyonel her şey bu dörtten akar.

Dört durum​

StatusAnlamıAPI davranışı
activeİmzalı, tarihte, fingerprint cluster'la eşleşiyorNormal hizmet eder
graceexp'in ötesinde ama grace_days içindeOkumalar geçer; mutasyonlar 503 ile X-License-Status: grace
missingDB'de lisans satırı yokTüm mutasyonlar 503; sadece bootstrap whitelist hizmet eder
invalidDoğrulama başarısız (signature, fingerprint, schema, clock rollback, grace ötesi expired)Mutasyonlar 503; UI specific reason'ı yüzeyler

Neden bu kadar az​

State machine bilinçli olarak dar. Çalışan "signature wrong" vs "fingerprint wrong" durumu yok çünkü operasyonel cevap aynıdır: operator düzeltene dek hizmet etmeyi reddet. Specific reason support akışı için invalid_reason'da yüzeylenir.

"Bootstrap whitelist" neyi geçirir​

Yeni kurulumda lisans yüklü değildir. Operator bir tane yükleyebilmeli. Yani küçük bir API path seti gate'i bypass eder:

  • /api/capabilities — UI'nın License Required landing page'i render etmesi için
  • /api/auth/login + /api/auth/login/2fa — admin login akışı
  • /api/auth/registration-status — register sayfasının ne göstereceğine karar vermesi için
  • /api/admin/license/... — upload + fingerprint endpoint'leri (hâlâ super-admin'e gated)
  • /healthz, /readyz — health prob'lar (/api'nin dışında yaşar, doğal olarak hariç)

Diğer her path lisans yüklenene kadar 503 döner. Bu super-admin olmayan kullanıcılar için login'i de içerir — authenticate olabilirler ama feature yüzeye ulaşamazlar.

Pratikte grace​

Grace exp ile exp + grace_days (lisansın grace days field'ı, genelde 14 ya da 30) arasındaki window'dur.

Grace'te:

  • Okumalar geçer. Dashboard, list, audit log — hepsi çalışır.
  • Mutasyonlar geçmez. Install / upgrade / uninstall, alarm create/edit, edge instance değişiklikleri — hepsi X-License-Status: grace ile 503'lür.

UI'nın üstündeki sarı banner "License expires in N days; renew before grace ends." der. Niyet kimsenin sürpriz olmaması — ışıklar açık ama bir şey değiştiremezsiniz.

En iyi pratik: grace başlamadan önce yenile. Admin → License'taki audit log her customer'ın expires_at'ini taşır; herhangi bir takvim-veya-monitoring aracı üstüne "60 günde yenilenecek" alarmı kurabilir.

Cluster fingerprint neden​

Her lisans belirli bir cluster fingerprint'e bound:

fingerprint = sha256( kube_system_uid ‖ "\0" ‖ installation_id )
  • kube_system_uid — kube-system namespace'inin UID'si; cluster'ın yaşamı için stabildir
  • installation_id — DT Edge Platform'un DB'sinde ilk boot'ta saklanan UUID

Lisans bu fingerprint'i Binding.ClusterFingerprint'te taşır. Her load'da ve periyodik recheck'te verifier local fingerprint'i yeniden hesaplar ve farklıysa lisansı reddeder.

Bu demek ki: cluster A için issued bir lisans cluster B'yi çalıştıramaz. Ve cluster A wipe edilip yeniden oluşturulursa (kube-system UID değişir) ya da DT Edge Platform'un DB'si reset edilirse (installation_id yeniden üretilir), lisans doğrulanmayı durdurur — yeni fingerprint'e bound bir tanesini gerektirir.

DT Edge Platform ve Provisioner aynı cluster üzerinde çalışıyorsa iki farklı fingerprint vardır çünkü farklı installation_id'leri vardır. Her ürünün kendi fingerprint'ine bound kendi lisansı gerekir.

Schema versioning​

const SchemaVersion = 1

Verifier bu build'in desteklediğinden daha yüksek schema iddia eden herhangi bir lisansı reddeder. Bilinçli asimetri — eski bir DT Edge Platform image'ında çalışan binary, binary'nin sahip olmadığı davranış için mint edilmiş bir lisansı yorumlayamaz. Yeni verifier'lar her zaman eski lisansları kabul eder; eski verifier'lar yenileri reddeder.

Yani: önce DT Edge Platform image'ını yükselt, sonra schema-bumped lisansı yükle. Ters sıra image yükselene dek fail eder.

Bunlar olmayan şeyler​

  • Online revocation. CRL yok, phone-home yok. Bir customer için kill switch expiry'i bekleyip yenilememek YA DA embed edilmiş public signing key'i rotate etmek (eski key tarafından imzalanan her lisansı lockstep'te emekli eder).
  • Per-feature gate'ler. Bugün gate signature + product + expiry + fingerprint, sonra kapasite için Limits. Hiçbir Features.X = true/false mekanizması yok.
  • Time integrity. Host clock'a güveniyoruz. Root'a sahip bir customer date'i geriye set ederse expired bir lisansı canlı tutabilir. Monotonic anchor bariz durumu yakalar — clock monotonic uptime'dan daha geriye — ama belirli bir on-host saldırgana karşı savunma değil.

Multi-replica HA​

Her API replica'sı bir Redis pub/sub kanalına subscribe olur (dtedge:license:reloaded). Herhangi bir replica yeni bir lisans yazdığı an (admin upload) her replica cached snapshot'ını düşürür ve yeniden okur. "Eski lisans hâlâ replica 7'de cache'li" yarışı asla olmaz.

Worker ve scheduler boot'ta aynısını yapar, artı şunları yakalamak için 60 saniyelik periyodik recheck:

  • Runtime sırasında wall'ı geçen expiry (active → grace → invalid past grace)
  • Clock rollback denemeleri
  • psql üzerinden uygulanan DB-side lisans satırı düzenlemeleri (örn: operator force re-bootstrap için satırı siler)

Ayrıca bakın​