Kf bertujuan untuk memberikan pengalaman developer yang serupa dengan Cloud Foundry, yang mereplikasi siklus proses build, push, dan deploy. Hal ini dilakukan dengan membuat lapisan UX developer di atas teknologi yang dikenal luas, digunakan secara luas, dan diadopsi seperti Kubernetes, Istio, dan registry container, bukan dengan menerapkan semua bagian dari awal.
Ringkasan keamanan
Saat membuat keputusan keamanan, Kf bertujuan untuk memberikan solusi lengkap yang native untuk komponen masing-masing dan dapat dilengkapi dengan mekanisme lain. Berikut penjelasannya:
- Solusi lengkap berarti Kf mencoba untuk tidak memberikan solusi parsial yang dapat menyebabkan rasa aman palsu.
- Native berarti solusi harus menjadi bagian dari komponen, bukan konstruksi Kf, untuk mencegah perubahan yang dapat menyebabkan gangguan.
- Dapat ditambahkan berarti pendekatan yang diambil Kf harus berfungsi dengan lancar dengan alat Kubernetes dan Google Cloud lainnya untuk pertahanan menyeluruh.
Pertimbangan penting
Selain Batasan saat ini yang dijelaskan di bawah, Anda harus membaca dan memahami item yang diuraikan di bagian ini.
Workload Identity
Secara default, Kf menggunakan Workload Identity untuk memberikan pengiriman dan rotasi kredensial Akun Layanan yang aman yang digunakan oleh Kf untuk berinteraksi dengan project Google Cloud Anda. Workload Identity mencapai hal ini dengan memetakan Akun Layanan Kubernetes (KSA) ke Akun Layanan Google (GSA). Pengontrol Kf berjalan di namespace kf
dan menggunakan KSA bernama controller
yang dipetakan ke GSA Anda untuk melakukan hal-hal berikut:
- Menulis metrik ke Stackdriver
- Saat ruang Kf baru dibuat (
kf create-space
), pengontrol Kf akan membuat KSA baru bernamakf-builder
di ruang baru dan memetakan ke GSA yang sama. - KSA
kf-builder
digunakan oleh Tekton untuk mengirim dan menarik image container ke Google Container Registry (gcr.io)
Diagram ini mengilustrasikan interaksi tersebut:
Batasan saat ini
- Kf tidak menyediakan peran RBAC bawaan.
- Sampai Kf menyediakannya, gunakan RBAC.
- Developer yang mendorong aplikasi dengan Kf juga dapat membuat pod (dengan
kubectl
) yang dapat menggunakan KSAkf-builder
dengan izin GSA terkait. - Men-deploy ke Kf memerlukan akses tulis ke registry penampung.
- Men-deploy Kf dalam project khusus tanpa akses ke resource produksi.
- Berikan akses kepada developer untuk mengirim kode ke Repositori Artefak dengan memberi mereka
roles/storage.admin
di project, atau bucket yang digunakan Repositori Artefak.
- Kf menggunakan Pod yang sama untuk mengambil, mem-build, dan menyimpan image.
- Asumsikan kredensial apa pun yang Anda berikan dapat diketahui oleh penulis dan penayang buildpack yang Anda gunakan.
- Kf tidak mendukung kuota untuk melindungi dari tetangga yang berisik.
- Gunakan kuota resource Kubernetes.