Keamanan Lapisan Transportasi (TLS) - AWS App Mesh
Persyaratan sertifikatTLSsertifikat otentikasiBagaimana App Mesh mengonfigurasi Utusan untuk bernegosiasi TLSVerifikasi enkripsiPerpanjangan sertifikatKonfigurasikan ECS beban kerja Amazon untuk menggunakan TLS otentikasi dengan AWS App MeshKonfigurasikan beban kerja Kubernetes untuk menggunakan otentikasi dengan TLS AWS App Mesh

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

Keamanan Lapisan Transportasi (TLS)

penting

Pemberitahuan akhir dukungan: Pada 30 September 2026, AWS akan menghentikan dukungan untuk. AWS App Mesh Setelah 30 September 2026, Anda tidak akan lagi dapat mengakses AWS App Mesh konsol atau AWS App Mesh sumber daya. Untuk informasi lebih lanjut, kunjungi posting blog ini Migrasi dari AWS App Mesh ke Amazon ECS Service Connect.

Di App Mesh, Transport Layer Security (TLS) mengenkripsi komunikasi antara proxy Envoy yang diterapkan pada sumber daya komputasi yang direpresentasikan di App Mesh oleh titik akhir mesh, seperti dan. Node virtual Gerbang virtual Proxy bernegosiasi dan mengakhiriTLS. Ketika proxy digunakan dengan aplikasi, kode aplikasi Anda tidak bertanggung jawab untuk menegosiasikan TLS sesi. Proxy bernegosiasi TLS atas nama aplikasi Anda.

App Mesh memungkinkan Anda memberikan TLS sertifikat ke proxy dengan cara berikut:

  • Sertifikat pribadi dari AWS Certificate Manager (ACM) yang dikeluarkan oleh AWS Private Certificate Authority (AWS Private CA).

  • Sertifikat yang disimpan pada sistem file lokal dari node virtual yang dikeluarkan oleh otoritas sertifikat (CA) Anda sendiri

  • Sertifikat yang disediakan oleh titik akhir Secrets Discovery Service (SDS) di atas Unix Domain Socket lokal.

Otorisasi Proxy Utusanharus diaktifkan untuk proxy Utusan yang diterapkan yang diwakili oleh titik akhir mesh. Kami menyarankan bahwa ketika Anda mengaktifkan otorisasi proxy, Anda membatasi akses hanya ke titik akhir mesh yang Anda aktifkan enkripsi.

Persyaratan sertifikat

Salah satu Nama Alternatif Subjek (SANs) pada sertifikat harus sesuai dengan kriteria tertentu, tergantung pada bagaimana layanan aktual yang diwakili oleh titik akhir mesh ditemukan.

  • DNS— Salah satu sertifikat SANs harus sesuai dengan nilai yang diberikan dalam pengaturan penemuan DNS layanan. Untuk aplikasi dengan nama penemuan layananmesh-endpoint.apps.local, Anda dapat membuat sertifikat yang cocok dengan nama itu, atau sertifikat dengan kartu liar*.apps.local.

  • AWS Cloud Map— Salah satu sertifikat SANs harus sesuai dengan nilai yang diberikan dalam pengaturan penemuan AWS Cloud Map layanan menggunakan formatservice-name.namespace-name. Untuk aplikasi dengan pengaturan penemuan AWS Cloud Map layanan serviceName mesh-endpoint dan namespaceName apps.local, Anda dapat membuat sertifikat yang cocok dengan namamesh-endpoint.apps.local, atau sertifikat dengan kartu liar *.apps.local.

Untuk kedua mekanisme penemuan, jika tidak ada sertifikat yang SANs cocok dengan pengaturan penemuan DNS layanan, koneksi antara Utusan gagal dengan pesan kesalahan berikut, seperti yang terlihat dari Utusan klien. 

TLS error: 268435581:SSL routines:OPENSSL_internal:CERTIFICATE_VERIFY_FAILED

TLSsertifikat otentikasi

App Mesh mendukung beberapa sumber untuk sertifikat saat menggunakan TLS otentikasi.

AWS Private CA

Sertifikat harus disimpan ACM di Wilayah dan AWS akun yang sama dengan titik akhir mesh yang akan menggunakan sertifikat. Sertifikat CA tidak harus berada di AWS akun yang sama, tetapi masih harus berada di Wilayah yang sama dengan titik akhir mesh. Jika Anda tidak memiliki AWS Private CA, maka Anda harus membuatnya sebelum Anda dapat meminta sertifikat darinya. Untuk informasi selengkapnya tentang meminta sertifikat dari AWS Private CA penggunaan yang sudah adaACM, lihat Meminta Sertifikat Pribadi. Sertifikat tidak dapat berupa sertifikat publik.

Privat CAs yang Anda gunakan untuk kebijakan TLS klien harus pengguna rootCAs.

