Praktik terbaik untuk keamanan pod di Azure Kubernetes Service (AKS)
Saat Anda mengembangkan dan menjalankan aplikasi di Azure Kubernetes Service (AKS), keamanan pod Anda adalah pertimbangan utama. Aplikasi Anda harus dirancang untuk prinsip jumlah hak istimewa yang paling sedikit diperlukan. Menjaga keamanan data privat adalah prioritas utama pelanggan. Anda tidak ingin info masuk seperti string koneksi database, kunci, atau rahasia dan sertifikat yang diekspos ke dunia luar di mana penyerang dapat memanfaatkan rahasia tersebut untuk tujuan jahat. Jangan menambahkannya ke kode Anda atau menyematkannya di gambar kontainer Anda. Pendekatan ini akan menimbulkan risiko eksposur dan membatasi kemampuan untuk memutar info masuk tersebut karena gambar kontainer perlu dibuat ulang.
Artikel praktik terbaik ini berfokus pada cara mengamankan pod di AKS. Anda akan mempelajari cara untuk:
- Menggunakan konteks keamanan pod untuk membatasi akses ke proses dan layanan atau eskalasi hak istimewa
- Mengautentikasi dengan sumber daya Azure lainnya menggunakan ID Beban Kerja Microsoft Entra
- Meminta dan mengambil info masuk dari vault digital seperti Azure Key Vault
Anda juga dapat membaca praktik terbaik untuk keamanan kluster dan untuk manajemen gambar kontainer.
Mengamankan akses pod ke sumber daya
Panduan praktik terbaik - Untuk menjalankan sebagai pengguna atau grup yang berbeda dan membatasi akses ke proses dan layanan simpul yang mendasarinya, tentukan pengaturan konteks keamanan pod. Tetapkan jumlah hak istimewa paling sedikit yang diperlukan.
Agar aplikasi berjalan dengan benar, pod harus berjalan sebagai pengguna atau grup yang ditentukan dan bukan sebagai root. securityContext untuk pod atau kontainer memungkinkan Anda menentukan pengaturan seperti runAsUser atau fsGroup untuk menggunakan izin yang sesuai. Hanya tetapkan izin pengguna atau grup yang diperlukan, dan jangan gunakan konteks keamanan sebagai sarana untuk menerima izin tambahan. runAsUser, eskalasi hak istimewa, dan pengaturan kemampuan Linux lainnya hanya tersedia di simpul dan pod Linux.
Saat Anda menjalankan sebagai pengguna non-root, kontainer tidak dapat mengikat ke port istimewa di bawah 1024. Dalam skenario ini, Kubernetes Services dapat digunakan untuk menyamarkan fakta bahwa aplikasi berjalan pada port tertentu.
Konteks keamanan Pod juga dapat menentukan kemampuan atau izin tambahan untuk mengakses proses dan layanan. Definisi konteks keamanan umum berikut dapat diatur:
- allowPrivilegeEscalation menentukan apakah pod dapat menggunakan hak istimewa root. Rancang aplikasi Anda sehingga pengaturan ini selalu diatur ke salah.
- Kemampuan Linux memungkinkan pod mengakses proses simpul yang mendasarinya. Berhati-hatilah saat menetapkan kemampuan ini. Tetapkan jumlah hak istimewa paling sedikit yang diperlukan. Untuk informasi selengkapnya, lihat kemampuan Linux.
- Label SELinux adalah modul keamanan kernel Linux yang memungkinkan Anda menentukan kebijakan akses untuk layanan, proses, dan akses sistem file. Sekali lagi, tetapkan jumlah hak istimewa paling sedikit yang diperlukan. Untuk informasi selengkapnya, lihat opsi SELinux di Kubernetes
Contoh manifes YAML pod berikut mengatur pengaturan konteks keamanan untuk ditentukan:
- Pod dijalankan sebagai ID pengguna 1000 dan bagian dari ID grup 2000
- Tidak dapat meningkatkan hak istimewa untuk menggunakan
root - Memungkinkan kemampuan Linux untuk mengakses antarmuka jaringan dan jam (perangkat keras) real-time milik host
apiVersion: v1
kind: Pod
metadata:
name: security-context-demo
spec:
securityContext:
fsGroup: 2000
containers:
- name: security-context-demo
image: mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine
securityContext:
runAsUser: 1000
allowPrivilegeEscalation: false
capabilities:
add: ["NET_ADMIN", "SYS_TIME"]
Bekerja samalah dengan operator kluster Anda untuk menentukan pengaturan konteks keamanan yang Anda butuhkan. Cobalah untuk merancang aplikasi Anda untuk meminimalkan izin tambahan dan akses yang dibutuhkan pod. Terdapat fitur keamanan tambahan untuk membatasi akses menggunakan AppArmor dan seccomp (komputasi aman) yang dapat diimplementasikan oleh operator kluster. Untuk informasi selengkapnya, lihat Mengamankan akses kontainer ke sumber daya.
Batasi eksposur info masuk
Panduan praktik terbaik - Jangan tentukan info masuk dalam kode aplikasi Anda. Gunakan identitas terkelola untuk sumber daya Azure untuk memungkinkan pod meminta akses ke sumber daya lain. Seperti Azure Key Vault, vault digital juga harus digunakan untuk menyimpan dan mengambil kunci dan info masuk digital. Identitas yang dikelola pod dimaksudkan untuk digunakan dengan pod Linux dan gambar kontainer saja.
Untuk membatasi risiko info masuk yang terekspos dalam kode aplikasi Anda, hindari penggunaan info masuk tetap atau bersama. Info masuk atau kunci tidak boleh disertakan langsung dalam kode Anda. Jika info masuk ini terekspos, aplikasi perlu diperbarui dan disebarkan ulang. Pendekatan yang lebih baik adalah memberi pod identitasnya sendiri dan cara mengautentikasi dirinya, atau secara otomatis mengambil info masuk dari vault digital.
Menggunakan ID Beban Kerja Microsoft Entra
Identitas beban kerja adalah identitas yang digunakan oleh aplikasi yang berjalan di pod yang dapat mengautentikasi dirinya terhadap layanan Azure lain yang mendukungnya, seperti Storage atau SQL. Ini terintegrasi dengan kemampuan asli Kubernetes untuk bergabung dengan penyedia identitas eksternal. Dalam model keamanan ini, kluster AKS bertindak sebagai penerbit token, MICROSOFT Entra ID menggunakan OpenID Koneksi untuk menemukan kunci penandatanganan publik dan memverifikasi keaslian token akun layanan sebelum menukarnya dengan token Microsoft Entra. Beban kerja Anda dapat menukar token akun layanan yang diproyeksikan ke volumenya untuk token Microsoft Entra menggunakan pustaka klien Azure Identity menggunakan Azure SDK atau Microsoft Authentication Library (MSAL).
Untuk informasi selengkapnya tentang identitas beban kerja, lihat Mengonfigurasi kluster AKS untuk menggunakan ID Beban Kerja Microsoft Entra dengan aplikasi Anda
Menggunakan Azure Key Vault dengan Driver CSI Penyimpanan Rahasia
Menggunakan ID Beban Kerja Microsoft Entra memungkinkan autentikasi terhadap layanan Azure yang mendukung. Untuk layanan atau aplikasi Anda sendiri tanpa identitas terkelola untuk sumber daya Azure, Anda masih dapat mengautentikasi menggunakan info masuk atau kunci. Vault digital dapat digunakan untuk menyimpan isi rahasia ini.
Saat aplikasi membutuhkan info masuk, aplikasi berkomunikasi dengan vault digital, mengambil konten rahasia terbaru, dan kemudian menyambung ke layanan yang diperlukan. Azure Key Vault bisa menjadi vault digital ini. Alur kerja yang disederhanakan untuk mengambil info masuk dari Azure Key Vault menggunakan identitas yang dikelola pod ditampilkan dalam diagram berikut:
Dengan Key Vault, Anda menyimpan dan secara teratur memutar rahasia seperti info masuk, kunci akun penyimpanan, atau sertifikat. Anda dapat mengintegrasikan Azure Key Vault dengan kluster AKS menggunakan penyedia Vault Kunci Azure untuk Driver CSI Penyimpanan Rahasia. Driver CSI Penyimpanan Rahasia memungkinkan kluster AKS untuk mengambil kembali konten rahasia dari Key Vault dan dengan aman menyediakannya hanya ke pod yang meminta. Bekerja samalah dengan operator kluster Anda untuk menyebarkan Driver CSI Penyimpanan Rahasia ke simpul pekerja AKS. Anda dapat menggunakan ID Beban Kerja Microsoft Entra untuk meminta akses ke Key Vault dan mengambil konten rahasia yang diperlukan melalui Driver Secrets Store CSI.
Langkah berikutnya
Artikel ini berfokus pada cara mengamankan pod Anda. Untuk menerapkan beberapa praktik terbaik ini, lihat artikel-artikel berikut: