Tentang Identitas Agen untuk GKE

Workload agen sering kali memerlukan langkah-langkah pertahanan, kontrol akses, dan alur kerja autentikasi yang berbeda dengan jenis workload lainnya. Anda dapat menggunakan Agent Identity untuk memberi setiap agen identitas per-Pod yang telah dibuktikan dan berjangka pendek. Identitas ini membantu Anda mengidentifikasi workload agen serta melacak dan mengelola tindakan yang dilakukan workload tersebut di seluruh Google Cloud. Dokumen ini menjelaskan cara kerja Identitas Agen di Google Kubernetes Engine (GKE), termasuk cara berintegrasi dengan produkGoogle Cloud lain, jenis autentikasi yang dapat digunakan agen Anda, dan cara mengatur beban kerja Anda menggunakan identitas ini.

Dokumen ini ditujukan untuk administrator platform dan engineer keamanan yang ingin meningkatkan keamanan agen yang berjalan di cluster GKE sekaligus mengintegrasikan agen dengan produk dan layanan Google Cloud .

Anda seharusnya sudah memahami topik berikut:

Apa yang dimaksud dengan Identitas Agen?

Google Cloud menyediakan berbagai jenis identitas untuk workload Anda, yang masing-masing ditujukan untuk serangkaian kasus penggunaan dan jenis workload tertentu. Identitas Agen adalah jenis identitas yang dirancang untuk beban kerja agen AI. Agen yang menggunakan Identitas Agen akan mendapatkan identitas unik yang didasarkan pada standar SPIFFE. Identitas ini terikat pada siklus proses agen, mengidentifikasi beban kerja sebagai agen, dan dikenali oleh berbagai layanan Gemini Enterprise Agent Platform seperti Agent Registry dan Agent Gateway. Anda dapat melacak dan mengelola workload yang memiliki identitas agen di semua layanan yang diakses workload, terlepas dari tempat workload tersebut berjalan. Workload yang menggunakan Agent Identity dapat melakukan autentikasi ke server MCP, resource di dalam dan di luar Google Cloud, agen lain, dan endpoint menggunakan identitasnya sendiri atau atas nama pengguna akhir. Untuk mengetahui informasi selengkapnya tentang Identitas Agen, lihat Ringkasan Identitas Agen.

Anda dapat menggunakan Identitas Agen untuk meningkatkan keamanan dan tata kelola agen AI yang Anda deploy di cluster GKE dan untuk mengaktifkan alur kerja tertentu bagi agen Anda seperti berikut:

  • Mengintegrasikan agen di GKE dengan produk seperti Agent Registry dan Agent Gateway.
  • Mengelola peran untuk beban kerja agen di seluruh project, folder, atau organisasi dalam kebijakan Identity and Access Management (IAM).
  • Mengurangi dampak agen yang disusupi pada node dan Pod lain di cluster.
  • Siapkan berbagai alur kerja autentikasi, seperti agen yang bertindak atas nama pengguna akhir, dengan menggunakan pengelola autentikasi Agent Identity.

Perbandingan dengan Workload Identity Federation for GKE

Agent Identity dan Workload Identity Federation for GKE menyediakan cara untuk memberikan identitas ke workload. Identitas Agen dirancang untuk model ancaman dan persyaratan khusus yang berlaku untuk agen AI, yang menghasilkan berbagai perbedaan fungsional. Tabel berikut memberikan perbandingan umum perbedaan ini:

Agent Identity Workload Identity Federation for GKE
Token akses identitas agen dapat terikat secara kriptografis ke sertifikat X.509 per-Pod. Token akses terikat memerlukan koneksi mTLS dan tidak berfungsi jika digunakan di luar Pod asli. Token akses gabungan tidak terikat secara kriptografis ke identitas Pod, berfungsi melalui koneksi non-mTLS, dan dapat digunakan di luar Pod asli.
Terintegrasi dengan pengelola autentikasi Agent Identity untuk mendukung alur kerja OAuth dan menggunakan kredensial pihak ketiga tanpa pengelolaan kredensial manual. Memerlukan penerapan alur kerja OAuth secara manual dan pengelolaan kredensial pihak ketiga saat melakukan autentikasi ke alat dan layanan eksternal.
Berfungsi dengan baik untuk workload otonom seperti agen AI. Berfungsi dengan baik untuk microservice deterministik seperti server web, API, dan tugas batch.
Memerlukan GKE versi 1.37.0-gke.3503000 atau yang lebih baru. Tersedia di semua versi GKE.
Token akses identitas agen terikat selalu menggunakan cakupan akses https://www.googleapis.com/auth/cloud-platform. Cakupan kustom tidak didukung. Token akses gabungan mendukung cakupan akses kustom.
Aplikasi dapat memperoleh token ID identitas agen untuk mengautentikasi secara langsung ke workload lain atau layanan hilir. Aplikasi tidak dapat memperoleh token ID kecuali jika ServiceAccount Kubernetes dikonfigurasi untuk meniru identitas akun layanan IAM.

Integrasi dengan Agent Platform

Gemini Enterprise Agent Platform mencakup beberapa produk dan layanan yang dirancang untuk membangun, mengatur, dan mengoperasikan agen dalam skala besar. Jika menjalankan workload agen di GKE, Anda dapat menggunakan produk Agent Platform dengan menetapkan identitas agen ke workload dan mendaftarkan workload sebagai agen di Agent Registry. Untuk mengintegrasikan dan menggunakan layanan Agent Platform dengan agen GKE, operator aplikasi Anda menambahkan anotasi dan label ke spesifikasi Kubernetes dari workload agen. Selain memverifikasi bahwa Workload Identity Federation for GKE diaktifkan, Anda tidak perlu membuat perubahan pada konfigurasi cluster atau node pool. Kemudian, Anda dapat mengelola dan mengatur agen GKE dengan cara yang sama seperti Anda mengatur agen yang berjalan di Agent Runtime atau Cloud Run.

Pendaftaran di Agent Registry juga membantu mencegah potensi gangguan saat Anda memindahkan project antar-organisasi. Selama pemindahan project, Agent Registry memeriksa apakah ada agen yang menggunakan identitas agen yang didasarkan pada domain tepercaya tingkat organisasi, yang akan berubah setelah pemindahan. Jika identitas agen tingkat organisasi sedang digunakan, pemindahan project akan diblokir. Pemeriksaan ini hanya terjadi pada Deployment yang Anda daftarkan di Agent Registry. Pemeriksaan tidak terjadi dengan pengontrol beban kerja lain atau Pod statis.

Cara kerjanya di GKE

