Introduction
Kubernetes telah menjadi standar industri dalam mengelola container secara otomatis, baik untuk aplikasi skala kecil hingga infrastruktur enterprise berskala besar.
Namun, mengoperasikan Kubernetes bukan hanya sekadar menjalankan kubectl apply, melainkan juga memastikan bahwa cluster aman, stabil, dan siap produksi (production-ready).
Dalam praktik terbaik (best practice), ada beberapa aspek penting yang perlu diperhatikan: mulai dari keamanan infrastruktur, pengelolaan akses, manajemen workload, hingga pemantauan (monitoring) dan disaster recovery.
Tujuannya adalah agar Kubernetes dapat berjalan secara optimal tanpa membahayakan data dan layanan yang berjalan di atasnya.
Security Best Practice
1. Hardening OS for Kubernetes
Ini adalah layer utama dalam melakukan hardening sebelum kita melakukan hardening cluster. Bayangkan, kita sudah melakukan hardening cluster tetapi OS kita masih belum dilakukan hardening. Maka, attacker bisa langsung bypass ke dalam cluster. Saya sudah membuat postingan tentang hardening OS di Ubuntu. Kita bisa menggunakan acuan hardening berdasarkan postingan tersebut
2. Isolate Cluster and Network for Kubernetes
Untuk tahapan ini lebih cenderung jika kita menggunakan on-premise server. Jadi kita harus pisahkan cluster kubernetes dengan cluster lainnya dan menggunakan firewall.
3. Image Scanning
Beberapa celah keamanan saat proses build image
- Code berasal dari untrusted registries
- Terdapat virnerabilities pada tools dari OS atau Library (Bisa terdapat dari official container images)
- Hilangkan dependencies yang tidak digunakan (Lebih baik menggunakan base image seperti alpine)
Pada saat setelah kita building image, sebaiknya kita melakukan scanning image tersebut sebelum digunakan. Ada beberapa tools untuk image scanning, yaitu Trivy, Snyk, Sysdig, dll
Penggunaan image scanning lebih baik digunkan pada build CI/CD Pipeline
4. Run container as non-root
Pada saat kita menjalankan container, lebih baik kita menggunakan dedicated user dan group. Jadi ketika attacker bisa masuk ke container, dia tidak bisa masuk ke system lainnya karna akses terbatas. Konfigurasi ini kita bisa terapkan ketika kita build images.
Beberapa miss-configure yang dapat menyebabkan overwrite konfigurasi user (terdapat pada manifest kubernetes)
- securityContext.runAsUser: 0
- securityContext.allowPrivilegeEscalation: true
5. User & Permissions
Berikut standar user permsission yang ada pada kubernetes
- Authentication -> Siapa yang bisa akses (user dan aplikasi)
- Authorization -> Permission apa yang dia punya
Best Practice -> Kelola user dan permission (Buat privileges semakin ketat)
Didalam kubernetes, tidak ada user secara native, ada 3 metode untuk membuat user
- Menggunakan static token file
- Menggunakan sertifikat
- Menggunakan 3rd party Identity Service
Untuk aplikasi, kita bisa menggunakan ServiceAccount (Menggunakan token untuk auth ke API Server)
Best Practice -> Gunakan RBAC untuk memanage akses permission (Berikan akses seminimal mungkin)
6. Menggunakan Network Policy
Secara default, komunikasi antar pods allow all. Maka, harus dibatasi komunikasi antar Pods. Misalkan kita mempunyai Pods,
- Frontend
- Backend
- Database
Maka, frontend hanya bisa akses ke backend, backend bisa akses ke frontend dan database, database hanya bisa akses ke backend.
Didalam kubernetes, terdapat 2 level komunikasi
- NetworkPolicy -> menggunakan service (Standart dari kubernetes)
- ServiceMesh -> menggunakan proxy (Advance untuk hardening yang digunakan kubernetes)
7. Encrypt Communication
Secara default, komunikasi antar pods tidak di enkripsi. Untuk mengatasi itu, kita bisa menggunakan mTLS antar service yang melakukan encrypt internal communication.
Kita bisa menggunakan ServiceMesh seperti Istio dan mengaktifkan mTLS
8. Secure Secret Data
Secara default, secret data pada kubernetes hanya menggunakan encrypt base64 dan kita bisa decode dengan mudah.
Terdapat 2 solusi untuk mengatasi hal ini
- Menggunakan kubernetes solusi – yaitu melakukan enable enkripsi menggunakan EncryptionConfiguration resource (Tetap butuh untuk mengelola encryption key)
- Menggunakan 3rd party – Menggunakan metode ini lebih aman dan kita bisa menggunakan Vault HashiCorp
9. Secure ETCD
Semua konfigurasi kubernetes cluster disimpan dalam ETCD. Jika attacker mempuyai akses ke ETCD, ini berarti dia bisa bypass ke API Server dan mendapatkan unlimited access
Best Practice:
- Meletakan ETCD dibelakang firewall
- Encrypt ETCD data
10. Configure Security Policies
Penggunaan security policies akan memudahkan kita ketika ada tahapan sebelum deploy tidak mengikuti best practice, maka kita akan gagalkan proses deployment. Untuk konfigurasi sendiri kita bisa menggunakan automation dari pada kita menggunakan human resource. Ada beberapa tools yang kita bisa gunakan sebagai security policies
- Open Policy Agent
- Kyverno
11. Backup, Restore & Disaster Recovery
Best Practice untuk backup dan restore:
- Regularly backup data
- Store backup safely
- Be able to easily restore cluster
Ada tools yang direkomendasikan untuk tapahan awal backup yaitu Velero.
Kita tidak akan bisa melindungi cluster 100% dari attacker walaupun kita sudah menggunakan semua best practice security. Katakan cluster kita kacau balau dikarenakan 1 attacker, maka kita harus melakukan restore pada cluster tersebut.
Beberapa strategy dan mekanisme untuk disaster recovery
- Restore cluster menggunakan backup data
- Harus dalam waktu yang singkat
- Dengan minimal yang terdampak pada user experience
Beberapa untuk menjalankan Automated Disaster Recovery
- Idealnya, testing disaster recovery bisa berjalan
- Eksekusi menggunakan automation
- Testing recovery dengan planning yang baik
Conclusion
Setelah kita melakukan beberapa best practice, tentunya kita tidak bisa melindungi sistem kita 100%. Setidaknya kita bisa menyulitkan attacker dalam percobaan penyerangan dan akan membutuhkan waktu yang sangat lama untuk bisa menembus ke dalam cluster kita. Mungkin beberapa tahapan ada beberapa yang saya tidak bisa jabarkan lebih detail. Kedepannya akan saya buat postingan untuk penggunaan tools dan penggunaan best practicenya.