Untuk mengonfigurasi node virtual dengan sertifikat dan CAs dari AWS Private CA, prinsipal (seperti pengguna atau peran) yang Anda gunakan untuk memanggil App Mesh harus memiliki IAM izin berikut:

  • Untuk sertifikat apa pun yang Anda tambahkan ke TLS konfigurasi pendengar, kepala sekolah harus memiliki acm:DescribeCertificate izin.

  • Untuk setiap yang CAs dikonfigurasi pada kebijakan TLS klien, kepala sekolah harus memiliki acm-pca:DescribeCertificateAuthority izin.

penting

Berbagi CAs dengan akun lain dapat memberikan akun tersebut hak istimewa yang tidak diinginkan kepada CA. Sebaiknya gunakan kebijakan berbasis sumber daya untuk membatasi akses ke akun yang adil acm-pca:DescribeCertificateAuthority dan acm-pca:GetCertificateAuthorityCertificate untuk akun yang tidak perlu mengeluarkan sertifikat dari CA.

Anda dapat menambahkan izin ini ke IAM kebijakan yang sudah ada yang dilampirkan pada prinsipal atau membuat prinsipal dan kebijakan baru dan melampirkan kebijakan tersebut ke prinsipal. Untuk informasi selengkapnya, lihat Mengedit IAM Kebijakan, Membuat IAM Kebijakan, dan Menambahkan IAM Izin Identitas.

catatan

Anda membayar biaya bulanan untuk pengoperasian masing-masing AWS Private CA sampai Anda menghapusnya. Anda juga membayar sertifikat pribadi yang Anda terbitkan setiap bulan dan sertifikat pribadi yang Anda ekspor. Untuk informasi selengkapnya, silakan lihat Harga AWS Certificate Manager.

Saat Anda mengaktifkan otorisasi proxy untuk Proxy Utusan yang diwakili oleh titik akhir mesh, IAM peran yang Anda gunakan harus diberi izin berikut: IAM

  • Untuk sertifikat apa pun yang dikonfigurasi pada pendengar node virtual, peran harus memiliki acm:ExportCertificate izin.

  • Untuk setiap yang CAs dikonfigurasi pada kebijakan TLS klien, peran harus memiliki acm-pca:GetCertificateAuthorityCertificate izin.

Sistem file

Anda dapat mendistribusikan sertifikat ke Utusan menggunakan sistem file. Anda dapat melakukan ini dengan membuat rantai sertifikat dan kunci pribadi yang sesuai tersedia di jalur file. Dengan begitu, sumber daya ini dapat dijangkau dari proxy sespan Utusan.

Layanan Penemuan Rahasia Utusan () SDS

Utusan mengambil rahasia seperti TLS sertifikat dari titik akhir tertentu melalui protokol Secrets Discovery. Untuk informasi selengkapnya tentang protokol ini, lihat dokumentasi Utusan. SDS

App Mesh mengonfigurasi proxy Envoy untuk menggunakan Unix Domain Socket yang lokal ke proxy untuk berfungsi sebagai titik akhir Secret Discovery Service (SDS) saat SDS berfungsi sebagai sumber sertifikat dan rantai sertifikat Anda. Anda dapat mengonfigurasi jalur ke titik akhir ini dengan menggunakan variabel APPMESH_SDS_SOCKET_PATH lingkungan.

penting

Layanan Penemuan Rahasia Lokal menggunakan Unix Domain Socket didukung pada proxy App Mesh Envoy versi 1.15.1.0 dan yang lebih baru.

App Mesh mendukung SDS protokol V2 menggunakan gRPC.

Integrasi dengan SPIFFE Runtime Environment () SPIRE

Anda dapat menggunakan implementasi sespan apa pun SDSAPI, termasuk rantai alat yang ada seperti SPIFFERuntime Environment (). SPIRE SPIREdirancang untuk memungkinkan penyebaran TLS otentikasi timbal balik antara beberapa beban kerja dalam sistem terdistribusi. Ini membuktikan identitas beban kerja saat runtime. SPIREjuga memberikan kunci dan sertifikat khusus beban kerja, berumur pendek, dan secara otomatis berputar langsung ke beban kerja.

Anda harus mengonfigurasi SPIRE Agen sebagai SDS penyedia untuk Utusan. Izinkan untuk secara langsung memasok Utusan dengan materi utama yang dibutuhkan untuk memberikan otentikasi timbal balikTLS. Jalankan SPIRE Agen di sidecars di sebelah proxy Utusan. Agen menangani pembuatan kembali kunci dan sertifikat berumur pendek sesuai kebutuhan. Agen membuktikan Utusan dan menentukan identitas layanan dan sertifikat CA mana yang harus disediakan untuk Utusan saat Utusan terhubung ke server yang diekspos oleh Agen. SDS SPIRE

