Praktik terbaik untuk keamanan dan pemutakhiran klaster di Azure Kubernetes Service (AKS)

  • Artikel

Saat Anda mengelola klaster di Azure Kubernetes Service (AKS), beban kerja dan keamanan data perlu menjadi pertimbangan utama. Saat Anda menjalankan klaster multi-penyewa menggunakan isolasi logis, Anda perlu mengamankan akses sumber daya dan beban kerja. Minimalkan risiko serangan dengan menerapkan pembaruan keamanan Kubernetes dan OS node terbaru.

Artikel ini berfokus pada cara mengamankan kontainer Anda di AKS. Anda akan mempelajari cara untuk:

  • Gunakan ID Microsoft Entra dan kontrol akses berbasis peran Kubernetes (Kubernetes RBAC) untuk mengamankan akses server API.
  • Amankan akses kontainer ke sumber daya node.
  • Upgrade klaster AKS ke versi Kubernetes terbaru.
  • Jangan lupa untuk memutakhirkan node dan menerapkan patch keamanan secara otomatis.

Anda juga dapat membaca praktik terbaik untuk manajemen citra kontainer dan untuk keamanan Pod.

Aktifkan perlindungan ancaman

Panduan praktik terbaik

Anda dapat mengaktifkan Defender untuk Kontainer guna membantu mengamankan kontainer Anda. Defender untuk Kontainer dapat menilai konfigurasi kluster serta memberikan rekomendasi keamanan, menjalankan pemindaian kerentanan, dan memberikan perlindungan dan peringatan real time untuk simpul dan kluster Kubernetes.

Akses aman ke API Server dan node klaster

Panduan praktik terbaik

Salah satu cara terpenting untuk mengamankan klaster adalah dengan mengamankan akses ke API Server Kubernetes. Untuk mengontrol akses ke server API, integrasikan Kubernetes RBAC dengan Microsoft Entra ID. Dengan kontrol ini, Anda mengamankan AKS dengan cara yang sama seperti Anda mengamankan akses ke langganan Azure Anda.

API Server Kubernetes menyediakan satu titik koneksi untuk permintaan untuk melakukan tindakan dalam klaster. Untuk mengamankan dan mengaudit akses ke API Server, batasi akses dan berikan tingkat izin serendah mungkin. meskipun pendekatan ini tidak unik untuk Kubernetes, ini sangat penting ketika Anda telah secara logis mengisolasi klaster AKS untuk penggunaan multi-tenant.

MICROSOFT Entra ID menyediakan solusi manajemen identitas siap perusahaan yang terintegrasi dengan kluster AKS. Karena Kubernetes tidak menyediakan solusi manajemen identitas, Anda mungkin sulit untuk membatasi akses ke API Server secara terperinci. Dengan kluster terintegrasi Microsoft Entra di AKS, Anda menggunakan akun pengguna dan grup yang ada untuk mengautentikasi pengguna ke server API.

Microsoft Entra integration for AKS clusters

Dengan menggunakan RBAC Kubernetes dan integrasi ID Microsoft Entra, Anda dapat mengamankan server API dan memberikan izin minimum yang diperlukan untuk kumpulan sumber daya terlingkup, seperti satu namespace. Anda dapat memberikan berbagai peran Kubernetes kepada pengguna atau grup Microsoft Entra. Dengan izin terperinci, Anda dapat membatasi akses ke API Server dan menyediakan jejak audit tindakan yang jelas yang dilakukan.

Praktik terbaik yang disarankan adalah menggunakan grup untuk menyediakan akses ke file dan folder alih-alih identitas individual. Misalnya, gunakan keanggotaan grup ID Microsoft Entra untuk mengikat pengguna ke peran Kubernetes daripada pengguna individual. Saat keanggotaan grup pengguna berubah, izin akses mereka pada klaster AKS juga ikut berubah.

Sementara itu, anggap saja Anda mengikat pengguna individu langsung ke peran dan fungsi pekerjaan mereka akan berubah. Meskipun keanggotaan grup Microsoft Entra diperbarui, izin mereka pada kluster AKS tidak akan. Dalam skenario ini, pengguna akan mendapatkan lebih banyak izin daripada yang mereka butuhkan.

Untuk informasi selengkapnya tentang integrasi Microsoft Entra, RBAC Kubernetes, dan Azure RBAC, lihat Praktik terbaik untuk autentikasi dan otorisasi di AKS.

Membatasi akses ke API Metadata Instans

Panduan praktik terbaik

Tambahkan kebijakan jaringan di semua ruang nama pengguna untuk memblokir jalan keluar pod ke titik akhir metadata.

Catatan

Untuk menerapkan Kebijakan Jaringan, sertakan atribut --network-policy azure saat membuat kluster AKS. Gunakan perintah berikut untuk membuat kluster: az aks create -g myResourceGroup -n myManagedCluster --enable-managed-identity --network-plugin azure --network-policy azure

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: restrict-instance-metadata
spec:
  podSelector:
    matchLabels: {}
  policyTypes:
  - Egress
  egress:
  - to:
    - ipBlock:
        cidr: 10.10.0.0/0#example
        except:
        - 169.254.169.254/32

Amankan akses kontainer ke sumber daya

Panduan praktik terbaik

Batasi akses ke tindakan yang dapat dilakukan kontainer. Berikan izin dalam jumlah serendah mungkin, dan hindari penggunaan akses root atau eskalasi istimewa.

Sama halnya dengan prinsip bahwa Anda harus memberikan izin sesedikit mungkin untuk pengguna dan grup, Anda juga harus membatasi kontainer untuk hanya melakukan tindakan dan proses yang benar-benar dibutuhkan. Untuk meminimalkan risiko serangan, hindari konfigurasi aplikasi dan kontainer yang memerlukan eskalasi hak istimewa atau akses root.

Misalnya, diatur allowPrivilegeEscalation: false dalam manifes Pod. Konteks keamanan Pod Kubernetes bawaan ini memungkinkan Anda menentukan izin tambahan, seperti pengguna atau grup untuk dijalankan, atau kemampuan Linux mengekspos. Untuk praktik terbaik lainnya, lihat Mengamankan akses Pod ke sumber daya.

Untuk kontrol tindakan kontainer yang lebih terperinci, Anda juga dapat menggunakan fitur keamanan Linux bawaan seperti AppArmor dan seccomp.

  1. Tentukan fitur keamanan Linux di tingkat node.
  2. Terapkan fitur melalui manifes Pod.

Fitur keamanan Linux bawaan hanya tersedia di node dan Pod Linux.

Catatan

Saat ini, lingkungan Kubernetes tidak sepenuhnya aman untuk penggunaan multi-tenant yang hostile. Fitur keamanan tambahan, seperti Microsoft Defender untuk KontainerAppArmor, seccomp,Pod Security Admission, atau Kubernetes RBAC untuk beberapa node, akan memblokir eksploitasi secara efisien.

Untuk memastikan keamanan saat menjalankan beban kerja multi-penyewa yang hostile, jangan percayai siapa pun selain hypervisor. Domain keamanan untuk Kubernetes menjadi seluruh kluster, bukan simpul individual.

Untuk jenis beban kerja multi-penyewa yang tidak bersahabat ini, Anda harus menggunakan kluster yang terisolasi secara fisik.

App Armor

Untuk membatasi tindakan kontainer, Anda dapat menggunakan AppArmor modul keamanan kernel Linux. 'AppArmor tersedia sebagai bagian dari OS node AKS yang mendasarinya, dan diaktifkan secara default. Anda membuat profil AppArmor yang membatasi tindakan membaca, menulis, atau menjalankan, atau fungsi sistem seperti memasang sistem file. Profil AppArmor default akan membatasi akses ke berbagai lokasi /proc dan /sys, serta menyediakan sarana untuk mengisolasi kontainer secara logis dari node yang mendasarinya. AppArmor bekerja untuk aplikasi apa pun yang berjalan di Linux, bukan hanya Pod Kubernetes.

AppArmor profiles in use in an AKS cluster to limit container actions

Untuk melihat AppArmor dalam tindakan, contoh berikut membuat profil yang mencegah penulisan ke file.

  1. SSH ke node AKS.

  2. Buat file bernama deny-write.profile.

  3. Salin dan tempel konten berikut:

    #include <tunables/global>