Di GKE, Agent Identity menggunakan konsep seperti server metadata GKE dan kumpulan identitas, mirip dengan Workload Identity Federation for GKE. Untuk menggunakan Agent Identity, Anda juga harus mengaktifkan Workload Identity Federation for GKE di cluster. Google Cloud akan otomatis membuat agent identity pool di tingkat project atau organisasi. Kumpulan identitas agen adalah domain tepercaya SPIFFE dan merupakan root of trust untuk identitas dan kredensial agen. Developer aplikasi dapat meminta identitas agen untuk agen mereka dengan menambahkan anotasi dan label ke spesifikasi Pod mereka. Saat workload di-deploy ke cluster, GKE akan menetapkan kredensial berikut ke workload:

  • Identitas SPIFFE yang mengidentifikasi workload. Semua Pod dalam workload terkelola, seperti Deployment, berbagi SPIFFE ID workload tersebut. ID SPIFFE mengidentifikasi agen di seluruh layanan Google Cloud . Anda dapat melacak tindakan apa pun yang dilakukan Pod, baik sebagai agen maupun atas nama pengguna akhir, dengan menggunakan ID SPIFFE. ID SPIFFE memiliki sintaksis berikut:

    spiffe://TRUST_DOMAIN/resources/container/projects/PROJECT_NUMBER/locations/CONTROL_PLANE_LOCATION/clusters/CLUSTER_NAME/ns/NAMESPACE/sa/SERVICEACCOUNT_NAME

    String ID ini memiliki atribut berikut:

    • TRUST_DOMAIN: domain tepercaya SPIFFE, yang memiliki salah satu nilai berikut, bergantung pada apakah project yang berisi cluster berada dalam organisasi atau tidak:
      • Project yang berada dalam organisasi: agents.global.org-ORGANIZATION_ID.system.id.goog, dengan ORGANIZATION_ID adalah ID organisasi.
      • Project yang tidak berada dalam organisasi: agents.global.proj-PROJECT_NUMBER.system.id.goog, dengan PROJECT_NUMBER adalah nomor project dari project cluster.
    • PROJECT_NUMBER: nomor project dari project cluster.
    • CONTROL_PLANE_LOCATION: region atau zona tempat bidang kontrol cluster berada.
    • CLUSTER_NAME: nama cluster tempat Pod berada.
    • NAMESPACE: nama namespace Kubernetes tempat Pod berada.
    • SERVICEACCOUNT_NAME: nama ServiceAccount Kubernetes yang ditetapkan ke Pod.

  • Paket kredensial identitas agen (x509.credential-bundle.private-key.pem) yang dipasang sebagai volume di setiap Pod dan dapat digunakan untuk autentikasi mTLS ke API Google Cloud . File ini mencakup kredensial berikut:

    • Rantai sertifikat X.509 yang mencakup ID SPIFFE untuk beban kerja agen sebagai parameter Nama Alternatif Subjek (SAN) dan akan berakhir dalam 24 jam. Rantai sertifikat digunakan untuk mendapatkan token akses terikat dan token identitas untuk autentikasi ke layanan lain.
    • Kunci pribadi yang otomatis dibuat oleh proses kubelet untuk setiap Pod. Kunci mengikat sertifikat X.509 Pod ke Pod secara kriptografis. Kunci ini membuktikan bahwa Pod yang membuat permintaan memiliki sertifikat X.509 yang digunakan untuk membuat koneksi TLS.

  • Paket kepercayaan CA root (TRUST_DOMAIN.spiffe-trust-bundle.pem) yang dipasang sebagai volume di setiap Pod dan dapat digunakan untuk mengonfigurasi autentikasi mTLS antar-agen yang menggunakan domain tepercaya yang sama. Selama handshake mTLS, agen menggunakan paket kepercayaan CA root untuk memvalidasi rantai sertifikat yang ditampilkan oleh agen peer.

Konfigurasi tingkat workload

Untuk menetapkan identitas agen dan kredensial per-Pod ke workload, GKE mencari anotasi berikut dalam spesifikasi Pod:

  • iam.gke.io/identity: "spiffe://TRUST_DOMAIN/*": GKE menggunakan anotasi ini untuk menetapkan ID SPIFFE ke Pod dari domain tepercaya yang sesuai.

  • iam.gke.io/inject-podcertificates: "true": GKE menggunakan anotasi ini untuk menambahkan paket kredensial identitas agen dan paket kepercayaan cluster ke setiap Pod dalam workload. Jika anotasi ini tidak ada, Anda tidak dapat memperoleh token akses yang terikat ke Pod tertentu. Kredensial yang disuntikkan digunakan untuk autentikasi mTLS dari Pod Anda keGoogle Cloud API atau agen peer mana pun.

Selain itu, Agent Registry menggunakan label dan anotasi berikut untuk mendaftarkan agen GKE Anda secara otomatis:

  • Label registry.gke.io/functional-type: "AGENT": mengidentifikasi workload sebagai agen AI dan menambahkan agen ke Agent Registry. Label ini hanya didukung oleh Deployment dan harus ditentukan di kolom metadata.labels pada manifes Deployment.
  • Anotasi iam.gke.io/spiffe-identity-type: "agent-identity": menunjukkan bahwa agen menggunakan Identitas Agen. Anotasi ini ditentukan dalam spesifikasi Pod. Jika label registry.gke.io/functional-type: "AGENT" ditentukan untuk Deployment, anotasi ini diperlukan dalam spesifikasi Pod.