Selama proses ini, identitas layanan dan sertifikat CA diputar, dan pembaruan dialirkan kembali ke Envoy. Utusan segera menerapkannya ke koneksi baru tanpa gangguan atau downtime dan tanpa kunci pribadi yang pernah menyentuh sistem file.

Bagaimana App Mesh mengonfigurasi Utusan untuk bernegosiasi TLS

App Mesh menggunakan konfigurasi titik akhir mesh dari klien dan server saat menentukan cara mengonfigurasi komunikasi antara Utusan dalam mesh.

Dengan kebijakan klien

Ketika kebijakan klien menerapkan penggunaanTLS, dan salah satu port dalam kebijakan klien cocok dengan port kebijakan server, kebijakan klien digunakan untuk mengonfigurasi konteks TLS validasi klien. Misalnya, jika kebijakan klien gateway virtual cocok dengan kebijakan server node virtual, TLS negosiasi akan dilakukan antara proxy menggunakan pengaturan yang ditentukan dalam kebijakan klien gateway virtual. Jika kebijakan klien tidak cocok dengan port kebijakan server, TLS antara proxy mungkin atau mungkin tidak dinegosiasikan, tergantung pada pengaturan kebijakan server. TLS

Tanpa kebijakan klien

Jika klien belum mengonfigurasi kebijakan klien, atau kebijakan klien tidak cocok dengan port server, App Mesh akan menggunakan server untuk menentukan apakah akan bernegosiasi TLS dari klien atau tidak, dan bagaimana caranya. Misalnya, jika gateway virtual belum menentukan kebijakan klien, dan node virtual belum mengonfigurasi TLS penghentian, tidak TLS akan dinegosiasikan antara proxy. Jika klien belum menentukan kebijakan klien yang cocok, dan server telah dikonfigurasi dengan TLS mode STRICT atauPERMISSIVE, proxy akan dikonfigurasi untuk bernegosiasi. TLS Bergantung pada bagaimana sertifikat telah diberikan untuk TLS penghentian, perilaku tambahan berikut berlaku.

  • ACMTLS-sertifikat terkelola — Ketika server telah mengonfigurasi TLS penghentian menggunakan sertifikat yang ACM dikelola, App Mesh secara otomatis mengonfigurasi klien untuk menegosiasikan TLS dan memvalidasi sertifikat terhadap CA pengguna root yang dirantai oleh sertifikat tersebut.

  • TLSSertifikat berbasis file — Ketika server telah mengonfigurasi TLS penghentian menggunakan sertifikat dari sistem file lokal proxy, App Mesh secara otomatis mengonfigurasi klien untuk bernegosiasiTLS, tetapi sertifikat server tidak divalidasi.

Nama alternatif subjek

Anda dapat secara opsional menentukan daftar Nama Alternatif Subjek (SANs) untuk dipercaya. SANsharus dalam URI format FQDN atau. Jika SANs disediakan, Utusan memverifikasi bahwa Nama Alternatif Subjek dari sertifikat yang disajikan cocok dengan salah satu nama dalam daftar ini.

Jika Anda tidak menentukan SANs titik akhir mesh terminating, proxy Envoy untuk node tersebut tidak memverifikasi sertifikat klien SAN rekan. Jika Anda tidak menentukan SANs titik akhir mesh asal, sertifikat yang disediakan oleh titik akhir akhir harus cocok dengan konfigurasi penemuan layanan titik akhir mesh. SAN

Untuk informasi selengkapnya, lihat App Mesh TLS: Persyaratan sertifikat.

penting

Anda hanya dapat menggunakan wildcard SANs jika kebijakan klien TLS disetel kenot enforced. Jika kebijakan klien untuk node virtual klien atau gateway virtual dikonfigurasi untuk diterapkanTLS, maka kebijakan klien tidak dapat menerima wildcardSAN.

Verifikasi enkripsi

Setelah Anda mengaktifkanTLS, Anda dapat meminta proxy Envoy untuk mengonfirmasi bahwa komunikasi dienkripsi. Proxy utusan memancarkan statistik tentang sumber daya yang dapat membantu Anda memahami apakah TLS komunikasi Anda berfungsi dengan baik. Misalnya, proxy Envoy mencatat statistik tentang jumlah TLS jabat tangan yang berhasil dinegosiasikan untuk titik akhir mesh tertentu. Tentukan berapa banyak TLS jabat tangan yang berhasil ada untuk titik akhir mesh bernama my-mesh-endpoint dengan perintah berikut.

curl -s 'http://my-mesh-endpoint.apps.local:9901/stats' | grep ssl.handshake

Dalam contoh berikut mengembalikan output, ada tiga jabat tangan untuk titik akhir mesh, sehingga komunikasi dienkripsi.

