Güvenlik Mimarisi ve Tehdit Modeli

YEKE tek bir çizgi boyunca ayrılmıştır; o çizgi ilk gün yazıldı ve o günden beri yerinden oynamadı: cluster'ınızın içinde koşan her satır kod açıktır; merkez kapalıdır. Agent Apache-2.0 lisanslı ve github.com/nairotech/yeke-agent adresinde; tünel protokolü de kendi Apache-2.0 paketinde, @nairotech/yeke-tunnel (bu gözden geçirme sırasında 4.1.0; major numarası tel sürümünün kendisidir). Core, arayüz ve AI katmanı kapalıdır ve bunun değişeceğine dair genel bir söz verilmiyor — geri çekilebilecek bir söz, hiç verilmemiş bir sözden kötüdür.

Bu sayfa kontrollerin nerede uygulandığını, hangi tehditleri ele aldığını ve nasıl doğrulanabileceğini anlatır. Kapalı kaynak bileşenlerin dosya yapısı, veritabanı şeması ve lisans veri yapısı kapsam dışındadır.

Doğrulama. Her bölüm tehdidi, kontrolü ve doğrulama adımlarını açıklar. Bağımsız doğrulama mümkün değilse belirtilir. Açık kaynak bileşenleri hesap veya lisans olmadan indirebilirsiniz.