Untuk mengintegrasikan agen GKE Anda dengan Agent Platform, daftarkan workload Anda ke Agent Registry selain menggunakan Agent Identity. Pertimbangkan untuk menerapkan pendaftaran workload agen atau mengotomatiskan pendaftaran di pipeline deployment Anda.

Token akses untuk agen

Di GKE, setiap Pod yang menggunakan Identitas Agen akan mendapatkan paket kredensial unik yang berisi sertifikat X.509 dan kunci pribadi Pod, yang tidak keluar dari Pod. Untuk mengakses API Google Cloud atau layanan eksternal, Pod agen di cluster GKE meminta token akses identitas agen dari server metadata GKE yang berjalan di setiap node. Pod menggunakan token akses identitas agen untuk mengautentikasi sebagai identitas agen.

Token akses dapat terikat atau tidak terikat, sebagai berikut:

  • Token akses terikat: terikat secara kriptografis ke sertifikat X.509 Pod dan hanya dapat digunakan melalui koneksi mTLS yang diautentikasi menggunakan sertifikat X.509 tersebut. Setiap permintaan token akses yang menyertakan sertifikat X.509 dalam payload akan menghasilkan token terikat.
  • Token akses tidak terikat: tidak terikat secara kriptografis ke Pod tertentu dan dapat digunakan melalui koneksi non-mTLS. Token akses yang tidak terikat lebih rentan terhadap serangan replay token, karena token yang bocor dapat digunakan oleh Pod lain.

Agen menggunakan token akses terikat atau tidak terikat untuk mengautentikasi permintaan mereka ke Google Cloud API. Administrator identitas dapat mengontrol akses yang dimiliki agen dengan menentukan token akses identitas agen tersebut di kebijakan IAM, seperti yang dijelaskan dalam Mengontrol akses ke Google Cloud resource untuk agen.

Jika Pod memiliki anotasi iam.gke.io/inject-podcertificates: "true", maka Library Klien Cloud dan library autentikasi Google akan menggunakan Kredensial Default Aplikasi (ADC) untuk otomatis mendapatkan token akses identitas agen terikat untuk Pod. Proses otomatis ini mungkin tidak terjadi di setiap pustaka atau bahasa pemrograman. Untuk meminta token akses yang tidak terikat, developer menggunakan salah satu metode berikut:

  • Tentukan anotasi iam.gke.io/inject-podcertificates: "true" dan tetapkan variabel lingkungan GOOGLE_API_ENABLE_RUNTIME_BOUND_TOKEN ke nilai false dalam spesifikasi Pod. GKE menambahkan paket kredensial X.509 ke Pod, tetapi variabel lingkungan menyebabkan ADC mendapatkan token akses yang tidak terikat.

    Metode ini memungkinkan Pod terus membuat koneksi mTLS dengan workload lain menggunakan sertifikat sekaligus menggunakan token akses yang tidak terikat untuk mengakses Google Cloud API.

  • Jangan tentukan anotasi iam.gke.io/inject-podcertificates: "true" dalam spesifikasi Pod. GKE tidak menambahkan paket kredensial X.509 ke Pod, sehingga ADC mendapatkan token akses yang tidak terikat untuk Pod.

  • Kirim permintaan GET HTTP langsung ke endpoint token server metadata GKE, yang menampilkan token akses yang tidak terikat.

Alur kerja autentikasi untuk agen

Tidak seperti workload non-agen, agen mungkin perlu mengautentikasi ke layanan atas nama pengguna akhir atau sebagai identitas agen itu sendiri, bergantung pada tugas yang dicoba dilakukan agen. Identitas Agen mendukung autentikasi ke jenis resource berikut dengan menggunakan berbagai kredensial dan model autentikasi:

  • Google Cloud API
  • Alat dan layanan eksternal
  • Autentikasi antar-agen

Autentikasi ke Google Cloud API

