View a markdown version of this page

Keamanan Lapisan Pengangkutan (TLS) - AWS App Mesh
Persyaratan sertifikatSertifikat otentikasi TLSBagaimana App Mesh mengonfigurasi Utusan untuk menegosiasikan TLSVerifikasi enkripsiPerpanjangan sertifikatKonfigurasikan beban kerja Amazon ECS untuk menggunakan otentikasi TLS dengan AWS App MeshKonfigurasikan beban kerja Kubernetes untuk menggunakan otentikasi TLS dengan 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 Pengangkutan (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 selengkapnya, kunjungi posting blog ini Ber 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 diwakili di App Mesh oleh titik akhir mesh, seperti dan. Node virtual Gerbang virtual Proksi bernegosiasi dan mengakhiri TLS. Ketika proxy digunakan dengan aplikasi, kode aplikasi Anda tidak bertanggung jawab untuk menegosiasikan sesi TLS. Proksi menegosiasikan TLS atas nama aplikasi Anda.

App Mesh memungkinkan Anda untuk 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) melalui Socket Domain Unix lokal.

Otorisasi Proxy Utusanharus diaktifkan untuk proxy Utusan yang digunakan yang diwakili oleh titik akhir mesh. Sebaiknya jika Anda mengaktifkan otorisasi proxy, Anda membatasi akses hanya ke titik akhir mesh yang Anda aktifkan enkripsi.

Persyaratan sertifikat

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

  • DNS — Salah satu SAN sertifikat harus sesuai dengan nilai yang disediakan dalam pengaturan penemuan layanan DNS. 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 SAN sertifikat 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 NameSpaceNameapps.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 SAN sertifikat yang cocok dengan pengaturan penemuan layanan DNS, koneksi antara Utusan gagal dengan pesan kesalahan berikut, seperti yang terlihat dari Envoy klien. 

TLS error: 268435581:SSL routines:OPENSSL_internal:CERTIFICATE_VERIFY_FAILED

Sertifikat otentikasi TLS

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

AWS Private CA

Sertifikat harus disimpan di ACM di Wilayah dan AWS akun yang sama dengan titik akhir mesh yang akan menggunakan sertifikat. Sertifikat CA tidak perlu 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 AWS Private CA sudah ada, lihat Meminta Sertifikat Pribadi. Sertifikat tidak dapat menjadi sertifikat publik.

CA pribadi yang Anda gunakan untuk kebijakan klien TLS harus menjadi CA pengguna root.

Untuk mengonfigurasi node virtual dengan sertifikat dan CA 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 acm:DescribeCertificate izin.

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

penting

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

Anda dapat menambahkan izin ini ke kebijakan IAM yang ada yang dilampirkan ke prinsipal atau membuat prinsip dan kebijakan baru dan melampirkan kebijakan ke prinsipal. Untuk informasi selengkapnya, lihat Meng edit Kebijakan IAM, Membuat Kebijakan IAM, dan Menambahkan Izin Identi tas IAM.

catatan

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

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

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

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

Sistem file

Anda dapat mendistribusikan sertifikat ke Envoy 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 sidecar Envoy.

Layanan Penemuan Rahasia Utusan (SDS)

Envoy mengambil rahasia seperti sertifikat TLS dari titik akhir tertentu melalui protokol Penemuan Rahasia. Untuk informasi selengkapnya tentang protokol ini, lihat dokumentasi SDS Envoy.

App Mesh mengonfigurasi proxy Envoy untuk menggunakan Soket Domain Unix yang lokal untuk proxy untuk berfungsi sebagai titik akhir Secret Discovery Service (SDS) ketika SDS berfungsi sebagai sumber untuk 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 protokol V2 SDS menggunakan gRPC.

Mengintegrasikan dengan SPIFFE Runtime Environment (SPIRE)

Anda dapat menggunakan implementasi sidecar apa pun dari API SDS, termasuk toolchain yang ada seperti SPIFFE Runtime Environment (SPIRE). SPIRE dirancang untuk memungkinkan penyebaran otentikasi TLS bersama 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 berputar secara otomatis langsung ke beban kerja.

Anda harus mengonfigurasi SPIRE Agen sebagai penyedia SDS untuk Envoy. Izinkan untuk secara langsung memasok Envoy dengan materi kunci yang dibutuhkan untuk memberikan otentikasi TLS bersama. Jalankan SPIRE Agents di sidecars di samping 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 Envoy saat Envoy terhubung ke server SDS yang diekspos oleh Agen SPIRE.

Selama proses ini, identitas layanan dan sertifikat CA dirotasi, dan pembaruan dialirkan kembali ke Envoy. Envoy segera menerapkannya ke koneksi baru tanpa gangguan atau downtime dan tanpa kunci pribadi 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 antar 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 terminasi TLS, TLS tidak akan dinegosiasikan antara proxy. Jika klien belum menentukan kebijakan klien yang cocok, dan server telah dikonfigurasi dengan mode TLS STRICT atauPERMISSIVE, proxy akan dikonfigurasi untuk menegosiasikan TLS. Bergantung pada bagaimana sertifikat telah diberikan untuk penghentian TLS, perilaku tambahan berikut berlaku.

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

  • File-based Sertifikat TLS — Ketika server telah mengkonfigurasi terminasi 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 (SAN) untuk dipercaya. SAN harus dalam format FQDN atau URI. Jika SAN disediakan, Envoy memverifikasi bahwa Nama Alternatif Subjek dari sertifikat yang disajikan cocok dengan salah satu nama dalam daftar ini.

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

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

penting

Anda hanya dapat menggunakan SAN wildcard jika kebijakan klien untuk TLS disetel ke. not enforced Jika kebijakan klien untuk node virtual klien atau gateway virtual dikonfigurasi untuk menerapkan TLS, maka tidak dapat menerima SAN wildcard.

Verifikasi enkripsi

Setelah mengaktifkan TLS, Anda dapat menanyakan proxy Envoy untuk mengonfirmasi bahwa komunikasi dienkripsi. Proksi Utusan memancarkan statistik sumber daya yang dapat membantu Anda memahami apakah komunikasi TLS berfungsi dengan baik. Misalnya, proxy Envoy mencatat statistik jumlah jabat tangan TLS yang berhasil yang telah dinegosiasikan untuk titik akhir mesh tertentu. Tentukan berapa banyak jabat tangan TLS yang berhasil untuk titik akhir mesh yang dinamai my-mesh-endpoint dengan perintah berikut.

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

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

listener.0.0.0.0_15000.ssl.handshake: 3

Proksi 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: 0

Untuk informasi selengkapnya tentang statistik TLS Envoy, lihat Statistik Pendengar U tusan.

Perpanjangan sertifikat

AWS Private CA

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

Sertifikat Anda sendiri

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

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 sidecar 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 sidecar Envoy Anda. Pastikan bahwa jalur ke sertifikat dan kunci pribadi cocok dengan yang dikonfigurasi AWS App Mesh.

  • Jika Anda menggunakan SDS-based distribusi, tambahkan sidecar yang mengimplementasikan API SDS 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 for Kubernetes untuk mengaktifkan otentikasi TLS untuk simpul virtual dan backend layanan gateway virtual dan pendengar. 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 dari Mutual TLS Authentication.

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

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

    --set sds.enabled=true
catatan

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