Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
Mengkonfigurasi metode otentikasi cluster di Lambda
Lambda memerlukan izin untuk mengakses kluster MSK Amazon Anda, mengambil catatan, dan melakukan tugas lainnya. Amazon MSK mendukung beberapa cara untuk mengautentikasi dengan kluster MSK Anda.
Metode otentikasi cluster
Akses tidak diautentikasi
Jika tidak ada klien yang mengakses cluster melalui internet, Anda dapat menggunakan akses yang tidak diautentikasi.
Otentikasi SASL/SCRAM
Lambda mendukung otentikasi Simple Authentication and Security Layer/Salted Challenge Response Authentication Mechanism (SASL/SCRAM) otentikasi, dengan fungsi hash SHA-512 dan enkripsi Transport Layer Security (TLS). Agar Lambda dapat terhubung ke cluster, simpan kredensyal otentikasi (nama pengguna dan kata sandi) dalam rahasia Secrets Manager, dan rujuk rahasia ini saat mengonfigurasi pemetaan sumber peristiwa Anda.
Untuk informasi selengkapnya tentang menggunakan Secrets Manager, lihat Autentikasi kredensyal masuk dengan Secrets Manager di Amazon Managed Streaming for Apache Kafka Developer Guide.
catatan
Amazon MSK tidak mendukung SASL/PLAIN otentikasi.
Otentikasi TLS timbal balik
Mutual TLS (mTLS) menyediakan otentikasi dua arah antara klien dan server. Klien mengirimkan sertifikat ke server untuk server untuk memverifikasi klien. Server juga mengirimkan sertifikat ke klien untuk klien untuk memverifikasi server.
Untuk integrasi MSK Amazon dengan Lambda, kluster MSK Anda bertindak sebagai server, dan Lambda bertindak sebagai klien.
-
Agar Lambda memverifikasi klaster MSK Anda, Anda mengonfigurasi sertifikat klien sebagai rahasia di Secrets Manager, dan mereferensikan sertifikat ini dalam konfigurasi pemetaan sumber peristiwa Anda. Sertifikat klien harus ditandatangani oleh otoritas sertifikat (CA) di toko kepercayaan server.
-
Cluster MSK juga mengirimkan sertifikat server ke Lambda. Sertifikat server harus ditandatangani oleh otoritas sertifikat (CA) di toko AWS kepercayaan.
Amazon MSK tidak mendukung sertifikat server yang ditandatangani sendiri. Semua broker di Amazon MSK menggunakan sertifikat publik yang ditandatangani oleh Amazon Trust Services CAs
Rahasia CLIENT_CERTIFICATE_TLS_AUTH memerlukan bidang sertifikat dan bidang kunci pribadi. Untuk kunci pribadi terenkripsi, rahasianya memerlukan kata sandi kunci pribadi. Baik sertifikat dan kunci pribadi harus dalam format PEM.
catatan
Lambda mendukung PBES1
Bidang sertifikat harus berisi daftar sertifikat, dimulai dengan sertifikat klien, diikuti oleh sertifikat perantara, dan diakhiri dengan sertifikat root. Setiap sertifikat harus dimulai pada baris baru dengan struktur berikut:
-----BEGIN CERTIFICATE----- <certificate contents> -----END CERTIFICATE-----
Secrets Manager mendukung rahasia hingga 65.536 byte, yang merupakan ruang yang cukup untuk rantai sertifikat yang panjang.
Kunci pribadi harus dalam format PKCS #8
-----BEGIN PRIVATE KEY----- <private key contents> -----END PRIVATE KEY-----
Untuk kunci pribadi terenkripsi, gunakan struktur berikut:
-----BEGIN ENCRYPTED PRIVATE KEY----- <private key contents> -----END ENCRYPTED PRIVATE KEY-----
Contoh berikut menunjukkan isi rahasia untuk otentikasi mTLS menggunakan kunci pribadi terenkripsi. Untuk kunci pribadi terenkripsi, Anda menyertakan kata sandi kunci pribadi dalam rahasia.
{ "privateKeyPassword": "testpassword", "certificate": "-----BEGIN CERTIFICATE----- MIIE5DCCAsygAwIBAgIRAPJdwaFaNRrytHBto0j5BA0wDQYJKoZIhvcNAQELBQAw ... j0Lh4/+1HfgyE2KlmII36dg4IMzNjAFEBZiCRoPimO40s1cRqtFHXoal0QQbIlxk cmUuiAii9R0= -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- MIIFgjCCA2qgAwIBAgIQdjNZd6uFf9hbNC5RdfmHrzANBgkqhkiG9w0BAQsFADBb ... rQoiowbbk5wXCheYSANQIfTZ6weQTgiCHCCbuuMKNVS95FkXm0vqVD/YpXKwA/no c8PH3PSoAaRwMMgOSA2ALJvbRz8mpg== -----END CERTIFICATE-----", "privateKey": "-----BEGIN ENCRYPTED PRIVATE KEY----- MIIFKzBVBgkqhkiG9w0BBQ0wSDAnBgkqhkiG9w0BBQwwGgQUiAFcK5hT/X7Kjmgp ... QrSekqF+kWzmB6nAfSzgO9IaoAaytLvNgGTckWeUkWn/V0Ck+LdGUXzAC4RxZnoQ zp2mwJn2NYB7AZ7+imp0azDZb+8YG2aUCiyqb6PnnA== -----END ENCRYPTED PRIVATE KEY-----" }
Untuk informasi selengkapnya tentang mTL untuk Amazon MSK, dan petunjuk tentang cara membuat sertifikat klien, lihat Autentikasi klien Mutual TLS untuk Amazon MSK di Panduan Pengembang Amazon Managed Streaming for Apache Kafka.
Autentikasi IAM
Anda dapat menggunakan AWS Identity and Access Management (IAM) untuk mengautentikasi identitas klien yang terhubung ke cluster MSK. Dengan autentikasi IAM, Lambda mengandalkan izin dalam peran eksekusi fungsi Anda untuk terhubung ke klaster, mengambil catatan, dan melakukan tindakan lain yang diperlukan. Untuk contoh kebijakan yang berisi izin yang diperlukan, lihat Membuat kebijakan otorisasi untuk peran IAM di Panduan Pengembang Amazon Managed Streaming for Apache Kafka.
Jika autentikasi IAM aktif di kluster MSK Anda, dan Anda tidak memberikan rahasia, Lambda secara otomatis default menggunakan autentikasi IAM.
Untuk informasi selengkapnya tentang autentikasi IAM di Amazon MSK, lihat kontrol akses IAM.
Bagaimana Lambda memilih broker bootstrap
Lambda memilih broker bootstrap berdasarkan metode otentikasi yang tersedia di cluster Anda, dan apakah Anda memberikan rahasia untuk otentikasi. Jika Anda memberikan rahasia untuk mTLS atau SASL/SCRAM, Lambda secara otomatis memilih metode autentikasi itu. Jika Anda tidak memberikan rahasia, Lambda memilih metode autentikasi terkuat yang aktif di cluster Anda. Berikut ini adalah urutan prioritas di mana Lambda memilih broker, dari autentikasi terkuat hingga terlemah:
mTL (rahasia disediakan untuk mTL)
SASL/SCRAM (secret provided for SASL/SCRAM)
SASL IAM (tidak ada rahasia yang disediakan, dan autentikasi IAM aktif)
TLS yang tidak diautentikasi (tidak ada rahasia yang disediakan, dan autentikasi IAM tidak aktif)
Plaintext (tidak ada rahasia yang disediakan, dan autentikasi IAM dan TLS yang tidak diautentikasi tidak aktif)
catatan
Jika Lambda tidak dapat terhubung ke jenis broker yang paling aman, Lambda tidak mencoba untuk terhubung ke jenis broker yang berbeda (lebih lemah). Jika Anda ingin Lambda memilih jenis broker yang lebih lemah, nonaktifkan semua metode autentikasi yang lebih kuat di cluster Anda.
