Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
Ak AgentCore ses Memori melalui gateway
Secara default, aplikasi memanggil bidang data Amazon Bedrock AgentCore Memory secara langsung, dan setiap permintaan diautentikasi dengan Sig AWS nature Version 4 (SIGv4). Anda dapat mengontrol akses ini dengan kebijakan berbasis identitas dan berbasis sumber daya IAM. Ini berfungsi dengan baik ketika layanan backend Anda memanggil Memori atas nama semua pengguna dan tidak perlu menerapkan isolasi per pengguna di lapisan Memori.
Ketika backend Anda memanggil Memori untuk banyak pengguna, Memory hanya melihat peran IAM backend Anda. Itu tidak dapat memverifikasi pengguna akhir mana permintaan itu. Kode aplikasi Anda harus menetapkan namespace actorId dan namespace yang benar pada setiap permintaan untuk mengisolasi data satu pengguna dari yang lain.
Dengan AgentCore Gateway di depan AgentCore Memori, Anda dapat memindahkan penegakan itu keluar dari kode aplikasi Anda dan masuk ke infrastruktur. Gateway menjadi titik masuk tunggal yang aman untuk lalu lintas Memori. Ini mengautentikasi setiap penelepon, mengevaluasi kebijakan kontrol akses, dan meneruskan permintaan yang diizinkan ke Memori. Memori Fronting dengan gateway memberi Anda dua fitur yang tidak dimiliki akses langsung:
- Oautentikasi OAuth untuk pengguna akhir
-
Bidang data memori adalah SigV4-only. Dengan gateway yang dikonfigurasi untuk otentikasi masuk OAuth (JWT), pengguna akhir Anda dapat mengotentikasi dengan penyedia OpenID Connect standar, dan aplikasi Anda tidak mendistribusikan kredentif kepada mereka. AWS Untuk informasi selengkapnya, lihat Meng autentikasi pengguna akhir ke Memori dengan O Auth.
- Fine-grained kontrol akses
-
Gateway dapat mengevaluasi kebijakan yang membatasi pemanggil ke aktor mereka sendiri, namespace mereka sendiri, atau serangkaian operasi Memori tertentu, termasuk untuk pemanggil yang diautentikasi dengan OAuth. Untuk informasi selengkapnya, lihat kontrol Fine-grained akses untuk Memori.
catatan
Fine-grained kontrol akses tidak didukung untuk operasi batch Memori (
BatchCreateMemoryRecords,BatchUpdateMemoryRecords, danBatchDeleteMemoryRecords). Masing-masing operasi ini membawa beberapa catatan dalam satu permintaan, yang tidak dapat dievaluasi oleh mesin kebijakan secara individual.
Kedua fitur dibangun pada konektor AgentCore Memori yang dijelaskan di halaman ini. Menyiapkan konektor adalah prasyarat untuk keduanya.
Konektor AgentCore Memori
Konektor AgentCore memori (agentcore-memory) adalah konektor gateway terkelola yang menghubungkan target gateway ke bidang data AgentCore Memori. Konektor adalah tipe target bawaan: alih-alih menulis skema API dan mengelola sendiri kabel titik akhir, Anda membuat target dari jenis konektor dan hanya menyediakan id konektor dan parameter target.
Saat Anda membuat target konektor Memori, Anda menyediakan:
-
konektor id (
agentcore-memory), dan -
parameter target, terutama sumber
memoryIddaya Memori di depan target.
Konektor kemudian:
- Menyelesaikan titik akhir Memori
-
Ini menentukan titik akhir bidang data Memori yang benar untuk sumber daya Memori target.
- Menjadikan operasi Memori yang didukung tersedia sebagai tindakan Cedar
-
Konektor membuat operasi bidang data Memori berikut tersedia sebagai tindakan Cedar, masing-masing dengan bidang permintaan yang diterimanya:
ListEventsCreateEvent,GetEvent,,DeleteEvent,ListSessions,ListActors,RetrieveMemoryRecords,ListMemoryRecords,GetMemoryRecord,DeleteMemoryRecordListMemoryExtractionJobs, danStartMemoryExtractionJob. Inilah yang memungkinkan kebijakan kontrol akses yang halus mengizinkan atau menolak operasi Memori tertentu dan kondisi pada atribut permintaan mereka. Untuk id tindakan dan atribut permintaan, lihat kontrol Fine-grained akses untuk Memori.catatan
Operasi batch Memori (
BatchCreateMemoryRecordsBatchUpdateMemoryRecords,, danBatchDeleteMemoryRecords) tidak didukung untuk kontrol akses yang halus. Masing-masing operasi ini membawa beberapa catatan dalam satu permintaan, yang tidak dapat dievaluasi oleh mesin kebijakan secara individual. - Meneruskan permintaan
-
Ini meneruskan setiap permintaan yang diizinkan ke bidang data Memori menggunakan mode kredensi keluar yang dikonfigurasi target.
Karena konektor menyediakan model Memori di luar kotak, Anda tidak membuat skema secara manual atau mengelola kabel titik akhir.
Bagaimana permintaan mengalir melalui gateway
Ketika klien memanggil Memori melalui gateway, gateway memproses permintaan dalam empat langkah:
-
Otentikasi masuk — gateway memvalidasi pemanggil sesuai dengan jenis otorizer inbound: token pembawa OAuth (JWT), SigV4, atau permintaan yang tidak diautentikasi. AWS Lihat Mode otentikasi masuk dan keluar.
-
Resolusi tindakan — gateway memetakan permintaan HTTP masuk (metode dan jalur) ke tindakan Cedar untuk operasi Memori yang sedang dicoba oleh pemanggil. Parameter jalur dan bidang isi permintaan diekstraksi ke dalam objek konteks permintaan.
-
Evaluasi kebijakan — jika gateway memiliki mesin kebijakan terlampir, gateway mengevaluasi kebijakan kontrol akses yang dikonfigurasi terhadap permintaan tersebut. Evaluasi dibantah secara default. Lihat kontrol Fine-grained akses untuk Memori.
-
Otentikasi keluar — jika permintaan diizinkan, gateway meneruskannya ke bidang data Memori menggunakan mode kredensi keluar target. Lihat Mode kredensi keluar.
Mode otentikasi masuk dan keluar
Gateway memiliki tipe otorizer masuk yang mengontrol cara mengotentikasi pemanggil, dan setiap target konektor Memori memiliki mode kredensi keluar yang mengontrol identitas yang digunakan gateway untuk memanggil Memori. Sebagian besar penerapan menggunakan salah satu dari dua kombinasi:
- Pengguna akhir OAuth (jalur kontrol akses berbutir halus utama)
-
CUSTOM_JWTinbound denganGATEWAY_IAM_ROLEoutbound. Pengguna atau agen Anda melakukan otentikasi dengan penyedia OpenID Connect, dan gateway memanggil Memori di bawah peran eksekusi gatewaynya sendiri. Ini adalah kombinasi yang digunakan ketika Anda menginginkan isolasi per pengguna untuk penelepon yang bukan kepala sekolah IAM. Untuk informasi selengkapnya, lihat Meng autentikasi pengguna akhir ke Memori dengan O Auth. - Layanan backend IAM dengan pass-through identitas
-
AWS_IAMinbound denganCALLER_IAM_CREDENTIALSoutbound. Gateway meneruskan identitas IAM masing-masing pemanggil ke Memori, sehingga Memory mengevaluasi izin IAM pemanggil dan Anda dapat menggunakan sumber pin lalu lintas yang diteruskan gerbang. Gunakan ini ketika penelepon Anda sudah menjadi kepala IAM dan Anda ingin Memory mengizinkan mereka secara langsung.
Kombinasi lain — seperti AWS_IAM atau NONE inbound dengan GATEWAY_IAM_ROLE outbound — didukung untuk skenario khusus seperti penegakan Cedar terpusat untuk penelepon IAM atau pengembangan dan pengujian. Lihat matriks kompatibilitas untuk set lengkapnya.
Jenis otorisasi masuk
Anda memilih otorisasi inbound saat Anda membuat gateway. Konektor Memori mendukung semua jenis otorizer masuk yang didukung AgentCore Gateway. Untuk informasi selengkapnya, lihat Konsep inti untuk Amazon Bedrock AgentCore Gateway.
-
CUSTOM_JWT(OAuth/JWT) — jalur utama untuk kontrol akses berbutir halus. Membuat klaim JWT penelepon tersedia untuk kebijakan kontrol akses dan mengaktifkan otentikasi OAuth untuk pengguna akhir. Lihat Meng autentikasi pengguna akhir ke Memori dengan O Auth. -
AWS_IAM(SigV4) — membuat identitas IAM pemanggil tersedia untuk kebijakan kontrol akses. Gunakan untuk penelepon IAM-authenticated backend, penegakan Cedar terpusat, atau penyematan sumber. -
AUTHENTICATE_ONLY- memerlukan permintaan yang ditandatangani yang valid tetapi tidak mengekspos identitas pemanggil yang diketik untuk aturan kebijakan berbasis identitas. -
NONE— tidak ada otorisasi. Ditujukan untuk pengembangan dan pengujian saja; jangan menggunakannya untuk akses Memori produksi.
Mode kredensi keluar
Mode kredensi keluar menentukan identitas yang dilihat bidang data Memori. Aturannya sederhana:
-
Jika otentikasi masuk Anda adalah
CUSTOM_JWTatauNONE, gateway selalu menggunakanGATEWAY_IAM_ROLE- itu memanggil Memori di bawah peran eksekusi gateway-nya. Tidak ada opsi lain yang valid dan tidak ada yang bisa dipilih. -
Jika otentikasi masuk Anda adalah
AWS_IAMatauAUTHENTICATE_ONLY, Anda juga dapat memilihCALLER_IAM_CREDENTIALSuntuk meneruskan identitas IAM pemanggil sendiri ke Memori, alih-alih menggunakan peran eksekusi gateway.
| Mode keluar | Bagaimana gateway memanggil Memori |
|---|---|
|
|
Gateway memanggil Memori di bawah peran eksekusi gateway-nya (panggilan pihak pertama). Bekerja dengan setiap jenis inbound. |
|
|
Gateway meneruskan identitas IAM pemanggil sendiri ke Memori (akses yang didelegasikan). Membutuhkan |
Matriks kompatibilitas
Tabel berikut mencantumkan setiap kombinasi yang didukung dari inbound authorizer dan mode kredentif keluar pada target konektor Memori.
| Ke dalam |
GATEWAY_IAM_ROLE
|
CALLER_IAM_CREDENTIALS
|
|---|---|---|
|
|
Didukung |
Ditolak saat pembuatan target |
|
|
Didukung |
Didukung |
|
|
Didukung |
Ditolak saat pembuatan target |
|
|
Didukung |
Didukung |
Bagaimana mode kredensi keluar mempengaruhi kontrol akses memori
Mode kredensi keluar menentukan identitas mana yang diotorisasi oleh Memory, sehingga kebijakan IAM yang dicakup oleh pemanggil berperilaku berbeda di setiap mode. Ini juga menentukan bagaimana Anda dapat membatasi lalu lintas yang diteruskan gateway dengan kebijakan berbasis sumber daya Mem ori.
-
GATEWAY_IAM_ROLE -
Gateway memanggil Memori di bawah peran eksekusi gateway-nya, sehingga Memory mengotorisasi permintaan sebagai peran itu. Untuk membatasi akses ke gateway ini, Anda dapat menggunakan
aws:PrincipalArnkondisi terhadap peran eksekusi gateway ARN, dan lingkup kebijakan identitas peran itu hanya untuk tindakan Memori yang dibutuhkan gateway. Permintaan yang diteruskan oleh gateway juga membawa kunciaws:SourceArnkondisi yang disetel ke gateway ARN (lihat mode berikut). -
CALLER_IAM_CREDENTIALS -
Gateway meneruskan identitas IAM pemanggil ke Memori, sehingga Memory mengotorisasi permintaan sebagai pemanggil. Karena prinsipalnya adalah penelepon daripada gateway, gunakan
aws:SourceArnkondisi untuk membatasi akses ke lalu lintas yang diteruskan gateway.
Dalam kedua mode keluar, gateway mencap kunci aws:SourceArn kondisi dengan ARN gateway yang meneruskan permintaan. Oleh karena itu, kebijakan berbasis sumber daya memori dapat membatasi akses ke gateway tertentu dengan mencoco aws:SourceArn kkan dengan ARN gateway, terlepas dari mode kredensi keluar.
penting
Karena mode kredensi keluar mengubah identitas yang diotorisasi Memory, kebijakan IAM yang dicakup oleh pemanggil berperilaku berbeda:
-
Dengan
CALLER_IAM_CREDENTIALS, Memory melihat identitas IAM penelepon sendiri. Kebijakan berbasis identitas dan sumber daya IAM yang mereferensikan pemanggil — termasuk kunci kondisi tertentuactorId, atau Memori sepertibedrock-agentcore:namespacedanbedrock-agentcore:namespacePath— dievaluasi terhadap pemanggil tersebut.Deny -
Dengan
GATEWAY_IAM_ROLE, Memory hanya melihat peran eksekusi gateway. Setiap permintaan pemanggil mencapai Memori di bawah peran tunggal itu, sehingga kebijakan IAM yang dicakup ke identitas pemanggil individu (sepertiDenypada penelepon tertentuactorId) tidak di evaluasi terhadap pemanggil asli dan tidak berlaku. Jangan mengandalkan kebijakan IAM cakupan pemanggil untuk menerapkan akses per penelepon dalam mode ini.
Jika Anda menggunakan GATEWAY_IAM_ROLE dan memerlukan kontrol akses per penelepon (misalnya, membatasi pemanggil ke ruang nama actorId atau ruang nama mereka sendiri), terapkan dengan kontrol akses halus (kebijakan Cedar) pada gateway daripada dengan kebijakan IAM cakupan pemanggil. Ini adalah jalur kontrol akses berbutir halus utama. Untuk informasi selengkapnya, lihat kontrol Fine-grained akses untuk Memori.
Untuk kunci kondisi kebijakan berbasis sumber daya dan contoh kebijakan JSON, lihat Resource-based kebijakan untuk Amazon Bedrock. AgentCore