profile k8s-apparmor-example-deny-write flags=(attach_disconnected) {
  #include <abstractions/base>

  file,
  # Deny all file writes.
  deny /** w,
}

Profil AppArmor ditambahkan menggunakan apparmor_parser perintah.

  1. Tambahkan profil ke AppArmor.

  2. Tentukan nama profil yang dibuat di langkah sebelumnya:

    sudo apparmor_parser deny-write.profile

    Jika profil diurai dengan benar dan diterapkan ke AppArmor, Anda tidak akan melihat output apa pun dan Anda akan dikembalikan ke prompt perintah.

  3. Dari mesin lokal, buat manifes Pod bernama aks-apparmor.yaml. Manifes ini:

    • Tentukan anotasi untuk container.apparmor.security.beta.kubernetes.
    • Rujuk profil deny-write yang dibuat di langkah-langkah sebelumnya.
    apiVersion: v1
kind: Pod
metadata:
  name: hello-apparmor
  annotations:
    container.apparmor.security.beta.kubernetes.io/hello: localhost/k8s-apparmor-example-deny-write
spec:
  containers:
  - name: hello
    image: mcr.microsoft.com/dotnet/runtime-deps:6.0
    command: [ "sh", "-c", "echo 'Hello AppArmor!' && sleep 1h" ]

  4. Dengan pod yang disebarkan, jalankan perintah berikut dan verifikasi pod hello-apparmor menunjukkan status Berjalan :

    kubectl get pods

NAME             READY   STATUS    RESTARTS   AGE
aks-ssh          1/1     Running   0          4m2s
hello-apparmor   0/1     Running   0          50s

Untuk informasi lebih lanjut tentang AppArmor, lihat profil AppArmor di Kubernetes.

Komputasi aman

Jika AppArmor dapat bekerja untuk aplikasi Linux apa pun, seccomp(secure computing) hanya berfungsi pada tingkat proses. Seccomp juga merupakan modul keamanan kernel Linux, dan secara native didukung oleh runtime Docker yang digunakan oleh node AKS. Dengan seccomp, Anda dapat membatasi panggilan proses kontainer. Ikuti praktik terbaik untuk memberikan izin seminimal mungkin kepada kontainer:

  • Menentukan dengan memfilter tindakan apa yang dapat diperbolehkan atau sebaliknya.
  • Menganotasi dalam manifes YAML Pod untuk mengaitkan dengan filter seccomp.

Untuk melihat seccomp dalam tindakan, buat filter yang mencegah perubahan izin pada file.

  1. SSH ke node AKS.

  2. Buat filter seccomp bernama /var/lib/kubelet/seccomp/prevent-chmod.

  3. Salin dan tempel konten berikut:

    {
  "defaultAction": "SCMP_ACT_ALLOW",
  "syscalls": [
    {
      "name": "chmod",
      "action": "SCMP_ACT_ERRNO"
    },
    {
      "name": "fchmodat",
      "action": "SCMP_ACT_ERRNO"
    },
    {
      "name": "chmodat",
      "action": "SCMP_ACT_ERRNO"
    }
  ]
}

    Di versi 1.19 dan yang lebih baru, Anda perlu mengonfigurasi hal-hal berikut:

    {
  "defaultAction": "SCMP_ACT_ALLOW",
  "syscalls": [
    {
      "names": ["chmod","fchmodat","chmodat"],
      "action": "SCMP_ACT_ERRNO"
    }
  ]
}

  4. Dari mesin lokal, buat manifes Pod bernama aks-seccomp.yaml dan paste konten berikut. Manifes ini:

    • Tentukan anotasi untuk seccomp.security.alpha.kubernetes.io.
    • Rujuk filter prevent-chmod yang dibuat pada langkah sebelumnya.
    apiVersion: v1
kind: Pod
metadata:
  name: chmod-prevented
  annotations:
    seccomp.security.alpha.kubernetes.io/pod: localhost/prevent-chmod
spec:
  containers:
  - name: chmod
    image: mcr.microsoft.com/dotnet/runtime-deps:6.0
    command:
      - "chmod"
    args:
     - "777"
     - /etc/hostname
  restartPolicy: Never

    Di versi 1.19 dan yang lebih baru, Anda perlu mengonfigurasi hal-hal berikut:

    apiVersion: v1
kind: Pod
metadata:
  name: chmod-prevented
spec:
  securityContext:
    seccompProfile:
      type: Localhost
      localhostProfile: prevent-chmod
  containers:
  - name: chmod
    image: mcr.microsoft.com/dotnet/runtime-deps:6.0
    command:
      - "chmod"
    args:
     - "777"
     - /etc/hostname
  restartPolicy: Never

  5. Sebarkan contoh Pod dengan menggunakan perintah kubectl apply:

    kubectl apply -f ./aks-seccomp.yaml

  6. Lihat status Pod menggunakan perintah kubectl get Pods.

    • Pod melaporkan kesalahan.
    • Perintah chmod dicegah untuk dijalankan oleh filter seccomp, seperti yang ditunjukkan dalam contoh output berikut:
    kubectl get pods

NAME                      READY     STATUS    RESTARTS   AGE
chmod-prevented           0/1       Error     0          7s

Untuk informasi selengkapnya tentang filter yang tersedia, lihat Profil keamanan Seccomp untuk Docker.

Lakukan pemutakhiran ke versi terbaru Kubernetes secara teratur

Panduan praktik terbaik

Untuk memastikan Anda memiliki fitur dan perbaikan bug termutakhir, lakukan peningkatan versi Kubernetes secara teratur di klaster AKS Anda.

Kubernetes merilis fitur baru dengan lebih cepat daripada platform infrastruktur yang lebih tradisional. Pembaruan Kubernetes meliputi:

  • Fitur baru
  • Perbaikan bug atau keamanan

Fitur baru biasanya melewati status alfa dan beta sebelum menjadi stabil. Setelah stabil, ia akan tersedia dan direkomendasikan untuk produksi. Siklus rilis fitur baru Kubernetes memungkinkan Anda untuk memperbarui Kubernetes tanpa mengalami perubahan yang besar atau harus menyesuaikan deployment dan template Anda.

AKS mendukung tiga kubernetes versi minor. Setelah versi patch minor baru diperkenalkan, versi minor tertua dan rilis patch yang didukung akan dihentikan. Pembaruan Kubernetes kecil terjadi secara berkala. Untuk tetap mendukung, pastikan Anda memiliki proses tata kelola untuk memeriksa peningkatan yang diperlukan. Untuk informasi selengkapnya, lihat AKS versi Kubernetes yang didukung.

Untuk memeriksa versi yang tersedia untuk klaster Anda, gunakan perintah az aks get-upgrade seperti yang diperlihatkan dalam contoh berikut:

az aks get-upgrades --resource-group myResourceGroup --name myAKSCluster --output table

Anda kemudian dapat memutakhirkan klaster AKS menggunakan perintah upgrade az aks. Proses pemutakhiran akan dengan aman:

  • Mengarantina dan menguras satu per satu node.
  • Menjadwalkan Pod pada node yang tersisa.
  • Menyebarkan node baru yang menjalankan versi OS dan Kubernetes terbaru.

Penting

Lakukan pengujian versi minor baru di lingkungan dev test dan pastikan bahwa beban kerja anda tetap sehat dengan versi Kubernetes yang baru.

Kubernetes dapat menghentikan API (seperti pada versi 1.16) yang diandalkan oleh beban kerja Anda. Saat memproduksi versi baru, pertimbangkan untuk menggunakan beberapa kumpulan node pada versi terpisah dan tingkatkan kumpulan individual satu per satu untuk secara progresif menggulirkan pembaruan di seluruh klaster. Jika menjalankan beberapa klaster, tingkatkan satu klaster sekaligus untuk memantau dampak atau perubahan secara progresif.

az aks upgrade --resource-group myResourceGroup --name myAKSCluster --kubernetes-version KUBERNETES_VERSION

Untuk informasi lebih lanjut mengenai peningkatan di AKS, lihat Versi Kubernetes yang Didukung di AKS dan Upgrade klaster AKS.

Memproses pembaruan simpul Linux

Setiap malam, node Linux di AKS mendapatkan patch keamanan melalui kanal pembaruan distro mereka. Perilaku ini secara otomatis dikonfigurasi saat node digunakan dalam klaster AKS. Untuk meminimalkan gangguan dan dampak potensial terhadap beban kerja berjalan, node tidak akan melakukan reboot secara otomatis jika patch keamanan atau pembaruan kernel memerlukan node tersebut. Untuk informasi selengkapnya tentang cara menangani reboot node, lihat Menerapkan pembaruan keamanan dan kernel ke node di AKS.

Peningkatan citra simpul

Peningkatan tanpa pengawasan menerapkan pembaruan ke OS node Linux, tetapi citra yang digunakan untuk membuat simpul untuk kluster Anda tetap tidak berubah. Jika simpul Linux baru ditambahkan ke kluster Anda, citra asli digunakan untuk membuat simpul. Simpul baru ini akan menerima semua pembaruan keamanan dan kernel yang tersedia selama pemeriksaan otomatis setiap malam tetapi akan tetap tidak ditampung hingga semua pemeriksaan dan proses hidupkan ulang selesai. Anda dapat menggunakan peningkatan gambar simpul untuk memeriksa dan memperbarui gambar simpul yang digunakan oleh klaster Anda. Untuk informasi selengkapnya tentang peningkatan gambar simpul, lihat Peningkatan gambar simpul Azure Kubernetes Service (AKS).

Memproses pembaruan simpul Windows Server

Untuk simpul Windows Server, lakukan operasi peningkatan gambar simpul secara teratur untuk menutup dan mengosongkan pod dengan aman serta menyebarkan simpul yang terbaru.