Ringkasan keamanan

Kf bertujuan untuk memberikan pengalaman developer yang serupa dengan Cloud Foundry, dengan mereplikasi siklus proses build, push, dan deploy. Hal ini dilakukan dengan membangun lapisan UX developer di atas teknologi yang sudah dikenal luas, digunakan, dan diadopsi seperti Kubernetes, Istio, dan registry container, bukan dengan mengimplementasikan semua bagian dari awal.

Saat membuat keputusan keamanan, Kf bertujuan untuk memberikan solusi lengkap yang berasal dari komponen masing-masing dan dapat ditingkatkan dengan mekanisme lain. Membahas hal itu:

  • Solusi lengkap berarti Kf berusaha untuk tidak memberikan solusi parsial yang dapat menyebabkan rasa aman yang semu.
  • Native berarti solusi harus menjadi bagian dari komponen, bukan konstruksi Kf untuk mencegah perubahan yang dapat menyebabkan gangguan.
  • Dapat ditingkatkan berarti pendekatan yang diambil Kf harus berfungsi tanpa hambatan dengan alat Kubernetes dan Google Cloud lainnya untuk pertahanan mendalam.

Pertimbangan penting

Selain Batasan saat ini yang dijelaskan di bawah, penting bagi Anda untuk membaca dan memahami item yang diuraikan di bagian ini.

Workload Identity

Secara default, Kf menggunakan Workload Identity untuk memberikan pengiriman yang aman dan rotasi kredensial Akun Layanan 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:

  1. Menulis metrik ke Stackdriver
  2. Saat ruang Kf baru dibuat (kf create-space), pengontrol Kf membuat KSA baru bernama kf-builder di ruang baru dan memetakannya ke GSA yang sama.
  3. KSA kf-builder digunakan oleh Tekton untuk mengirim dan menarik image container ke Google Container Registry (gcr.io)

Diagram ini menggambarkan interaksi tersebut:

Batasan saat ini

  • Kf tidak menyediakan peran RBAC bawaan. Gunakan RBAC hingga Kf memberikannya.

  • Developer yang mendorong aplikasi dengan Kf juga dapat membuat Pod (dengan kubectl) yang dapat menggunakan KSA kf-builder dengan izin GSA terkaitnya.

  • Men-deploy ke Kf memerlukan akses tulis ke registry container. Deploy Kf dalam project khusus tanpa akses ke resource produksi. Beri developer akses untuk mengirim kode ke Artifact Repository dengan memberi mereka roles/storage.admin di project atau bucket yang digunakan Artifact Repository.

  • Kf menggunakan Pod yang sama untuk mengambil, membuat, dan menyimpan gambar. Asumsikan bahwa kredensial yang Anda berikan dapat diketahui oleh penulis dan penerbit buildpack yang Anda gunakan.

  • Kf tidak mendukung kuota untuk melindungi dari tetangga yang berisik. Gunakan kuota resource Kubernetes.

Resource lainnya

Umum

Perlindungan lanjutan