Otentikasi TLS timbal balik - AWS App Mesh
Sertifikat otentikasi TLS timbal balikKonfigurasikan titik akhir meshMigrasikan layanan ke otentikasi TLS bersamaMemverifikasi otentikasi TLS timbal balikPanduan otentikasi TLS timbal balik App Mesh

Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Otentikasi TLS timbal balik

Otentikasi Mutual TLS (Transport Layer Security) adalah komponen opsional TLS yang menawarkan otentikasi peer dua arah. Mutual TLS otentikasi menambahkan lapisan keamanan melalui TLS dan memungkinkan layanan Anda untuk memverifikasi klien yang membuat koneksi.

Klien dalam hubungan client-server juga menyediakan sertifikat X.509 selama proses negosiasi sesi. Server menggunakan sertifikat ini untuk mengidentifikasi dan mengotentikasi klien. Proses ini membantu memverifikasi apakah sertifikat dikeluarkan oleh otoritas sertifikat tepercaya (CA) dan apakah sertifikat tersebut adalah sertifikat yang valid. Ini juga menggunakan Nama Alternatif Subjek (SAN) pada sertifikat untuk mengidentifikasi klien.

Anda dapat mengaktifkan otentikasi TLS timbal balik untuk semua protokol yang didukung oleh. AWS App Mesh Mereka adalah TCP, HTTP/1.1, HTTP/2, gRPC.

catatan

Menggunakan App Mesh, Anda dapat mengonfigurasi otentikasi TLS timbal balik untuk komunikasi antara proxy Utusan dari layanan Anda. Namun, komunikasi antara aplikasi Anda dan proxy Utusan tidak terenkripsi.

Sertifikat otentikasi TLS timbal balik

AWS App Mesh mendukung dua sumber sertifikat yang mungkin untuk otentikasi TLS timbal balik. Sertifikat klien dalam Kebijakan Klien TLS dan validasi server dalam konfigurasi TLS pendengar dapat bersumber dari:

  • Sistem File— Sertifikat dari sistem file lokal proxy Utusan yang sedang dijalankan. Untuk mendistribusikan sertifikat ke Envoy, Anda harus menyediakan jalur file untuk rantai sertifikat dan kunci pribadi ke App Mesh API.

  • Envoy's Secret Discovery Service (SDS) — B ring-your-own sidecars yang menerapkan SDS dan memungkinkan sertifikat dikirim ke Envoy. Mereka termasuk SPIFFE Runtime Environment (SPIRE).

penting

App Mesh tidak menyimpan sertifikat atau kunci pribadi yang digunakan untuk otentikasi TLS bersama. Sebaliknya, Utusan menyimpannya dalam memori.

Konfigurasikan titik akhir mesh

Konfigurasikan otentikasi TLS timbal balik untuk titik akhir mesh Anda, seperti node virtual atau gateway. Titik akhir ini memberikan sertifikat dan menentukan otoritas tepercaya.

Untuk melakukan ini, Anda perlu menyediakan sertifikat X.509 untuk klien dan server, dan secara eksplisit mendefinisikan sertifikat otoritas tepercaya dalam konteks validasi penghentian TLS dan originasi TLS.

Percaya di dalam jala

Sertifikat sisi server dikonfigurasi dalam pendengar Virtual Node (penghentian TLS), dan sertifikat sisi klien dikonfigurasi dalam backend layanan Virtual Nodes (originasi TLS). Sebagai alternatif untuk konfigurasi ini, Anda dapat menentukan kebijakan klien default untuk semua layanan backend dari node virtual, dan kemudian, jika diperlukan, Anda dapat mengganti kebijakan ini untuk backend tertentu sesuai kebutuhan. Virtual Gateways hanya dapat dikonfigurasi dengan kebijakan klien default yang berlaku untuk semua backend-nya.

Anda dapat mengonfigurasi kepercayaan di berbagai jerat dengan mengaktifkan otentikasi TLS timbal balik untuk lalu lintas masuk di Gateway Virtual untuk kedua jerat.

Percaya di luar jaring

Tentukan sertifikat sisi server di pendengar Virtual Gateway untuk penghentian TLS. Konfigurasikan layanan eksternal yang berkomunikasi dengan Virtual Gateway Anda untuk menyajikan sertifikat sisi klien. Sertifikat harus berasal dari salah satu otoritas sertifikat (CA) yang sama yang digunakan sertifikat sisi server pada pendengar Virtual Gateway untuk originasi TLS.

Migrasikan layanan ke otentikasi TLS bersama

Ikuti panduan ini untuk menjaga konektivitas saat memigrasikan layanan yang ada dalam App Mesh ke autentikasi TLS bersama.

Migrasi layanan yang berkomunikasi melalui plaintext

  1. Aktifkan PERMISSIVE mode untuk konfigurasi TLS pada titik akhir server. Mode ini memungkinkan lalu lintas teks biasa untuk terhubung ke titik akhir.

  2. Konfigurasikan otentikasi TLS timbal balik di server Anda, tentukan sertifikat server, rantai kepercayaan, dan secara opsional SAN tepercaya.

  3. Konfirmasikan komunikasi terjadi melalui koneksi TLS.

  4. Konfigurasikan otentikasi TLS timbal balik pada klien Anda, tentukan sertifikat klien, rantai kepercayaan, dan secara opsional SAN tepercaya.

  5. Aktifkan STRICT mode untuk konfigurasi TLS di server.

Migrasi layanan yang berkomunikasi melalui TLS

  1. Konfigurasikan pengaturan TLS timbal balik pada klien Anda, tentukan sertifikat klien dan secara opsional SAN tepercaya. Sertifikat klien tidak dikirim ke backend sampai setelah server backend memintanya.

  2. Konfigurasikan pengaturan TLS timbal balik di server Anda, tentukan rantai kepercayaan dan secara opsional SAN tepercaya. Untuk ini, server Anda meminta sertifikat klien.

Memverifikasi otentikasi TLS timbal balik

Anda dapat merujuk ke dokumentasi Transport Layer Security: Verify encryption untuk melihat bagaimana tepatnya Envoy memancarkan statistik terkait TLS. Untuk otentikasi TLS timbal balik, Anda harus memeriksa statistik berikut:

  • ssl.handshake

  • ssl.no_certificate

  • ssl.fail_verify_no_cert

  • ssl.fail_verify_san

Dua contoh statistik berikut bersama-sama menunjukkan bahwa koneksi TLS yang berhasil berakhir ke node virtual semuanya berasal dari klien yang memberikan sertifikat.

listener.0.0.0.0_15000.ssl.handshake: 3
listener.0.0.0.0_15000.ssl.no_certificate: 0

Contoh statistik berikutnya menunjukkan bahwa koneksi dari node klien virtual (atau gateway) ke node virtual backend gagal. Nama Alternatif Subjek (SAN) yang disajikan dalam sertifikat server tidak cocok dengan SAN mana pun yang dipercaya oleh klien.

cluster.cds_egress_my-mesh_my-backend-node_http_9080.ssl.fail_verify_san: 5

Panduan otentikasi TLS timbal balik App Mesh