SREK3S adalah seorang Site Reliability Engineer (SRE) yang dipower oleh AI dan berorientasi pada keamanan untuk kluster Kubernetes Anda. Kebanyakan agen AI Kubernetes saat ini adalah rootkit yang menunggu untuk terjadi. Mereka meminta hak cluster-admin dan mengalirkan stdout mentah ke API LLM eksternal. SREK3S adalah agen tanggap insiden yang berbasis zero-trust dan read-only. Ia menangkapi kecelakaan pod, membersihkan rahasia di memori sebelum egress jaringan, dan mensandbox triage LLM di pekerja POSIX-jailed. Ia menghasilkan patch GitOps yang diverifikasi dengan otoritas penulisan kluster yang sepenuhnya nol dan gagal secara deterministik ke ulasan manusia.

Fitur Utama dan Keamanan SREK3S

  • SREK3S memiliki beberapa fitur utama. Pertama, ia tidak melakukan mutasi kluster: hanya namespaced get, list, dan watch. Tidak ada ClusterRole, tidak ada field write di kontrak kabel, dan tidak ada token yang dimount di agen. Kedua, ia melakukan pemeriksaan rahasia di memori: 11 aturan regex berurutan dijalankan sebelum egress. Tidak ada yang terungkap mencapai antrian, disk, atau soket. Ketiga, ia melakukan validasi AST YAML: sebuah patch bertahan dari parse AST YAML, lalu git apply --check terhadap byte target sendiri. Keempat, ia memiliki eskalasi Tier-2 yang deterministik: tier, patch, dan setiap bendera dihitung sebelum model dikonsultasikan.
  • Banyak "agen SRE AI" adalah kegagalan kontrol katastrofis yang disamarkan sebagai fitur. Dengan memikat akun layanan ke cluster-admin dan memount kredensial mentah, mereka mengubah stdout kontainer—yang sering kali bocor kunci AWS dan kata sandi Postgres—menjadi pipa eksfiltrasi ke LLM pihak ketiga. Lebih buruk lagi, memberikan otoritas penulisan model mengubah injeksi prompt baris log menjadi mutasi kluster penuh yang tidak memerlukan kerentanan apapun di model itu sendiri. Saya membangun SREK3S untuk mengambil pendekatan yang berlawanan: menghapus kemampuan secara keseluruhan.
  • SREK3S adalah responder insiden AI yang berbasis zero-trust dan read-only. Karena ia tidak memiliki otoritas penulisan kluster di mana pun dalam arsitekturnya, pertanyaan apakah model akan melakukan sesuatu yang berbahaya tidak pernah timbul—ia fisiknya tidak bisa. SREK3S mengenforce batas keamanan yang ketat dan struktural: Pemeriksaan Rahasia di Memori: Tidak ada rahasia yang melintasi batas egress jaringan. Sentinel Go menggunakan paket hermetik untuk membersihkan rahasia di memori, di node, sebelum soket apapun dibuka. Aturan yang Terurut dan Normatif: Pemeriksaan mengikuti 11 aturan yang ketat (menargetkan blok PEM, JWT, kunci AWS), mengeksekusi pass cross-line pertama untuk mencegah unmasking sebagian. RBAC Zero-Write: Sentinel dibatasi pada Role namespaced yang hanya get, list, dan watch. Tidak ada ClusterRole atau binding. Agen Tanpa Kredensial: Agen Python berjalan dengan automountServiceAccountToken: false sebagai UID 10001 dengan sistem file root-only read dan semua kemampuan diturunkan.
  • SREK3S tidak hanya memproses hasil halusinasi model ke kubectl apply. Ia mengatasi output LLM dengan kecurigaan yang ekstrem. Validasi AST YAML: fungsi verify_yaml_ast memparsing dokumen asli dan yang dipatch menjadi Abstract Syntax Trees untuk membuktikan hanya satu field semantik yang berubah, menangkap kesalahan tipe yang dif-mudah lewatkan. Failsafes GitOps yang Sesungguhnya: Ia menjalankan git apply --check di repo buangan yang dimaterialisasi terhadap byte yang tepat yang disediakan, menolak untuk menormalisasi atau memperbaiki output yang rusak. Sandboxing POSIX yang Dapat Dibuang: Analisis dieksekusi di proses anak yang dibatasi oleh batasan yang ketat (256 MiB memori, 1 detik CPU, 0 core dump). Tidak ada state yang bertahan setelah investigasi. Hukum Fail-Closed: Routing insiden adalah deterministik. Jika bukti ambigu (misalnya, CrashLoopBackOff yang generik), SREK3S menolak untuk menebak, secara default mengirimkan ulasan arsitektur Tier-2 yang mengirimkan laporan war room Markdown tanpa mengusulkan patch.
  • Saya tidak hanya menulis tes jalur bahagia; saya mencoba memecahkan sistem ini dengan cara yang bisa dibayangkan. Basis kode melewati setiap gerbang yang saya dapat lemparkan (go vet, gofmt, -race, black, flake8, mypy, pytest), saat ini berada di 1087 tes yang lulus (179 di Go). Scrubber Corpus: Pembersih memori divalidasi terhadap korpus 46 kasus yang meliputi 8 kelompok. Ini termasuk 32 rahasia yang dapat dimasking dan kelompok negative_controls yang khusus dari 6 kasus yang harus bertahan tanpa sentuhan—karena alat pemeriksaan yang hanya memblanking semua hal adalah sepenuhnya tidak berguna. Pembatasan Kinerja: Sistem mengenforce anggaran throughput ≥20,000 baris/detik/core. Ini memastikan pemasking tetap di dalam anggaran deteksi 2 detik, dengan aturan dikompilasi tepat sekali dan tidak pernah dikompilasi ulang di jalur panas.
  • Saya membangun gerbang build (test_scrubber_manifest_spec.py) yang memparsing tabel aturan normatif langsung dari CONTRIBUTING.md dan gagalkan build jika ID aturan, urutan, atau pola kode berdrift dari dokumentasi. Pengenforcean RBAC: TestSentinelRoleGrantsNoMutatingVerb memparsing YAML deployment dan gagalkan build jika kata kerja selain get, list, atau watch pernah menyusup ke Role Sentinel. Menangkap Defek yang Sesungguhnya: Saya mendokumentasikan kegagalan saya di lessons-learned.md. Pengujian ekstensif menangkap kasus tepi seperti fixture CrashLoop yang tidak terdeteksi oleh restartPolicy: Never, selector Service yang tidak berjalan ke mana pun meskipun 16 manifest tes hijau, dan blok terminationGracePeriodSeconds yang salah ditempatkan di tingkat kontainer—which tes cocok teks melewatkan, tetapi server API sebenarnya menolaknya.
  • SREK3S mengekstraksi kemampuan yang benar-benar berguna dari LLM—membaca bukti kecelakaan dan membentuk hipotesis—tanpa menyerahkan kunci kluster. Cobalah dalam 60 Detik. SREK3S adalah open-source dan dilisensikan MIT. Karena ia bergantung pada informer client-go standar, ia dapat dengan mudah di-deploy ke kluster apapun yang konform (k8s, k3s, Minikube, EKS). Anda tidak perlu membangun biner Go atau mengompilasi Python untuk mengujinya. Kami menerbitkan gambar multi-arch langsung ke GHCR. Clone repositori, terapkan overlay quickstart, dan detonasi fixture kebocoran memori yang disediakan untuk melihat pemeriksaan memori langsung terjadi.