Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
Mengkonfigurasi sumber acara Apache Kafka yang dikelola sendiri untuk Lambda
Sebelum Anda membuat pemetaan sumber peristiwa untuk cluster Apache Kafka yang dikelola sendiri, Anda perlu memastikan bahwa cluster dan VPC tempat ia berada dikonfigurasi dengan benar. Anda juga perlu memastikan bahwa peran eksekusi fungsi Lambda Anda memiliki izin IAM yang diperlukan.
Ikuti petunjuk di bagian berikut untuk mengonfigurasi cluster Apache Kafka dan fungsi Lambda yang dikelola sendiri. Untuk mempelajari cara membuat pemetaan sumber peristiwa, lihatMenambahkan klaster Kafka sebagai sumber peristiwa.
Otentikasi cluster Kafka
Lambda mendukung beberapa metode untuk mengautentikasi dengan klaster Apache Kafka yang dikelola sendiri. Pastikan Anda mengonfigurasi cluster Kafka untuk menggunakan salah satu metode otentikasi yang didukung ini. Untuk informasi lebih lanjut tentang keamanan Kafka, lihat bagian Keamanan
Akses VPC
Jika hanya pengguna Kafka dalam VPC Anda yang mengakses broker Kafka Anda, Anda harus mengonfigurasi sumber acara Kafka untuk akses Amazon Virtual Private Cloud (Amazon VPC).
Otentikasi SASL/SCRAM
Lambda mendukung otentikasi Sederhana dan Lapisan Keamanan/Salted Challenge Response Authentication Mechanism (SASL/SCRAM) otentikasi dengan enkripsi Transport Layer Security (TLS) (). SASL_SSL Lambda mengirimkan kredensial terenkripsi untuk mengautentikasi dengan klaster. Lambda tidak mendukung SASL/SCRAM dengan plaintext (). SASL_PLAINTEXT Untuk informasi selengkapnya tentang autentikasi SASL/SCRAM, lihat RFC 5802
Lambda juga mendukung otentikasi SASL/PLAIN. Karena mekanisme ini menggunakan kredensyal teks yang jelas, koneksi ke server harus menggunakan enkripsi TLS untuk memastikan bahwa kredensialnya dilindungi.
Untuk autentikasi SASL, Anda menyimpan kredensyal masuk sebagai rahasia. AWS Secrets Manager Untuk informasi selengkapnya tentang menggunakan Secrets Manager, lihat Tutorial: Membuat dan mengambil rahasia di Panduan AWS Secrets Manager Pengguna.
penting
Untuk menggunakan Secrets Manager untuk otentikasi, rahasia harus disimpan di AWS wilayah yang sama dengan fungsi Lambda Anda.
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, dan server mengirimkan sertifikat ke klien untuk klien untuk memverifikasi server.
Dalam Apache Kafka yang dikelola sendiri, Lambda bertindak sebagai klien. Anda mengonfigurasi sertifikat klien (sebagai rahasia di Secrets Manager) untuk mengautentikasi Lambda dengan broker Kafka Anda. Sertifikat klien harus ditandatangani oleh CA di toko kepercayaan server.
Cluster Kafka mengirimkan sertifikat server ke Lambda untuk mengautentikasi broker Kafka dengan Lambda. Sertifikat server dapat berupa sertifikat CA publik atau sertifikat CA/Self-signed private. Sertifikat CA publik harus ditandatangani oleh otoritas sertifikat (CA) yang ada di toko kepercayaan Lambda. Untuk sertifikat CA/Self-signed privat, Anda mengonfigurasi sertifikat CA root server (sebagai rahasia di Secrets Manager). Lambda menggunakan sertifikat root untuk memverifikasi broker Kafka.
Untuk informasi selengkapnya tentang mTL, lihat Memperkenalkan autentikasi TLS timbal balik untuk Amazon MSK sebagai sumber acara
Mengkonfigurasi rahasia sertifikat klien
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 algoritma enkripsi kunci pribadi 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, sertakan 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-----" }
Mengkonfigurasi rahasia sertifikat CA root server
Anda membuat rahasia ini jika broker Kafka Anda menggunakan enkripsi TLS dengan sertifikat yang ditandatangani oleh CA pribadi. Anda dapat menggunakan enkripsi TLS untuk otentikasi VPC, SASL/SCRAM, SASL/PLAIN, atau mTLS.
Rahasia sertifikat CA root server memerlukan bidang yang berisi sertifikat CA root broker Kafka dalam format PEM. Contoh berikut menunjukkan struktur rahasia.
{"certificate":"-----BEGIN CERTIFICATE----- MIID7zCCAtegAwIBAgIBADANBgkqhkiG9w0BAQsFADCBmDELMAkGA1UEBhMCVVMx EDAOBgNVBAgTB0FyaXpvbmExEzARBgNVBAcTClNjb3R0c2RhbGUxJTAjBgNVBAoT HFN0YXJmaWVsZCBUZWNobm9sb2dpZXMsIEluYy4xOzA5BgNVBAMTMlN0YXJmaWVs ZCBTZXJ2aWNlcyBSb290IENlcnRpZmljYXRlIEF1dG... -----END CERTIFICATE-----" }
Konfigurasi jaringan
Agar Lambda dapat menggunakan cluster Kafka Anda sebagai sumber acara, Lambda memerlukan akses ke VPC Amazon tempat klaster Anda berada. Kami menyarankan Anda menerapkan titik akhir AWS PrivateLink VPC untuk Lambda untuk mengakses VPC Anda. Terapkan titik akhir untuk Lambda dan (). AWS Security Token Service AWS STS Jika broker menggunakan otentikasi, gunakan juga titik akhir VPC untuk Secrets Manager. Jika Anda mengonfigurasi tujuan saat kegagalan, gunakan juga titik akhir VPC untuk layanan tujuan.
Pastikan juga VPC yang terkait dengan klaster Kafka Anda termasuk mencakup gateway NAT per subnet publik. Untuk informasi selengkapnya, lihat Aktifkan akses internet untuk fungsi Lambda yang terhubung dengan VPC.
Jika Anda menggunakan titik akhir VPC, Anda juga harus mengonfigurasinya untuk mengaktifkan nama DNS pribadi.
Saat Anda membuat pemetaan sumber peristiwa untuk cluster Apache Kafka yang dikelola sendiri, Lambda memeriksa apakah Elastic Network Interfaces (ENI) sudah ada untuk subnet dan grup keamanan VPC klaster Anda. Jika Lambda menemukan ENI yang ada, ia mencoba untuk menggunakannya kembali. Jika tidak, Lambda membuat ENI baru untuk terhubung ke sumber acara dan menjalankan fungsi Anda.
catatan
Fungsi Lambda selalu berjalan di dalam VPC yang dimiliki oleh layanan Lambda. VPC ini dikelola secara otomatis oleh layanan dan tidak terlihat oleh pelanggan. Anda juga dapat menghubungkan fungsi Anda ke VPC Amazon. Dalam kedua kasus tersebut, konfigurasi VPC fungsi Anda tidak memengaruhi pemetaan sumber peristiwa. Hanya konfigurasi VPC sumber acara yang menentukan bagaimana Lambda terhubung ke sumber acara Anda.
Untuk informasi selengkapnya tentang mengonfigurasi jaringan, lihat Menyiapkan AWS Lambda dengan cluster Apache Kafka dalam VPC
Aturan grup keamanan VPC
Konfigurasikan grup keamanan untuk VPC Amazon yang berisi klaster Anda dengan aturan berikut (minimal):
-
Aturan masuk - Izinkan semua lalu lintas di port broker Kafka untuk grup keamanan yang ditentukan untuk sumber acara Anda. Kafka menggunakan port 9092 secara default.
-
Aturan keluar - Izinkan semua lalu lintas di port 443 untuk semua tujuan. Izinkan semua lalu lintas di port broker Kafka untuk grup keamanan yang ditentukan untuk sumber acara Anda. Kafka menggunakan port 9092 secara default.
-
Jika Anda menggunakan titik akhir VPC alih-alih gateway NAT, grup keamanan yang terkait dengan titik akhir VPC harus mengizinkan semua lalu lintas masuk pada port 443 dari grup keamanan sumber acara.
Bekerja dengan VPC endpoint
Saat Anda menggunakan titik akhir VPC, panggilan API untuk menjalankan fungsi Anda dirutekan melalui titik akhir ini menggunakan ENI. Prinsipal layanan Lambda perlu memanggil sts:AssumeRole dan lambda:InvokeFunction pada peran dan fungsi apa pun yang menggunakan ENI tersebut.
Secara default, titik akhir VPC memiliki kebijakan IAM yang terbuka. Praktik terbaik adalah membatasi kebijakan ini untuk memungkinkan hanya prinsipal tertentu untuk melakukan tindakan yang diperlukan menggunakan titik akhir itu. Untuk memastikan bahwa pemetaan sumber peristiwa Anda dapat menjalankan fungsi Lambda Anda, kebijakan titik akhir VPC harus mengizinkan prinsip layanan Lambda untuk memanggil dan. sts:AssumeRole lambda:InvokeFunction Membatasi kebijakan titik akhir VPC Anda agar hanya mengizinkan panggilan API yang berasal dari organisasi Anda mencegah pemetaan sumber peristiwa berfungsi dengan baik.
Contoh kebijakan titik akhir VPC berikut menunjukkan cara memberikan akses yang diperlukan ke prinsipal layanan Lambda untuk titik akhir dan Lambda. AWS STS
contoh Kebijakan titik akhir VPC - titik akhir AWS STS
{ "Statement": [ { "Action": "sts:AssumeRole", "Effect": "Allow", "Principal": { "Service": [ "lambda.amazonaws.com" ] }, "Resource": "*" } ] }
contoh Kebijakan titik akhir VPC - Titik akhir Lambda
{ "Statement": [ { "Action": "lambda:InvokeFunction", "Effect": "Allow", "Principal": { "Service": [ "lambda.amazonaws.com" ] }, "Resource": "*" } ] }
Jika broker Kafka Anda menggunakan otentikasi, Anda juga dapat membatasi kebijakan titik akhir VPC untuk titik akhir Secrets Manager. Untuk memanggil Secrets Manager API, Lambda menggunakan peran fungsi Anda, bukan kepala layanan Lambda. Contoh berikut menunjukkan kebijakan titik akhir Secrets Manager.
contoh Kebijakan titik akhir VPC - Titik akhir Secrets Manager
{ "Statement": [ { "Action": "secretsmanager:GetSecretValue", "Effect": "Allow", "Principal": { "AWS": [ "customer_function_execution_role_arn" ] }, "Resource": "customer_secret_arn" } ] }
Jika Anda memiliki tujuan pada kegagalan yang dikonfigurasi, Lambda juga menggunakan peran fungsi Anda untuk memanggil s3:PutObject salah satusns:Publish, sqs:sendMessage atau menggunakan ENI yang dikelola Lambda.
Akses API dan izin fungsi Lambda
Selain mengakses cluster Kafka yang dikelola sendiri, fungsi Lambda Anda memerlukan izin untuk melakukan berbagai tindakan API. Anda menambahkan izin ini ke peran eksekusi fungsi. Jika pengguna Anda memerlukan akses ke tindakan API apa pun, tambahkan izin yang diperlukan ke kebijakan identitas untuk pengguna atau AWS Identity and Access Management peran (IAM).
Izin fungsi Lambda diperlukan
Untuk membuat dan menyimpan log dalam grup log di Amazon CloudWatch Logs, fungsi Lambda Anda harus memiliki izin berikut dalam peran pelaksanaannya:
Izin fungsi Lambda opsional
Fungsi Lambda Anda mungkin juga memerlukan izin untuk:
-
Jelaskan rahasia Secrets Manager Anda.
-
Akses AWS Key Management Service (AWS KMS) kunci terkelola pelanggan Anda.
-
Akses VPC Amazon Anda.
-
Kirim catatan pemanggilan yang gagal ke tujuan.
Secrets Manager dan AWS KMS izin
Bergantung pada jenis kontrol akses yang Anda konfigurasikan untuk broker Kafka Anda, fungsi Lambda Anda mungkin memerlukan izin untuk mengakses rahasia Secrets Manager Anda atau untuk mendekripsi kunci yang dikelola pelanggan Anda. AWS KMS Untuk mengakses sumber daya ini, peran eksekusi fungsi Anda harus memiliki izin berikut:
Izin VPC
Jika hanya pengguna dalam VPC yang dapat mengakses cluster Apache Kafka yang dikelola sendiri, fungsi Lambda Anda harus memiliki izin untuk mengakses sumber daya VPC Amazon Anda. Sumber daya ini termasuk VPC, subnet, grup keamanan, dan antarmuka jaringan. Untuk mengakses sumber daya ini, peran eksekusi fungsi Anda harus memiliki izin berikut:
Menambahkan izin ke peran eksekusi
Secara default, Lambda tidak diizinkan untuk melakukan tindakan yang diperlukan atau opsional untuk klaster Apache Kafka yang dikelola sendiri. Anda harus membuat dan menentukan tindakan ini dalam Kebijakan kepercayaan IAM, lalu melampirkan kebijakan ke peran eksekusi Anda. Contoh ini menunjukkan cara agar Anda dapat membuat kebijakan yang mengizinkan Lambda mengakses sumber daya Amazon VPC Anda.
{ "Version":"2012-10-17", "Statement":[ { "Effect":"Allow", "Action":[ "ec2:CreateNetworkInterface", "ec2:DescribeNetworkInterfaces", "ec2:DescribeVpcs", "ec2:DeleteNetworkInterface", "ec2:DescribeSubnets", "ec2:DescribeSecurityGroups" ], "Resource":"*" } ] }
Untuk informasi tentang membuat dokumen kebijakan JSON di konsol IAM, lihat Membuat kebijakan di tab JSON di Panduan Pengguna IAM.
Memberikan akses pengguna dengan kebijakan IAM
Secara default, pengguna dan peran tidak memiliki izin untuk melakukan operasi API sumber peristiwa. Untuk memberikan akses ke pengguna di organisasi atau akun Anda, Anda membuat atau memperbarui kebijakan berbasis identitas. Untuk informasi selengkapnya, lihat Mengontrol akses ke AWS sumber daya menggunakan kebijakan di Panduan Pengguna IAM.