Agen dapat menggunakan identitasnya sendiri untuk melakukan autentikasi ke Google Cloud API, seperti ke BigQuery atau Platform Agen. Untuk mengautentikasi, Pod mendapatkan token akses identitas agen dari server metadata GKE di node. Token akses ini dapat secara opsional diikat ke sertifikat X.509 Pod, yang berarti bahwa token akses hanya dapat digunakan melalui koneksi mTLS yang diautentikasi menggunakan sertifikat X.509.

Jika aplikasi Anda menggunakan library autentikasi Python google-auth versi 2.61.0 atau yang lebih baru, maka Kredensial Default Aplikasi (ADC) akan otomatis meminta token akses terikat untuk Pod yang memiliki paket kredensial identitas agen. Jika Anda menggunakan Library Klien Cloud untuk Python, pastikan Anda menggunakan versi yang menyertakan library google-auth versi 2.61.0 atau yang lebih baru. Untuk bahasa pemrograman lain atau untuk versi library Python google-auth yang lebih lama dari 2.61.0, minta token akses yang tidak terikat.

Jika Anda mendapatkan token akses terikat, Anda harus menggunakan sertifikat X.509 Pod untuk membuat koneksi mTLS dengan endpoint mTLS API tujuan. Jika mendapatkan token akses yang tidak terikat, Anda dapat menggunakan token tersebut dalam permintaan ke endpoint non-mTLS API tersebut.

Untuk mengonfigurasi kode aplikasi agar mendapatkan token akses terikat atau tidak terikat dengan menggunakan metode ini, lihat Mengautentikasi menggunakan identitas agen di GKE.

Jika Anda adalah administrator platform atau administrator keamanan, Anda tidak perlu mengonfigurasi autentikasi tambahan untuk agen yang melakukan autentikasi ke APIGoogle Cloud . Anda dapat mengontrol akses ke resource menggunakan kebijakan IAM, seperti yang dijelaskan dalam Mengontrol akses ke Google Cloud resource untuk agen.

Autentikasi agen ke layanan eksternal

Agen sering kali perlu mengakses alat dan layanan eksternal menggunakan kredensial tertentu, seperti kunci API atau token OAuth. Agen mungkin perlu mengautentikasi sebagai identitasnya sendiri atau atas nama pengguna akhir. Anda dapat memberikan kredensial tertentu kepada agen menggunakan Pengelola autentikasi Identitas Agen (Pratinjau). Pengelola autentikasi memusatkan konfigurasi alur kerja autentikasi dan perolehan kredensial untuk agen yang Anda jalankan di seluruh Google Cloud.

Di pengelola autentikasi, Anda mengonfigurasi penyedia autentikasi untuk menangani alur kerja autentikasi tertentu. Saat agen di GKE perlu melakukan autentikasi menggunakan kredensial tertentu, Pod akan menggunakan token akses identitas agennya untuk melakukan autentikasi ke pengelola autentikasi. Penyedia autentikasi kemudian menangani langkah autentikasi tambahan dan menampilkan kredensial yang diminta ke Pod. Pengelola autentikasi menukarkan kredensial eksternal dengan token akses yang memiliki masa aktif singkat, sehingga token refresh yang memiliki masa aktif lama dan secret API tidak disimpan di penampung agen.

Anda dapat menggunakan pengelola autentikasi untuk kasus penggunaan berikut, yang masing-masing melibatkan penyiapan dan konfigurasi tertentu di pengelola autentikasi dan dalam kode aplikasi:

  • Mengakses layanan eksternal atas nama pengguna akhir.
  • Mengakses layanan eksternal sebagai identitasnya sendiri.
  • Akses API menggunakan kunci API.

Anda dapat memantau dan mencabut kredensial yang dibuat oleh pengelola autentikasi. Anda juga dapat melacak kredensial yang digunakan agen tertentu, karena agen melakukan autentikasi ke pengelola autentikasi menggunakan token akses identitas agennya. Bagian berikut menjelaskan kasus penggunaan untuk pengelola autentikasi dan model autentikasi yang sesuai. Bergantung pada model autentikasi yang Anda gunakan, Anda dan developer aplikasi Anda perlu membuat perubahan tertentu pada kode agen dan aplikasi sisi klien.

