Rekomendasi konfigurasi API endpoint

Komunikasi API internal

OpenStack menyediakan endpoint API yang dihadapi publik maupun pribadi. Secara default, komponen OpenStack menggunakan endpoint yang ditentukan secara umum. Rekomendasinya adalah mengkonfigurasi komponen ini untuk menggunakan endpoint API dalam domain keamanan yang tepat.

Layanan memilih endpoints API masing-masing berdasarkan katalog layanan OpenStack. Layanan ini mungkin tidak mematuhi nilai endpoints API publik atau internal yang terdaftar. Hal ini dapat menyebabkan lalu lintas manajemen internal diarahkan ke endpoints API eksternal.

Konfigurasikan URL internal dalam katalog layanan Identitas

Katalog layanan identitas harus mengetahui URL internal Anda. Sementara fitur ini tidak digunakan secara default, mungkin leveraged melalui konfigurasi. Selain itu, harus kompatibel dengan perubahan yang harus dilakukan jika perilaku ini menjadi default.

Untuk mendaftarkan URL internal untuk endpoint:

$ openstack endpoint create identity \
  --region RegionOne internal \
  https://MANAGEMENT_IP:5000/v3

Ganti `` MANAGEMENT_IP`` dengan alamat IP manajemen dari node controller Anda.

Konfigurasikan aplikasi untuk URL internal

Anda dapat memaksa beberapa layanan untuk menggunakan endpoint API yang spesifik. Oleh karena itu, disarankan agar setiap layanan OpenStack berkomunikasi dengan API dari layanan lain harus dikonfigurasi secara eksplisit untuk mengakses endpoint API internal yang benar.

Setiap proyek dapat menunjukkan cara yang tidak konsisten untuk menentukan endpoint API target. Rilis OpenStack di masa depan berusaha untuk mengatasi ketidakkonsistenan ini melalui penggunaan katalog layanan Identitas secara konsisten.

Contoh konfigurasi #1: nova

cinder_catalog_info='volume:cinder:internalURL'
glance_protocol='https'
neutron_url='https://neutron-host:9696'
neutron_admin_auth_url='https://neutron-host:9696'
s3_host='s3-host'
s3_use_ssl=True

Contoh konfigurasi #2: cinder

glance_host = 'https://glance-server'

Tempel dan middleware

Sebagian besar endpoint API dan layanan HTTP lainnya di OpenStack menggunakan pustaka Python Paste Deploy. Dari perspektif keamanan, perpustakaan ini memungkinkan manipulasi aliran filter permintaan melalui konfigurasi aplikasi. Setiap elemen dalam rantai ini disebut sebagai *middleware *. Mengubah urutan filter dalam pipa atau menambahkan middleware tambahan mungkin memiliki dampak keamanan yang tidak dapat diprediksi.

Umumnya, pelaksana menambahkan middleware untuk memperluas fungsionalitas dasar OpenStack. Sebaiknya pelaksana membuat pertimbangan cermat terhadap paparan potensial yang diperkenalkan oleh penambahan komponen perangkat lunak non-standar ke pipeline permintaan HTTP mereka.

Untuk informasi lebih lanjut tentang Paste Deploy, lihat Python Paste Deployment documentation.

Isolasi dan kebijakan proses endpoint API

Anda harus mengisolasi proses endpoint API, terutama yang berada di dalam domain keamanan publik harus diisolasi sebanyak mungkin. Bila pengerahan memungkinkan, endpoint API harus dipasang di host terpisah untuk peningkatan isolasi.

Namespace

Banyak sistem operasi sekarang menyediakan dukungan kompartementalisasi. Linux mendukung namespace untuk menetapkan proses ke dalam domain independen. Bagian lain dari panduan ini mencakup kompartementalisasi sistem secara lebih rinci.

Kebijakan jaringan

Karena endpoint API biasanya menjembatani beberapa domain keamanan, Anda harus memberi perhatian khusus pada kompartementalisasi proses API. Lihat: ref: Bridging_security_domains untuk informasi tambahan di area ini.

Dengan pemodelan yang cermat, Anda dapat menggunakan teknologi ACL dan IDS jaringan untuk menerapkan komunikasi point to talk secara eksplisit antara layanan jaringan. Sebagai layanan lintas domain yang kritis, jenis penegakan eksplisit ini bekerja dengan baik untuk layanan antrian pesan OpenStack.

Untuk menerapkan kebijakan, Anda dapat mengonfigurasi layanan, firewall berbasis host (seperti iptables), kebijakan lokal (SELinux atau AppArmor), dan kebijakan jaringan global pilihan.

Kontrol akses wajib (Mandatory Access Control)

Anda harus mengisolasi proses endpoint API satu sama lain dan proses lainnya pada mesin. Konfigurasi untuk proses tersebut harus dibatasi pada proses-proses tersebut tidak hanya oleh Discretionary Access Controls, namun melalui Mandatory Access Control. Tujuan dari kontrol akses yang disempurnakan ini adalah untuk membantu penahanan dan eskalasi pelanggaran keamanan endpoint API. Dengan kontrol akses wajib, pelanggaran tersebut sangat membatasi akses terhadap sumber daya dan memberikan peringatan sebelumnya mengenai kejadian tersebut.

API endpoint rate-limiting

Rate Limiting adalah sarana untuk mengontrol frekuensi kejadian yang diterima oleh aplikasi berbasis jaringan. Bila pembatas laju yang kuat tidak ada, hal itu dapat mengakibatkan aplikasi menjadi rentan terhadap berbagai penolakan serangan layanan. Hal ini terutama berlaku untuk API, yang menurut sifatnya dirancang untuk menerima frekuensi permintaan dan jenis permintaan yang sama.

Dalam OpenStack, disarankan agar semua endpoint, terutama publik, dilengkapi dengan lapisan perlindungan ekstra, dengan menggunakan proxy rate-limiting atau firewall aplikasi web.

Adalah kunci bahwa operator dengan hati-hati merencanakan dan mempertimbangkan kebutuhan kinerja individual pengguna dan layanan di dalam awan OpenStack mereka saat mengkonfigurasi dan menerapkan fungsi rate limiting.

Solusi umum untuk memberikan rate-limiting adalah Nginx, HAProxy, OpenRepose, atau Modul Apache seperti mod_ratelimit, mod_qos, atau mod_security.