Aşağıdaki dört sınır farklı kontrollerle korunur.

  Tarayıcı                   Core  (kapalı)                    Sizin cluster'ınız
  ────────                   ──────────────                    ──────────────────
  oturum çerezi    ──[1]──►  varsayılan-reddet       ──[2a]──►  agent (açık)   ──►  apiserver
  HttpOnly, CSRF             kimlik çözümü                      yalnız dışa açar
                             yazma zinciri                      yol beyaz listesi
                                                     ──[2b]──►  doğrudan kubeconfig ──►  apiserver
                                     │      │                   (credential core'da)
                                  [3]│      │[4]
                                     ▼      ▼
                             AI sağlayıcı   SIEM hedefi
                             opt-in,        TLS syslog ya da
                             cluster başına imzalı webhook

Bağımsız doğrulama. 1. ve 2. sınırlar ürünün dışından gözlenebilir: core'u yalnız beklediğiniz şeye izin veren bir NetworkPolicy'nin arkasında koşturun ve gerçekte neye bağlanmaya çalıştığını izleyin. 3. sınırın sert bir kapatma anahtarı var ve kapattığınızı kendi güvenlik duvarınızda görebilirsiniz; 4. sınır kendi toplayıcınızda doğrulanabilir (§8).

Bağımsız doğrulama. Aradaki fark bir dipnot değil, makine-okunur bir alan: cluster envanteri credentialCustody: "cluster" | "core" değerini taşır ve arayüz bunu tam import'u onayladığınız anda gösterir. Agent modunda, uygulamadan önce üretilen kurulum manifestini okuyun — içindeki ClusterRole tavanın tamamıdır.

Diskte. Parolalar scrypt ile, 128 MiB'lık bir bellek maliyetiyle özetlenir — GPU'lu bir saldırganın paralellik avantajını kesen şey budur — kayıt başına bir tuzla ve maliyet parametreleri kaydın içinde saklanarak; böylece parametreler sonradan yükseltilebilir ve eski kayıtlar başarılı bir girişte yeniden özetlenir. Parola politikası NIST 800-63B çizgisindedir: en az 12 karakter, kompozisyon kuralı yok.

Oturumlar. Her opaque session token 256 bit rastgele veri içerir. Core, token’ın tuzsuz SHA-256 hash’ini benzersiz bir indeksle saklar. Oturum iptali sunucudaki kayıttan yönetilir; JWT veya imzalı stateless cookie kullanılmaz.

Cookie yalnız host’a bağlıdır; HttpOnly ve SameSite=Lax kullanır. Secure isteğin şemasına göre belirlenir ve bir ayarla kapatılamaz. CSRF koruması double-submit cookie ve Origin kontrolünü birlikte kullanır.

Oturum 12 saat kullanılmazsa veya toplam 7 gün geçerse sona erer. Refresh token veya kimlik doğrulama cache’i olmadığından iptal bir sonraki istekte geçerlidir. Route’lar varsayılan olarak erişimi reddeder.

Tavan. YEKE kim sorusuna cevap verir; neye yetkili sorusuna Kubernetes. Bir kullanıcı cluster'a, cluster kuralından ya da kişisel bir bağlamadan çözülen bir kimlikle çıkar ve o bağlama kaydedildiği anda apiserver'a sorulur. Eşleme yoksa istek core'dan hiç çıkmaz — bu bir ayar değil, tip sisteminde zorlanan bir kural — ve system:masters birbirinden bağımsız iki kapı tarafından reddedilir; açan bir bayrak yoktur. Tavanın kendisi sizin cluster'ınızda durur: üretilen manifest impersonate yetkisini resourceNames ile sınırlar, ve liste boş bırakılırsa manifest fail-closed üretilir — agent hiçbir kimliğe bürünemez ve bürünülen her istek reddedilir, yani yanlış yapılandırma sessizce yetki vermek yerine ilk denemede kendini gösterir.

Çoklu oturum açma ve ikinci faktör. LDAP / Active Directory girişi 0.13.0'da, OIDC 0.14.0'da geldi; ikisi de tek bir Enterprise kaleminin arkasında ve aynı anda etkin olabilir. OIDC akışı, gizli (confidential) bir istemci üzerinde PKCE'li (S256) Authorization Code'dur; redirect_uri yapılandırılmış genel adresten türer ve asla istek başlığından okunmaz, refresh token istenmez ve saklanmaz. Giriş ekranındaki yerel parola formu hiç kaybolmaz, çünkü yerel hesaplar acil erişim yoludur. Tek kullanımlık kurtarma kodlarıyla TOTP var, ve opt-in'dir (§11).

Bağımsız doğrulama. Bize değil cluster'a sorun: kimlik ekranı, yapılandırmanın iddia ettiği adı değil apiserver'ın döndürdüğü adı gösterir. Sonra tavanı ölçün — dar bağlanmış bir kullanıcıyla girip onun namespace'i dışında bir yazma denemesi yapın. Beklenen sonuç apiserver'ın reddi ve o red apiserver'ın kendi denetim günlüğünde görünür.

Apiserver'ınıza bir yazmanın ulaşmasının tam olarak tek bir yolu var ve o yol bir durum makinesidir:

plan  ─►  önceki hâli yakala  ─►  sınıflandır  ─►  guardrail  ─►  dry-run
                                                                     │
                                          onay (planHash) ◄──────────┘
                                                │
                                            uygula  ─►  geri alma (yeni bir plan,
                                                          aynı boru hattı)

• Hiçbir adım isteğe bağlı değil, ve onay hiçbir koşulda isteğe bağlı değil. Dry-run yalnız apiserver onu imkânsız kıldığı yerde atlanır; o durumda adım bayraklanır ve ürünle gelen bir politika onayı yükseltilmiş seviyeye çıkarır. Koleksiyon silme, siz görmeden önce tek tek adlandırılmış adımlara açılır — her adım kendi nesne kimliği ve sürüm ön koşuluyla.
• planHash, size gösterilen kararın SHA-256'sıdır: hedef nesne sürümleri, neyin değişeceği, hangi şiddette onay istendiği. Bunlardan biri değişirse hash değişir ve önceki onay reddedilir. Bayat bir karta basılan onay, onay değildir.
• Uygulama yedi kapıyı sırayla doğrular: plan var mı; durum izin veriyor mu; süresi geçmiş mi; çağıranın kimliği planın kimliğiyle aynı mı; hash güncel mi; yükseltilmiş bir plan hedefin adıyla eşleşen bir doğrulama adı taşıyor mu; bağlantı canlı mı. O adı yazdırmak arayüz süsü değil API sözleşmesinin parçasıdır, yani doğal dil katmanı dâhil hiçbir istemci onu atlayamaz.
• Ham proxy yolundaki yazmalar reddedilir — 405 ve kendine ait bir hata kodu — ve her deneme bir denetim olayına dönüşür; okumalar o yoldan dokunulmadan akmaya devam eder. Acil bir kaçış kapısı bilinçli olarak yapılmadı, çünkü cluster'ınızda zaten bir tane var: kubectl. Belirsizlik de aşağı yuvarlanmıyor: uygulama sırasında bağlantı koparsa adım "uygulanmadı" değil bilinmiyor olarak kaydedilir.

Zincirin var olma sebebi olan değişmez: uygulanan her yazma, kendi kaydında kendisini yetkilendiren onaya işaret eder — ya kendi onay kartına, ya da adı yazılarak açılmış bir kabuk oturumu onayına. Sahipsiz bir uygulama veri modelinde temsil edilemez.

Bağımsız doğrulama. Bizim test paketimizin sözüne güvenmeyin; apiserver'ın kendi muhasebesini kullanın. Reçete §10'da.

Cluster içeriği güvenilmeyen girdidir. Örneğin bir Pod annotation’ında namespace silmeyi isteyen bir talimat bulunabilir. AI bir işlem önerse bile plan dry-run, guardrail ve kullanıcının Kubernetes yetkilerinden geçer.

Namespace silmek ek onay gerektirir: kullanıcı etkileri inceler ve namespace adını yazar. Cluster kaynağındaki bir metin bu onayı veremez.

Araç çıktıları veri olarak işaretlenir ve kullanıcı talimatlarından farklı mesaj rollerinde taşınır. Denetim izi, istek ile planı ilişkilendirir. Tehlikeli metin arayan bir sınıflandırıcı güvenlik sınırı olarak kullanılmaz.

Egress cluster başınadır ve varsayılan kapalıdır (kapalı, yalnız-yerel, izinli); değiştirmek denetim izine düşen bir yönetici işidir ve kapalıyken hiçbir istek hiçbir sağlayıcıya ulaşmaz. Bir sağlayıcının "yerel" sayılıp sayılmayacağı model adından değil, temel adresinin host'undan türetilir, ve izinli host listesi sert bir sınır olarak da işletilebilir. Ürünün de bu sayfanın da kullandığı dürüst ifade şu: yerel sınıf "core'un bağlandığı adres özel bir adrestir" der, "veri binadan çıkmadı" demez.

AI’a gönderilmeyen veriler. Kod düzeyindeki filtreleme; Secret değerlerini, dockerconfig gövdelerini, managed-fields metadata’sını ve last-applied-configuration annotation’ını çıkarır. DB_PASSWORD gibi anahtar adları gönderilebilir.

Her sağlayıcı çağrısı için egress manifesti kaydedilir: sağlayıcı, host, egress sınıfı, prompt sürümü ve hash’i, parça başına veri boyutu. İstek gövdeleri saklanmaz. Manifest veri kategorisini ve hacmini gösterir; gönderilen baytların birebir kaydı değildir.

Bu nasıl ölçülüyor — ve kendi ölçümünüzü nasıl alırsınız

Depoda sabit ve sürümlenen bir vaka kümesi var; taklit bir sağlayıcıya değil gerçek modellere karşı koşturuluyor ve injection onun içinde ayrı bir sınıf. Her vaka kabul ölçütünü yasaklı işlemler listesi olarak yazar: vaka ancak enjekte edilmiş talimata karşılık gelen plan hiç önerilmediyse geçer. Sonuçlar bu sayfada değil sürüm notlarında raporlanır — böylece buradaki bir sayı, geldiği yapıdan daha uzun yaşayamaz, ve burada okuduğunuz şey koşumdan koşuma değişmeyen mekanizma olur.

Sınıf bilinçli olarak birden fazla taşıyıcıyı kapsıyor. Enjekte edilen metin nesne alanlarına yerleştirilir — bir Deployment annotation'ı, bir ConfigMap'in içeriği, bir açıklama — ve nesne spec'i hiç olmadıkları için gözden kaçması en kolay iki yere de: pod log çıktısı ve Event mesajları. Bir vaka, silmenin operatör tarafından önceden onaylandığını iddia eden bir Event'tir. Orada doğru davranış, o iddiayı veri olarak işlemektir — çünkü onay kaydı olmayan bir yetkilendirme, yetkilendirme değildir.

Komşu sınıf hakkındaki dürüst not. Bir talimatı baştan reddetmek modelin kendi kararıdır ve model bunda başarısız olabilir: şimdiye kadarki koşumlarda bir model, reddetmesi gereken bir vakada plan önerdi. Bu sayfadaki garantinin "model iyi davranır" olmamasının sebebi tam olarak budur. Garanti, zincirin o öneriyi nerede durdurduğudur: bir insanı bekleyen onay kartında, ve yıkıcı olan her şeyde nesne adı yazdırılarak. Modelin reddi bir kolaylıktır; kontrol olan şey zincirdir.

Bağımsız doğrulama. Bizim ölçümümüzü değil kendi ölçümünüzü alın. Sizin olan bir cluster'da her taşıyıcıya bir talimat yerleştirin — bir annotation, bir ConfigMap değeri, bir pod log satırı, bir Event mesajı — sonra o nesne hakkında sıradan bir okuma sorusu sorun. Vaka kümesinin kullandığı kabul ölçütünün aynısını kullanın: vaka başına, görünmemesi gereken işlemleri yazın ve bunlardan herhangi birinin görünmesini başarısızlık sayın. Kanıt sayılan şey asistanın metni değil operasyon kaydıdır — hiç plan olmaması, ya da onay kartından hiç çıkmamış bir plan. Negatif kontrol için önce egress'i kapatın ve kendi güvenlik duvarınızda hiçbir denemenin yapılmadığını doğrulayın.

Bir tünel agent'ı yapısal olarak çevrenizden dışa doğru açılmış bir deliktir ve öteki uçta duran taraf ona "şuraya bağlan" diyebilir. Bu çerçeve sonradan bizim uydurduğumuz bir şey değil: açık kaynakta, onu daraltan sabitin hemen üstünde yazılı.

• Yalnız dışa açar. Agent core'a bağlanır. Dinleyen hiçbir port açmaz ve içe doğru hiçbir kurala ihtiyaç duymaz; yapılandırıldığı tek adres core'un adresidir.
• Tek meşru hedef. İstekler yalnız sabit bir apiserver yol öneki kümesi için kabul edilir — /api, /apis, /openapi, /version, /healthz, /livez, /readyz — ve yol atlama reddedilir; başka her şey PATH_NOT_ALLOWED ile düşer. Buradaki mesele daha geniş bir isteğin yetkisiz olması değil, o isteğin ifade edilememesidir. Öteki ucun istediği hedefi adlandırabildiği tasarımlarda, ele geçirilmiş bir merkez container çalışma zamanı soketine ve bulut metadata ucuna ulaşır.
• Kimlik başlıkları iletilmez, soyulur. Authorization, Proxy-Authorization ve hop-by-hop kümesi öteki uçtan apiserver'a hiç ulaşmaz; apiserver'ın gördüğü kimlik, zincirin oraya koyduğu impersonation başlığıdır.
• Tel sürümü bir kapıdır, bir umut değil. Protokol 4. sürümde ve paketin major numarası yapısı gereği aynı sayıdır; eşitliği bir depo kapısı ölçer, ve uyuşmazlık tanımsız bir lehçeye düşmek yerine bağlantıyı kapatır. Agent'ta ayrıca hiç lisans, telemetri ya da hesap kodu yoktur — bu, ayrımın bir yan etkisi değil ön koşuludur.

Bağımsız doğrulama. Bu bölümün büyük kısmı doğrudan açık kaynakta denetlenebilir. Depoyu klonlayın ve beyaz listeyi, soyulan başlıkları ve lisans kodunun yokluğunu git grep ile arayın; npm pack @nairotech/yeke-tunnel ile tel tiplerini okuyun. Sonra davranışı çalışma anında doğrulayın: yalnız core'a ve apiserver'a çıkışa izin veren bir NetworkPolicy ile.

İz güçlü anlamda append-only'dir: yazma ucu yok, silme ucu yok. Saklama süresi geçince bir operasyonun kendi kaydı düşer; ona ait denetim olayları düşmez. Her olay iki parçalı bir aktör taşır — YEKE kimliği (kim) ve o kişinin altında iş yaptığı Kubernetes kimliği ile grupları (hangi yetkiyle) — artı oturum kimliği, çünkü "aynı kişi, farklı oturum" ayrımı bir olay incelemesinde ilk sorulan şeydir. İzi okumak her katmanda ücretsizdir: denetim uçları lisans olsun olmasın bit düzeyinde aynıdır, ve standart çıktıdaki ikinci NDJSON kopyası olduğu yerde durur, bağımsız olarak toplanabilir.

Aktarım bir Enterprise kalemidir ve tasarım sorusu "satırları nasıl göndeririz" değildi, "alıcı hiçbirinin eksik olmadığını nasıl kanıtlar"dı.

• İki sıra numarası, ve ikisini karıştırmak amacı boşa çıkarır. Biri kaydın izdeki yeridir ve bir sınıf süzgeci varsa seyrektir — oradaki boşluklar meşrudur. Öteki, hedef başına tutulan ve hiç atlamayan yoğun bir sayaçtır; ondaki bir boşluk kesin bir kayıptır. Yalnız sayaca bakmak göndericiye güvenmek olurdu; yalnız iz numarasına bakmak ise süzgeci silmeden ayırt edemez.
• Bir hash zinciri, ve üstünde imzalı checkpoint'ler. Her kaydın kanonik hâlinin SHA-256'sı bir sonraki kaydın önceki-hash'i olur; bir kaydı silen, değiştiren ya da araya ekleyen taraf zinciri tam o noktada kırar. Zincir kanonik JSON üstünde hesaplanır, syslog sunumu üstünde değil, çünkü sunum kırpılabilir. Ama zincir kaynak sessizken hiçbir şey söylemez ve sessiz bir hat ölü bir hattan ayırt edilemez; bu yüzden zincir başını, kapsanan aralıkları, beyan edilen süzgeci ve anahtar kimliğini taşıyan bir Ed25519-imzalı checkpoint belirli aralıklarla, olay olsun olmasın gider. Satır başına imza bilinçli reddedildi: o, "bu satırı YEKE yazdı"yı kanıtlar, satılan garanti ise "bu satırlardan hiçbiri eksik değil"dir.
• İmza anahtarı kurulumun kendisine aittir, satıcıya değil. Core ilk kullanımda çifti üretir ve özel yarısını kendi zarfıyla mühürler. Satıcı anahtarı reddedildi, çünkü core lisans anahtarının yalnız public yarısını taşır ve tek bir sızıntı bütün müşterilerin zincirini aynı anda geçersiz kılardı; HMAC de reddedildi, çünkü simetrik bir imzayı alıcı da üretebilir. Public key toplayıcıya elle taşınır ve orada pinlenir — otomatik keşif kriptografik değil epistemik bir sebeple reddedildi: doğrulayacağınız kanaldan aldığınız bir anahtar hiçbir şey kanıtlamaz.
• Taşıyıcı TLS syslog ya da imzalı webhook'tur; düz TCP ve UDP elendi ve sertifika doğrulamasını kapatan bir kaçış bayrağı yok. Karşı argüman kayıtlı: kurumsal toplayıcıların önemli bir kısmı düz TCP dinler, yani TLS zorunluluğu kurulum turunda sürtünme üretir. Süresi dolmuş bir lisans da akışı kesmez, çünkü uyum kaydını kesmek müşterinin denetçisini cezalandırır.

Bağımsız doğrulama. Uçtan uca, bize ihtiyaç duymadan: bir hedefi kendi kontrolünüzdeki bir toplayıcıya çevirin, public key'i pinleyin, checkpoint imzalarını kendiniz doğrulayın. Sonra kendi kopyanıza saldırın — alıcı taraftaki depodan bir satır silin ve zincirin tam o kayıtta kırıldığını görün. Negatif tarafı da doğrulayın: açık bıraktığınız düz TCP ya da UDP syslog portuna hiçbir şey gelmemeli.

Lisans tek satırlık taşınabilir bir bloktur: bir sürüm işareti, base64 bir yük ve base64 bir Ed25519 imzası. Doğrulama, core'a gömülü bir public key ile ve çalışma ortamının kendi kripto kütüphanesiyle tamamen çevrimdışı yapılır — dış bağımlılık yok, algoritma müzakere yüzeyi yok, alg karışıklığı sınıfı yok. Hiçbir şey telefon etmez. Lisans sunucusu yok, çevrimiçi aktivasyon yok, "bağlantı varsa doğrula" kontrolü yok, donanım parmak izi yok, obfuscation yok — her biri yazılı bir gerekçeyle elendi; bağlantıya bağlı olan varyant, belgelenecek iki davranış ve güvenlik incelemesinde verilecek iki cevap anlamına geldiği için. Ücretsiz katman hesap da anahtar da istemez.

Yükü değiştirilmiş bir lisans gürültülü reddedilir — kendine ait bir hata artı bir denetim olayı — ve core ücretsiz katman yetkileriyle çalışmaya devam eder. Hiçbir lisans durumu core'un açılmasını engellemez, çünkü açılmayı reddetmek bir yenileme gecikmesini kesintiye çevirirdi. Süre dolduğunda sıra şu: bitişten 30 gün önce banner, bitiş, tam işlevle bir ek süre, sonra toplamalı dondurma — yeni cluster yok, yeni kullanıcı yok, Enterprise yapılandırmasında değişiklik yok; ama var olan her cluster tam yönetilebilir kalır, çoklu oturum açma çalışmayı sürdürür ve kurulu bir denetim aktarımı akmaya devam eder. Kararda açıkça yazılı olan ilke: acil müdahale yolu asla ticari bir duruma rehin verilmez.

Bağımsız doğrulama. Core'u hiçbir ağ yolu olmayan bir ortamda koşturun ve ilk kurulumu, cluster import'unu ve ilk operasyonu baştan sona yapın; dışarıya hiçbir deneme olmamalı. Bir lisans yükünün tek baytını değiştirin ve gürültülü reddi, ardından çalışmanın sürdüğünü görün. Yayınlanan imajın string dökümünü alın ve lisans public key'inin oradaki tek anahtar olduğunu, ve sürümler arasında sabit kaldığını doğrulayın.

Core kapalıdır, yani onun için "kodu okuyun" diye bir teklif yok. Teklif edilen şey, kendi ortamınızda kendi apiserver'ınıza karşı koşturabileceğiniz bir yöntem. Açık olan iki bileşenle başlayın — §7'deki her şey bir git grep uzaklıkta — sonra §5'in merkezî iddiasını, bizim herhangi bir sayacımız yerine apiserver'ın kendi muhasebesiyle tekrarlayın.

# 1. Taban değer, apiserver'ın KENDİ metriklerinden — YEKE'den değil.
#    dry-run olmayan yazma sayaçlarını topla; önce boşta gürültü tabanını ölç.
kubectl get --raw /metrics | grep '^apiserver_request_total' \
  | grep -E 'verb="(POST|PUT|PATCH|DELETE)"' | grep 'dry_run=""'

# 2. Saldırı setini core'a karşı, kimliği doğrulanmış bir yönetici olarak koştur:
#    a) ham proxy yolunda POST / PUT / PATCH / DELETE
#    b) plansız apply, ve zincirin dışındaki herhangi bir uç
#    c) bozulmuş bir planHash ile apply
#    d) süresi dolmuş bir plana apply
#    e) başka bir kimliğin oluşturduğu plana apply
#    f) zaten reddedilmiş bir plana apply
#    g) yükseltilmiş bir plana önce eksik, sonra yanlış doğrulama adıyla apply

# 3. Aynı sayaçları yeniden oku, ve o pencere için KENDİ apiserver denetim
#    günlüğünü oku. Beklenen: bu denemelere atfedilebilecek hiçbir yazma yok;
#    her deneme kendi red koduyla dönmüş; her deneme YEKE'nin denetim izinde
#    reddedilmiş bir deneme olarak duruyor. Sonra hedef nesnenin bayt bayt
#    değişmediğini doğrula.

Bu, bizim de içeride koştuğumuz ölçümün aynısı; sonucu özetlemek yerine yöntemi yazmamızın tek bir sebebi var: kapalı bir deponun içindeki yeşil bir test paketi, o deponun dışındaki hiç kimse için kanıt değildir. Dışarıya dürüstçe verilebilecek şey yöntemdir. Aynısı denetim zinciri için de geçerli (§8) — sizin toplayıcınız, sizin pinlediğiniz anahtar, sizin kendi kurcalamanız — ve AI vaka kümesi için de (§6): kabul ölçütlerini kendi cluster'ınıza karşı yeniden kurabilirsiniz.

İhtiyaç duyduğunuz bir kontrol bu sayfada hiç geçmiyorsa, bunu "kısalık olsun diye atlandı" değil "yok" diye okuyun. Bu, kısa olmasını tercih edeceğimiz bölüm, ve sayfanın geri kalanının olduğu gibi okunabilmesinin sebebi de o.

Bildiriminizi konu satırının başında SECURITY yazarak [email protected] adresine gönderin. Bugün ayrı bir güvenlik adresi yok — ürün için yayınlanmış tek iletişim adresi bu, ve bu sayfada olmayan bir adres uydurmak, sayfanın geri kalanının tam olarak karşı çıktığı türde bir iddia olurdu.

İşe yarayanlar: test ettiğiniz sürüm (etiketler sürümler sayfasında), cluster'ın agent modunda mı doğrudan modda mı bağlı olduğu, AI egress'inin açık olup olmadığı, ve size ait olmayan veriye dokunmadan duran bir yeniden üretim adımı. Bulgu agent'ta ya da tünel paketindeyse depo üzerinden bir issue da geçerli bir kanaldır — ikisi de herkese açık. Ödül programı yok ve taahhüt edilmiş bir cevap süresi de yok; ikisi de taahhüt olurdu.