Akses ke layanan eksternal atas nama pengguna akhir

Pengguna akhir dapat meminta agen untuk melakukan tindakan tertentu atas nama pengguna, seperti menulis pesan di saluran Slack atau membuka permintaan pull di repositori GitHub. Dalam skenario ini, pengguna mendelegasikan otoritasnya kepada agen dengan memberikan izin secara eksplisit kepada agen untuk bertindak atas nama pengguna. Untuk menyiapkan izin pengguna dan pengambilan kredensial, Anda menggunakan 3-legged OAuth, yang melibatkan langkah-langkah berikut:

  1. Penyedia autentikasi mengalihkan pengguna untuk melakukan autentikasi ke layanan eksternal.
  2. Pengguna login dan menyetujui akses yang diperlukan agen.
  3. Layanan eksternal menampilkan kredensial ke penyedia autentikasi.

Untuk mengonfigurasi OAuth 3-legged bagi agen yang berjalan di GKE, administrator platform dan developer aplikasi harus mengikuti langkah-langkah berikut:

  1. Administrator platform menyiapkan penyedia autentikasi:
    1. Buat penyedia autentikasi OAuth 3-legged di pengelola autentikasi.
    2. Konfigurasi penyedia autentikasi untuk mengalihkan ke server otorisasi pihak ketiga.
    3. Konfigurasi layanan pihak ketiga untuk mengirim token akses pengguna ke penyedia autentikasi.
    4. Memberi otorisasi agen untuk mengakses penyedia autentikasi.
  2. Developer aplikasi mengubah aplikasi:
    1. Ubah kode agen untuk melakukan autentikasi menggunakan penyedia auth.
    2. Ubah kode aplikasi sisi klien untuk menangani login pengguna, pengalihan, dan kelanjutan percakapan.

Untuk mengetahui informasi selengkapnya tentang cara mengonfigurasi penyedia autentikasi dan mengubah aplikasi sisi klien dan agen, lihat Mengautentikasi menggunakan OAuth 3-legged dengan pengelola autentikasi.

Akses ke layanan eksternal sebagai identitas agen

Agen mungkin perlu mengakses layanan eksternal seperti ServiceNow atau Salesforce dengan menggunakan identitas agen itu sendiri. Misalnya, agen pengelolaan inventaris dapat memantau data penjualan dan memesan inventaris untuk menghindari masalah stok selama acara penjualan puncak. Dalam skenario ini, Anda menggunakan OAuth 2-legged, yang mencakup langkah-langkah berikut:

  1. Pengelola autentikasi meminta token akses dari layanan eksternal.
  2. Layanan eksternal memvalidasi permintaan dan menampilkan token akses ke pengelola autentikasi.

Untuk mengonfigurasi OAuth 2-legged bagi agen yang berjalan di GKE, Anda harus melakukan hal berikut:

  1. Administrator platform menyiapkan penyedia autentikasi:
    1. Dapatkan client ID OAuth, rahasia klien, dan endpoint token dari layanan eksternal.
    2. Buat penyedia autentikasi OAuth 2-legged di pengelola autentikasi yang memiliki informasi OAuth layanan eksternal.
    3. Memberi otorisasi agen untuk mengakses penyedia autentikasi.
  2. Developer aplikasi mengubah kode agen untuk melakukan autentikasi menggunakan penyedia autentikasi.

Untuk mengetahui informasi selengkapnya tentang cara mengonfigurasi penyedia autentikasi dan mengubah kode agen, lihat Mengautentikasi menggunakan OAuth 2-legged dengan pengelola autentikasi.

Akses ke API menggunakan kunci API

