Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
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 digunakan pada sumber daya komputasi yang direpresentasikan dalam App Mesh oleh titik akhir mesh, seperti dan. Node virtual Gerbang virtual Proxy menegosiasikan dan mengakhiri TLS. Ketika proxy digunakan dengan aplikasi, kode aplikasi Anda tidak bertanggung jawab untuk menegosiasikan sesi TLS. Proxy menegosiasikan TLS atas nama aplikasi Anda.
App Mesh memungkinkan Anda memberikan sertifikat TLS 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 layanan DNS. Untuk aplikasi dengan nama penemuan layanan
mesh-endpoint.apps.local*..apps.local -
AWS Cloud Map— Salah satu sertifikat SANs harus sesuai dengan nilai yang diberikan dalam pengaturan penemuan AWS Cloud Map layanan menggunakan format
service-name.namespace-namemesh-endpointapps.localmesh-endpoint.apps.local*.apps.local.
Untuk kedua mekanisme penemuan, jika tidak ada sertifikat yang SANs cocok dengan pengaturan penemuan layanan DNS, koneksi antara Utusan gagal dengan pesan galat berikut, seperti yang terlihat dari Utusan klien.
TLS error: 268435581:SSL routines:OPENSSL_internal:CERTIFICATE_VERIFY_FAILEDSertifikat otentikasi TLS
App Mesh mendukung beberapa sumber untuk sertifikat saat menggunakan otentikasi TLS.
- AWS Private CA
-
Sertifikat harus disimpan di ACM di Wilayah yang sama dan AWS akun sebagai 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 ACM yang sudah ada AWS Private CA , lihat Meminta Sertifikat Pribadi. Sertifikat tidak dapat berupa sertifikat publik.
Privat CAs yang Anda gunakan untuk kebijakan klien TLS harus pengguna CAs root.
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 izin IAM berikut:
-
Untuk sertifikat apa pun yang Anda tambahkan ke konfigurasi TLS pendengar, kepala sekolah harus memiliki izin.
acm:DescribeCertificate -
Untuk setiap yang CAs dikonfigurasi pada kebijakan klien TLS, kepala sekolah harus memiliki
acm-pca:DescribeCertificateAuthorityizin.
penting
Berbagi CAs dengan akun lain dapat memberikan akun-akun tersebut hak istimewa yang tidak diinginkan kepada CA. Sebaiknya gunakan kebijakan berbasis sumber daya untuk membatasi akses ke akun yang adil
acm-pca:DescribeCertificateAuthoritydanacm-pca:GetCertificateAuthorityCertificateuntuk akun yang tidak perlu mengeluarkan sertifikat dari CA.Anda dapat menambahkan izin ini ke kebijakan IAM yang sudah ada yang dilampirkan pada prinsipal atau membuat prinsipal dan kebijakan baru dan melampirkan kebijakan tersebut ke prinsipal. Untuk informasi selengkapnya, lihat Mengedit Kebijakan IAM, Membuat Kebijakan IAM, dan Menambahkan Izin Identitas IAM.
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, peran IAM yang Anda gunakan harus diberi izin IAM berikut:
-
Untuk sertifikat apa pun yang dikonfigurasi pada pendengar node virtual, peran harus memiliki
acm:ExportCertificateizin. -
Untuk setiap yang CAs dikonfigurasi pada kebijakan klien TLS, peran harus memiliki
acm-pca:GetCertificateAuthorityCertificateizin.
-
- 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 sertifikat TLS dari titik akhir tertentu melalui protokol Secrets Discovery. Untuk informasi selengkapnya tentang protokol ini, lihat dokumentasi SDS
Envoy. 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_PATHlingkungan.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 protokol V2 SDS menggunakan gRPC.
- Mengintegrasikan dengan SPIFFE Runtime Environment (SPIRE)
-
Anda dapat menggunakan implementasi sidecar apa pun dari SDS API, termasuk toolchain yang ada seperti SPIFFE Runtime Environment (SPIRE)
. SPIRE dirancang untuk memungkinkan penyebaran otentikasi TLS timbal balik antara beberapa beban kerja dalam sistem terdistribusi. Ini membuktikan identitas beban kerja saat runtime. SPIRE juga memberikan kunci dan sertifikat khusus beban kerja, berumur pendek, dan otomatis berputar langsung ke beban kerja. Anda harus mengonfigurasi Agen SPIRE sebagai penyedia SDS untuk Utusan. Izinkan untuk secara langsung memasok Utusan dengan materi utama yang dibutuhkan untuk memberikan otentikasi TLS timbal balik. Jalankan SPIRE Agents 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 ketika Utusan terhubung ke server SDS yang diekspos oleh Agen 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 menegosiasikan 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 penggunaan TLS, dan salah satu port dalam kebijakan klien cocok dengan port kebijakan server, kebijakan klien digunakan untuk mengonfigurasi konteks validasi TLS klien. Misalnya, jika kebijakan klien gateway virtual cocok dengan kebijakan server node virtual, negosiasi TLS akan dicoba 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 TLS kebijakan server.
- 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 menegosiasikan TLS dari klien atau tidak, dan bagaimana caranya. Misalnya, jika gateway virtual belum menentukan kebijakan klien, dan node virtual belum mengonfigurasi penghentian TLS, TLS tidak akan dinegosiasikan antara proxy. Jika klien belum menentukan kebijakan klien yang cocok, dan server telah dikonfigurasi dengan mode TLS
STRICTatauPERMISSIVE, proxy akan dikonfigurasi untuk menegosiasikan TLS. Bergantung pada bagaimana sertifikat telah disediakan untuk penghentian TLS, perilaku tambahan berikut berlaku.-
Sertifikat TLS yang dikelola ACM — Ketika server telah mengonfigurasi penghentian TLS menggunakan sertifikat yang dikelola ACM, App Mesh secara otomatis mengonfigurasi klien untuk menegosiasikan TLS dan memvalidasi sertifikat terhadap CA pengguna root yang dirantai sertifikat tersebut.
-
Sertifikat TLS berbasis file — Ketika server telah mengonfigurasi penghentian TLS menggunakan sertifikat dari sistem file lokal proxy, App Mesh secara otomatis mengonfigurasi klien untuk menegosiasikan TLS, tetapi sertifikat server tidak divalidasi.
-
- Nama alternatif subjek
-
Anda dapat secara opsional menentukan daftar Nama Alternatif Subjek (SANs) untuk dipercaya. SANs harus dalam format FQDN atau URI. 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 SAN pada sertifikat klien rekan. Jika Anda tidak menentukan SANs titik akhir mesh asal, SAN pada sertifikat yang disediakan oleh titik akhir penghentian harus cocok dengan konfigurasi penemuan layanan titik akhir mesh.
Untuk informasi selengkapnya, lihat App Mesh TLS: Persyaratan sertifikat.
penting
Anda hanya dapat menggunakan wildcard SANs jika kebijakan klien untuk TLS disetel ke.
not enforcedJika kebijakan klien untuk node virtual klien atau gateway virtual dikonfigurasi untuk menerapkan TLS, maka kebijakan tersebut tidak dapat menerima wildcard SAN.
Verifikasi enkripsi
Setelah mengaktifkan TLS, Anda dapat menanyakan proxy Utusan untuk mengonfirmasi bahwa komunikasi dienkripsi. Proxy utusan memancarkan statistik tentang sumber daya yang dapat membantu Anda memahami apakah komunikasi TLS Anda berfungsi dengan baik. Misalnya, proxy Envoy mencatat statistik tentang jumlah jabat tangan TLS yang berhasil dinegosiasikan untuk titik akhir mesh tertentu. Tentukan berapa banyak jabat tangan TLS yang berhasil ada untuk titik akhir mesh bernama my-mesh-endpoint
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: 3Proxy utusan juga memancarkan statistik ketika negosiasi TLS gagal. Tentukan apakah ada kesalahan TLS 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 negosiasi TLS 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: 0Untuk informasi selengkapnya tentang statistik Envoy TLS, lihat Statistik Pendengar Utusan
Perpanjangan sertifikat
AWS Private CA
Saat Anda memperbarui sertifikat dengan ACM, 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 yang Diterbitkan Amazon ACM 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 beban kerja Amazon ECS untuk menggunakan otentikasi TLS dengan AWS App Mesh
Anda dapat mengonfigurasi mesh Anda untuk menggunakan otentikasi TLS. Pastikan sertifikat tersedia untuk sidecar proxy Envoy yang Anda tambahkan ke beban kerja Anda. Anda dapat melampirkan volume EBS atau EFS ke sespan Envoy Anda, atau Anda dapat menyimpan dan mengambil sertifikat dari Secrets Manager. AWS
-
Jika Anda menggunakan distribusi sertifikat berbasis file, lampirkan volume EBS atau EFS ke sespan Envoy Anda. Pastikan jalur ke sertifikat dan kunci pribadi cocok dengan yang dikonfigurasi AWS App Mesh.
-
Jika Anda menggunakan distribusi berbasis SDS, tambahkan sespan yang mengimplementasikan SDS API Envoy dengan akses ke sertifikat.
catatan
SPIRE tidak didukung di Amazon ECS.
Konfigurasikan beban kerja Kubernetes untuk menggunakan otentikasi TLS dengan AWS App Mesh
Anda dapat mengonfigurasi AWS App Mesh Controller untuk Kubernetes untuk mengaktifkan otentikasi TLS 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 volume EBS atau EFS 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 berbasis SDS, Anda harus menyiapkan penyedia SDS lokal node yang mengimplementasikan API SDS Envoy. Utusan akan mencapainya melalui UDS. Untuk mengaktifkan dukungan mTL berbasis SDS di AppMesh pengontrol EKS, atur
enable-sdsflag ketruedan berikan jalur UDS penyedia SDS lokal ke pengontrol melalui bendera.sds-uds-pathJika Anda menggunakan helm, Anda mengatur ini sebagai bagian dari instalasi controller Anda:--set sds.enabled=true
catatan
Anda tidak akan dapat menggunakan SPIRE untuk mendistribusikan sertifikat Anda jika Anda menggunakan Amazon Elastic Kubernetes Service (Amazon EKS) dalam mode Fargate.
