Mengamankan layanan jaringan OpenStack

Bagian ini membahas praktik terbaik konfigurasi OpenStack Networking saat mereka menerapkan keamanan jaringan proyek di dalam penyebaran OpenStack Anda.

Alur kerja layanan jaringan proyek

OpenStack Networking menyediakan pengguna layanan jaringan dan sumber daya jaringan. Adalah penting bahwa arsitek dan operator awan mengevaluasi kasus penggunaan desain mereka dalam memberikan pengguna kemampuan untuk membuat, memperbarui, dan menghancurkan sumber daya jaringan yang tersedia.

Mesin kebijakan sumber daya jaringan

Sebuah mesin kebijakan dan file konfigurasinya, policy.json, di dalam OpenStack Networking menyediakan metode untuk memberikan otorisasi pengguna yang lebih halus mengenai metode dan objek jaringan proyek. Definisi kebijakan OpenStack Networking mempengaruhi ketersediaan jaringan, keamanan jaringan dan keamanan OpenStack secara keseluruhan. Arsitek dan operator awan harus hati-hati mengevaluasi kebijakan mereka terhadap akses pengguna dan proyek untuk administrasi sumber daya jaringan. Untuk penjelasan lebih rinci tentang definisi kebijakan OpenStack Networking, lihat `Authentication and authorization section <https://docs.openstack.org/admin-guide/networking_auth.html> `__ di Panduan Administrator OpenStack.

Catatan

Penting untuk meninjau ulang kebijakan sumber daya jaringan default, karena kebijakan ini dapat diubah agar sesuai dengan postur keamanan Anda.

Jika penggelaran OpenStack Anda menyediakan beberapa jalur akses eksternal ke domain keamanan yang berbeda, penting bagi Anda untuk membatasi kemampuan proyek untuk menghubungkan beberapa vNIC ke beberapa access point eksternal - ini akan menjembatani domain keamanan ini dan dapat menyebabkan kompromi keamanan yang tak terduga. Hal ini dimungkinkan mengurangi risiko ini dengan memanfaatkan fungsi agregat host yang disediakan oleh OpenStack Compute atau melalui pemisahan proyek VM menjadi beberapa proyek dengan konfigurasi jaringan virtual yang berbeda.

Kelompok keamanan

Layanan OpenStack Networking menyediakan fungsionalitas kelompok keamanan dengan menggunakan mekanisme yang lebih fleksibel dan kuat daripada kemampuan kelompok keamanan yang ada di dalam OpenStack Compute. Dengan demikian, nova.conf harus selalu menonaktifkan grup keamanan bawaan dan proxy semua grup keamanan menghubungi OpenStack Networking API saat menggunakan OpenStack Networking. Kegagalan untuk melakukannya menghasilkan kebijakan keamanan yang saling bertentangan yang secara bersamaan diterapkan oleh kedua layanan tersebut. Untuk mengelompokkan grup keamanan ke OpenStack Networking, gunakan nilai konfigurasi berikut:

  • firewall_driver harus disetel ke nova.virt.firewall.NoopFirewallDriver sehingga nova-compute tidak melakukan penyaringan berbasis iptables itu sendiri.

  • security_group_api harus disetel ke neutron sehingga semua permintaan grup keamanan diproksikan ke layanan OpenStack Networking.

Grup keamanan adalah wadah untuk aturan kelompok keamanan. Grup keamanan dan peraturan mereka mengizinkan administrator dan memproyeksikan kemampuan untuk menentukan jenis lalu lintas dan arah (ingress/egress) yang diizinkan melewati port antarmuka virtual. Bila port antarmuka virtual dibuat di OpenStack Networking, ini terkait dengan grup keamanan. Untuk rincian lebih lanjut tentang perilaku grup keamanan port default, rujuk dokumentasi Networking Security Group Behavior. Aturan dapat ditambahkan ke grup keamanan default untuk mengubah perilaku berdasarkan per-penyebaran.

Saat menggunakan OpenStack Compute API untuk memodifikasi grup keamanan, grup keamanan yang diperbarui berlaku untuk semua port antarmuka virtual pada sebuah instance. Hal ini disebabkan API grup keamanan OpenStack Compute yang berbasis instance daripada berbasis port, seperti yang ditemukan di OpenStack Networking.

Kuota-kuota

Kuota memberikan kemampuan untuk membatasi jumlah sumber daya jaringan yang tersedia untuk proyek. Anda dapat menerapkan kuota default untuk semua proyek. The /etc/neutron/neutron.conf menyertakan opsi ini untuk kuota:

[QUOTAS]
# resource name(s) that are supported in quota features
quota_items = network,subnet,port

# default number of resource allowed per tenant, minus for unlimited
#default_quota = -1

# number of networks allowed per tenant, and minus means unlimited
quota_network = 10

# number of subnets allowed per tenant, and minus means unlimited
quota_subnet = 10

# number of ports allowed per tenant, and minus means unlimited
quota_port = 50

# number of security groups allowed per tenant, and minus means unlimited
quota_security_group = 10

# number of security group rules allowed per tenant, and minus means unlimited
quota_security_group_rule = 100

# default driver to use for quota checks
quota_driver = neutron.quota.ConfDriver

OpenStack Networking juga mendukung batas kuota per proyek melalui API ekstensi kuota. Untuk mengaktifkan kuota per proyek, Anda harus mengatur opsi quota_driver di neutron.conf.

quota_driver = neutron.db.quota.driver.DbQuotaDriver

Mengurangi spoofing ARP

Saat menggunakan jaringan flat (datar), Anda tidak dapat mengasumsikan bahwa proyek yang berbagi layer 2 network yang sama (atau broadcast domain) sepenuhnya terisolasi satu sama lain. Proyek ini mungkin rentan terhadap spoofing ARP, mempertaruhkan kemungkinan serangan man-in-the-middle.

Jika menggunakan versi Open vSwitch yang mendukung pencocokan ARP field, Anda dapat membantu mengurangi risiko ini dengan mengaktifkan opsi prevention_arp_spoofing untuk agen Open vSwitch. Pilihan ini mencegah terjadinya serangan spoof; itu tidak melindungi mereka dari serangan spoof. Perhatikan bahwa pengaturan ini diharapkan dapat dihapus di Ocata, dengan perilaku menjadi aktif secara permanen.

Misalnya, di /etc/neutron/plugins/ml2/openvswitch_agent.ini:

prevent_arp_spoofing = True

Plug-in selain Open vSwitch mungkin juga mencakup langkah-langkah mitigasi yang serupa; Sebaiknya aktifkan fitur ini, bila sesuai.

Catatan

Even dengan prevent_arp_spoofing diaktifkan, jaringan flat (datar) tidak menyediakan tingkat isolasi proyek yang lengkap, karena semua lalu lintas proyek masih dikirim ke VLAN yang sama.