Anda dapat menyimpan kunci API di pengelola autentikasi agar digunakan agen untuk mengautentikasi ke API eksternal. Meskipun Anda dapat menyimpan kunci API di vault lain seperti Secret Manager, metode pengelola otorisasi memungkinkan Anda melacak dan mengelola akses agen ke kunci API di lokasi pusat. Untuk menyimpan dan menggunakan kunci API di auth manager, Anda melakukan hal berikut:

  1. Administrator platform menyiapkan penyedia autentikasi:
    1. Buat penyedia autentikasi kunci API di pengelola autentikasi.
    2. Buat dan simpan kunci API di penyedia autentikasi.
    3. Memberi otorisasi agen untuk mengakses penyedia autentikasi.
  2. Ubah kode agen untuk melakukan autentikasi menggunakan penyedia auth.

Untuk mengetahui informasi selengkapnya, lihat Melakukan autentikasi menggunakan kunci API dengan pengelola autentikasi.

Autentikasi antar-agen

Bagian ini menjelaskan alur kerja autentikasi lanjutan. Anda harus sudah memahami topik berikut:

  • Token Web JSON (JWT): token ID identitas agen adalah JWT yang ditandatangani.
  • Header JSON Object Signing and Encryption (JOSE): Token ID memiliki header JOSE yang menjelaskan algoritma dan kunci penandatanganan untuk token ID.
  • Kunci Web JSON (JWK): JWK digunakan untuk menandatangani token ID. JWK publik untuk kumpulan identitas agen dipublikasikan sebagai JSON Web Key Set (JWKS). Anda menggunakan kunci publik ini untuk memvalidasi token ID masuk dari agen lain.

Dalam arsitektur multi-agen, agen sering berkolaborasi dengan memanggil langsung agen peer atau layanan hilir. Anda dapat langsung membuat komunikasi antar-workload agen dengan menggunakan token identitas Agent Identity, yang merupakan JWT bertanda tangan yang dapat Anda peroleh dari server metadata GKE. Untuk mengautentikasi koneksi antara layanan agen, developer aplikasi melakukan hal berikut:

  1. Mendapatkan token ID identitas agen dari server metadata GKE untuk agen panggilan. Token ID ini harus menetapkan klaim aud ke endpoint agen penerima.
  2. Sertakan token ID di header permintaan Authorization: Bearer dari permintaan HTTP.
  3. Di agen penerima, validasi token ID yang masuk menggunakan JWK publik untuk kumpulan identitas agen dan berbagai parameter header dan isi dalam token ID.

Untuk mengetahui informasi selengkapnya tentang cara meminta, menggunakan, dan memvalidasi token ID dalam kode aplikasi Anda, lihat Mengautentikasi ke agen lain.

Autentikasi agen-ke-agen tidak memerlukan konfigurasi Google Cloud tambahan dari administrator platform, karena alur kerja ini melewati pemeriksaan otorisasi IAM. Sebaliknya, agen berkomunikasi langsung satu sama lain dan mengizinkan tindakan berdasarkan identitas agen.

Mengontrol akses ke Google Cloud resource untuk agen

Administrator keamanan dapat mengontrol resource yang dapat diakses oleh agen menggunakan kebijakan IAM yang mereferensikan ID utama agen. Untuk mengontrol akses ke resource untuk agen yang berjalan di GKE dan memiliki identitas agen, Anda menyertakan salah satu ID principal berikut dalam kebijakan IAM Anda:

  • Semua agen dalam domain tepercaya tertentu:

    principalSet://TRUST_DOMAIN/*

    Dalam ID ini, TRUST_DOMAIN adalah domain kepercayaan untuk hierarki resource Anda, yang bergantung pada apakah agen berada dalam project yang ada di organisasi:

    • Project yang berada dalam organisasi: agents.global.org-ORGANIZATION_ID.system.id.goog, dengan ORGANIZATION_ID adalah ID organisasi.
    • Project yang tidak berada dalam organisasi: agents.global.proj-PROJECT_NUMBER.system.id.goog, dengan PROJECT_NUMBER adalah nomor project dari project cluster.

  • Satu agen di domain tepercaya:

    principal://TRUST_DOMAIN/resources/container/projects/PROJECT_NUMBER/locations/CONTROL_PLANE_LOCATION/clusters/CLUSTER_NAME/ns/NAMESPACE_NAME/sa/SERVICEACCOUNT_NAME

    Dalam ID ini, parameter berikut mengidentifikasi agen tertentu:

    • PROJECT_NUMBER: nomor project dari project cluster.
    • CONTROL_PLANE_LOCATION: region atau zona bidang kontrol cluster.
    • CLUSTER_NAME: nama cluster tempat agen berada.
    • NAMESPACE_NAME: nama namespace Kubernetes tempat agen berada.
    • SERVICEACCOUNT_NAME: nama ServiceAccount Kubernetes yang digunakan oleh workload agen.