listener.0.0.0.0_15000.ssl.handshake: 3

Proxy utusan juga mengeluarkan statistik ketika TLS negosiasi gagal. Tentukan apakah ada TLS kesalahan untuk titik akhir mesh.

curl -s 'http://my-mesh-endpoint.apps.local:9901/stats' | grep -e "ssl.*\(fail\|error\)"

Dalam contoh output yang dikembalikan, tidak ada kesalahan untuk beberapa statistik, sehingga TLS negosiasi berhasil.

listener.0.0.0.0_15000.ssl.connection_error: 0
listener.0.0.0.0_15000.ssl.fail_verify_cert_hash: 0
listener.0.0.0.0_15000.ssl.fail_verify_error: 0
listener.0.0.0.0_15000.ssl.fail_verify_no_cert: 0
listener.0.0.0.0_15000.ssl.ssl.fail_verify_san: 0

Untuk informasi selengkapnya tentang statistik Utusan, lihat TLS Statistik Pendengar Utusan.

Perpanjangan sertifikat

AWS Private CA

Saat Anda memperbarui sertifikatACM, sertifikat yang diperbarui akan didistribusikan secara otomatis ke proxy Anda yang terhubung dalam waktu 35 menit setelah perpanjangan selesai. Sebaiknya gunakan perpanjangan terkelola untuk memperbarui sertifikat secara otomatis mendekati akhir masa berlakunya. Untuk informasi selengkapnya, lihat Pembaruan Terkelola untuk Sertifikat ACM yang Diterbitkan Amazon di Panduan Pengguna. AWS Certificate Manager

Sertifikat Anda sendiri

Saat menggunakan sertifikat dari sistem file lokal, Utusan tidak akan memuat ulang sertifikat secara otomatis saat berubah. Anda dapat memulai ulang atau menerapkan kembali proses Utusan untuk memuat sertifikat baru. Anda juga dapat menempatkan sertifikat yang lebih baru di jalur file yang berbeda dan memperbarui node virtual atau konfigurasi gateway dengan jalur file tersebut.

Konfigurasikan ECS beban kerja Amazon untuk menggunakan TLS otentikasi dengan AWS App Mesh

Anda dapat mengonfigurasi mesh Anda untuk menggunakan TLS otentikasi. Pastikan sertifikat tersedia untuk sidecar proxy Envoy yang Anda tambahkan ke beban kerja Anda. Anda dapat melampirkan EBS atau EFS volume ke sespan Envoy Anda, atau Anda dapat menyimpan dan mengambil sertifikat dari Secrets Manager. AWS

  • Jika Anda menggunakan distribusi sertifikat berbasis file, lampirkan EBS atau EFS volume ke sespan Envoy Anda. Pastikan jalur ke sertifikat dan kunci pribadi cocok dengan yang dikonfigurasi AWS App Mesh.

  • Jika Anda menggunakan distribusi SDS berbasis, tambahkan sespan yang mengimplementasikan Envoy SDS API dengan akses ke sertifikat.

catatan

SPIREtidak didukung di AmazonECS.

Konfigurasikan beban kerja Kubernetes untuk menggunakan otentikasi dengan TLS AWS App Mesh

Anda dapat mengonfigurasi AWS App Mesh Controller untuk Kubernetes untuk mengaktifkan TLS otentikasi untuk backend dan pendengar layanan virtual node dan gateway virtual. Pastikan sertifikat tersedia untuk sidecar proxy Envoy yang Anda tambahkan ke beban kerja Anda. Anda dapat melihat contoh untuk setiap jenis distribusi di bagian panduan Mutual TLS Authentication.

  • Jika Anda menggunakan distribusi sertifikat berbasis file, lampirkan EBS atau EFS volume ke sespan Envoy Anda. Pastikan jalur ke sertifikat dan kunci pribadi cocok dengan yang dikonfigurasi di pengontrol. Atau, Anda dapat menggunakan Kubernetes Secret yang dipasang pada sistem file.

  • Jika Anda menggunakan distribusi SDS berbasis, Anda harus menyiapkan SDS penyedia lokal node yang mengimplementasikan Envoy's. SDS API Utusan akan mencapainya. UDS Untuk mengaktifkan TLS dukungan m SDS berbasis di EKS AppMesh pengontrol, setel enable-sds flag ke true dan berikan UDS jalur SDS penyedia lokal ke pengontrol melalui sds-uds-path flag. Jika Anda menggunakan helm, Anda mengatur ini sebagai bagian dari instalasi controller Anda: 

    --set sds.enabled=true
catatan

Anda tidak akan dapat menggunakannya SPIRE untuk mendistribusikan sertifikat Anda jika Anda menggunakan Amazon Elastic Kubernetes Service (EKSAmazon) dalam mode Fargate.