View a markdown version of this page

Ak AgentCore ses Memori melalui gateway - Batu Dasar Amazon AgentCore

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 memoryId daya 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:

  1. 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.

  2. 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.

  3. 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.

  4. 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 dengan GATEWAY_IAM_ROLE outbound. 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 dengan CALLER_IAM_CREDENTIALS outbound. 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_JWT atauNONE, gateway selalu menggunakan GATEWAY_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_IAM atauAUTHENTICATE_ONLY, Anda juga dapat memilih CALLER_IAM_CREDENTIALS untuk meneruskan identitas IAM pemanggil sendiri ke Memori, alih-alih menggunakan peran eksekusi gateway.

Mode keluar Bagaimana gateway memanggil Memori

GATEWAY_IAM_ROLE

Gateway memanggil Memori di bawah peran eksekusi gateway-nya (panggilan pihak pertama). Bekerja dengan setiap jenis inbound.

CALLER_IAM_CREDENTIALS

Gateway meneruskan identitas IAM pemanggil sendiri ke Memori (akses yang didelegasikan). Membutuhkan AWS_IAM atau AUTHENTICATE_ONLY masuk, karena memerlukan identitas IAM penelepon untuk meneruskan.

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

CUSTOM_JWT

Didukung

Ditolak saat pembuatan target

AWS_IAM

Didukung

Didukung

NONE

Didukung

Ditolak saat pembuatan target

AUTHENTICATE_ONLY

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:PrincipalArn kondisi 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 kunci aws:SourceArn kondisi 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:SourceArn kondisi 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:

  • DenganCALLER_IAM_CREDENTIALS, Memory melihat identitas IAM penelepon sendiri. Kebijakan berbasis identitas dan sumber daya IAM yang mereferensikan pemanggil — termasuk kunci kondisi tertentuactorId, atau Memori seperti bedrock-agentcore:namespace dan bedrock-agentcore:namespacePath — dievaluasi terhadap pemanggil tersebut. Deny

  • DenganGATEWAY_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 (seperti Deny pada 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