Untuk mengetahui informasi selengkapnya tentang cara menemukan ID prinsipal untuk agen GKE dan mengelola akses, lihat Mengelola akses ke Google Cloud API untuk agen.

Identitas Agen mendukung semua jenis kebijakan IAM, seperti kebijakan izin, kebijakan penolakan, dan kebijakan Principal Access Boundary (PAB). Untuk mengelola akses agen di cluster GKE yang menggunakan Identitas Agen, Anda menyertakan ID utama agen dalam jenis kebijakan yang sesuai. Untuk mengetahui informasi selengkapnya tentang cara mengonfigurasi setiap jenis kebijakan IAM, lihat topik berikut:

Melihat dan mengelola agen di seluruh Google Cloud

Jika developer aplikasi mendaftarkan agen mereka di Agent Registry, Anda dapat melihat agen GKE bersama agen lain yang Anda jalankan di Google Cloud. Agent Registry menampilkan identitas SPIFFE agen, tempat agen berjalan, dan informasi tambahan tentang agen. Semua permintaan API yang diautentikasi menggunakan Agent Identity akan menghasilkan log audit Agent Registry. Bergantung pada alur kerja autentikasi yang digunakan agen, Cloud Audit Logs memberikan informasi berikut:

  • Autentikasi menggunakan identitas agen sendiri: log audit yang dihasilkan mencakup ID utama agen, yang dapat Anda gunakan untuk menemukan cluster, namespace, dan ServiceAccount agen.
  • Operasi yang didelegasikan atas nama pengguna akhir: log audit yang dihasilkan mencakup informasi tentang pengguna akhir yang mengizinkan tindakan dan ID SPIFFE agen yang menjalankan panggilan. Atribusi identitas ini dalam log audit membantu Anda memvalidasi bahwa pengguna akhir mengizinkan tindakan tertentu.

Selain Cloud Audit Logs, developer aplikasi dapat mengonfigurasi beban kerja agen mereka untuk memancarkan trace, log, dan metrik yang dapat dilihat di Google Cloud Observability. Untuk mengetahui informasi selengkapnya tentang cara mengonfigurasi workload, lihat dokumen berikut:

Meningkatkan keamanan untuk agen GKE

Administrator keamanan dapat mengelola tindakan keamanan khusus agen secara terpisah dari batasan untuk jenis workload lainnya dengan merujuk identitas agen. Pertimbangkan langkah-langkah defensif berikut saat Anda menjalankan agen:

Batasan

  • Anda hanya dapat mendaftarkan Deployment secara otomatis di Agent Registry. Pengontrol workload lain dan Pod statis tidak mendukung pendaftaran otomatis.
  • Token akses identitas agen terikat hanya menggunakan cakupan OAuth https://www.googleapis.com/auth/cloud-platform. Anda tidak dapat menentukan cakupan yang berbeda untuk token akses terikat.
  • Pengambilan otomatis token akses atau token ID terikat hanya didukung di aplikasi Python yang menggunakan library google-auth versi 2.61.0 atau yang lebih baru. Jika Anda menggunakan Library Klien Cloud untuk Python, Anda harus menggunakan versi yang menyertakan library google-auth versi 2.61.0 atau yang lebih baru.
  • Library Klien Cloud tertentu mungkin tidak otomatis merutekan permintaan Anda ke endpoint mTLS.
  • Untuk autentikasi agent-to-agent, Anda hanya dapat menggunakan token ID terikat untuk mengautentikasi antar-agen yang berada dalam domain kepercayaan identitas agen yang sama.

Langkah berikutnya