Jika arsitektur Anda menggunakan banyak layanan, mungkin diperlukan komunikasi antarlayanan, menggunakan cara asinkron atau sinkron. Banyak dari layanan ini mungkin bersifat pribadi sehingga memerlukan kredensial untuk mengaksesnya.
Untuk komunikasi asinkron, Anda dapat menggunakan layanan Google Cloud berikut:
- Cloud Tasks untuk komunikasi asinkron one-to-one
- Pub/Sub untuk komunikasi asinkron one-to-many, one-to-one, dan many-to-one
- Cloud Scheduler untuk komunikasi asinkron yang terjadwal secara berkala
- Eventarc untuk komunikasi berbasis peristiwa
Pada semua kasus ini, layanan yang digunakan bertindak untuk mengelola interaksi dengan layanan penerima berdasarkan konfigurasi yang Anda siapkan.
Namun, untuk komunikasi sinkron, layanan Anda akan memanggil layanan lain
secara langsung, melalui HTTP, menggunakan URL endpoint-nya. Untuk kasus penggunaan ini, Anda harus memastikan
bahwa setiap layanan hanya dapat membuat permintaan ke layanan
tertentu. Misalnya, jika Anda memiliki layanan login
, layanan tersebut harus dapat
mengakses layanan user-profiles
, tetapi tidak dapat mengakses layanan search
.
Dalam situasi ini, Google merekomendasikan agar Anda menggunakan IAM dan identitas layanan berdasarkan akun layanan yang dikelola pengguna per layanan yang telah diberi kumpulan izin minimum yang diperlukan untuk melakukan pekerjaannya.
Selain itu, permintaan harus menunjukkan bukti identitas layanan panggilan. Untuk melakukannya, konfigurasikan layanan panggilan Anda agar menambahkan token ID OpenID Connect yang ditandatangani Google sebagai bagian dari permintaan.
Menyiapkan akun layanan
Untuk menyiapkan akun layanan, konfigurasikan layanan penerima untuk menerima permintaan dari
layanan panggilan dengan menjadikan akun layanan dari layanan panggilan sebagai akun utama
pada layanan penerima. Kemudian, Anda memberikan peran Cloud Run Invoker (roles/run.invoker
)
untuk akun layanan tersebut. Untuk melakukan kedua tugas tersebut, ikuti petunjuk di tab yang sesuai:
UI Konsol
Buka Konsol Google Cloud:
Pilih layanan penerima.
Klik Tampilkan Panel Info di pojok kanan atas untuk menampilkan tab Izin.
Klik Tambahkan akun utama.
Masukkan identitas layanan panggilan. Biasanya berupa alamat email, secara default
PROJECT_NUMBER-compute@
.Pilih peran
Cloud Run Invoker
dari menu drop-down Pilih peran.Klik Simpan.
gcloud
Gunakan perintah gcloud run services add-iam-policy-binding
:
gcloud run services add-iam-policy-binding RECEIVING_SERVICE \ --member='serviceAccount:CALLING_SERVICE_IDENTITY' \ --role='roles/run.invoker'
dengan RECEIVING_SERVICE
sebagai nama layanan penerima,
dan CALLING_SERVICE_IDENTITY
adalah alamat email
akun layanan, secara default
PROJECT_NUMBER-compute@
.
Terraform
Untuk mempelajari cara menerapkan atau menghapus konfigurasi Terraform, lihat Perintah dasar Terraform.
Kode Terraform berikut membuat layanan Cloud Run awal yang ditujukan untuk publik.
Ganti us-docker.pkg.dev/cloudrun/container/hello
dengan referensi ke image container Anda.
Kode Terraform berikut menjadikan layanan awal bersifat publik.
Kode Terraform berikut membuat layanan Cloud Run kedua yang ditujukan untuk pribadi.
Ganti us-docker.pkg.dev/cloudrun/container/hello
dengan referensi ke image container Anda.
Kode Terraform berikut membuat layanan kedua menjadi pribadi.
Kode Terraform berikut digunakan untuk membuat akun layanan.
Kode Terraform berikut memungkinkan layanan yang tercantum ke layanan akun memanggil layanan Cloud Run pribadi yang awal.
Memperoleh dan mengonfigurasi token ID
Setelah Anda memberikan peran yang sesuai ke akun layanan panggilan, ikuti langkah-langkah berikut:
Ambil Token ID yang ditandatangani Google menggunakan salah satu metode yang dijelaskan di bagian berikut. Tetapkan klaim audiens (
aud
) ke URL layanan penerima atau audiens kustom yang dikonfigurasi. Jika Anda tidak menggunakan audiens kustom, nilaiaud
harus tetap menjadi URL layanan, bahkan saat membuat permintaan ke tag traffic tertentu.Tambahkan token ID yang Anda ambil dari langkah sebelumnya ke salah satu header berikut dalam permintaan ke layanan penerima:
- Header
Authorization: Bearer ID_TOKEN
. - Header
X-Serverless-Authorization: Bearer ID_TOKEN
. Anda dapat menggunakan header ini jika aplikasi sudah menggunakan headerAuthorization
untuk otorisasi kustom. Tindakan ini akan menghapus tanda tangan sebelum meneruskan token ke container pengguna.
- Header
Untuk mengetahui cara lain mendapatkan token ID yang tidak dijelaskan di halaman ini, baca Metode untuk mendapatkan token ID.
Menggunakan library autentikasi
Cara termudah dan paling andal untuk memperoleh dan mengonfigurasi proses token ID adalah dengan menggunakan library autentikasi.
Kode ini dapat berfungsi di lingkungan apa pun, bahkan di luar Google Cloud,
tempat library dapat memperoleh kredensial autentikasi untuk akun
layanan, termasuk lingkungan
yang mendukung Kredensial Default Aplikasi lokal.
Untuk menetapkan
Kredensial Default Aplikasi,
download file kunci akun layanan, dan
tetapkan variabel lingkungan GOOGLE_APPLICATION_CREDENTIALS
ke jalur
file kunci akun layanan. Untuk informasi selengkapnya, lihat
Cara kerja Kredensial Default Aplikasi.
Kode ini tidak berfungsi untuk mendapatkan kredensial autentikasi untuk akun pengguna.
Node.js
Python
Go
Java
Menggunakan server metadata
Jika karena alasan tertentu Anda tidak dapat menggunakan library autentikasi, Anda dapat mengambil token ID dari Server metadata Compute saat container Anda sedang berjalan di Cloud Run. Perlu diperhatikan bahwa metode ini tidak berfungsi di luar Google Cloud, termasuk dari komputer lokal Anda.
curl "http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/identity?audience=[AUDIENCE]" \
-H "Metadata-Flavor: Google"
Dengan AUDIENCE adalah URL layanan yang Anda panggil atau audiens kustom yang dikonfigurasi.
Tabel berikut merangkum bagian-bagian utama dari permintaan kueri metadata:
Komponen | Deskripsi |
---|---|
URL root | Semua nilai metadata didefinisikan sebagai sub-jalur di bawah URL root berikut: http://metadata.google.internal/computeMetadata/v1 |
Header permintaan | Header berikut harus ada dalam setiap permintaan: Metadata-Flavor: Google Header ini menunjukkan bahwa permintaan dikirim dengan tujuan mengambil nilai metadata, bukan secara tidak sengaja mengambilnya dari sumber yang tidak aman, dan memungkinkan server metadata menampilkan data yang Anda minta. Jika Anda tidak memberikan header ini, server metadata akan menolak permintaan Anda. |
Untuk mengetahui panduan menyeluruh terkait aplikasi yang menggunakan teknik autentikasi antarlayanan ini, ikuti tutorial mengamankan layanan Cloud Run.
Menggunakan workload identity federation dari luar Google Cloud
Jika lingkungan Anda menggunakan penyedia identitas yang didukung oleh workload identity federation, Anda dapat menggunakan metode berikut untuk melakukan autentikasi dengan aman ke layanan Cloud Run dari luar Google Cloud:
Siapkan akun layanan seperti yang dijelaskan dalam Menyiapkan akun layanan di halaman ini.
Konfigurasikan penggabungan workload identity untuk penyedia identitas seperti yang dijelaskan dalam Mengonfigurasi workload identity federation.
Ikuti petunjuk di bagian Memberikan izin identitas eksternal untuk meniru identitas akun layanan.
Gunakan REST API untuk mendapatkan token yang memiliki masa aktif singkat, tetapi alih-alih memanggil
generateAccessToken
untuk mendapatkan token akses, panggilgenerateIdToken
untuk mendapatkan token ID.Misalnya, menggunakan cURL:
ID_TOKEN=$(curl -0 -X POST https://iamcredentials.googleapis.com/v1/projects/-/serviceAccounts/SERVICE_ACCOUNT:generateIdToken \ -H "Content-Type: text/json; charset=utf-8" \ -H "Authorization: Bearer $STS_TOKEN" \ -d @- <<EOF | jq -r .token { "audience": "SERVICE_URL" } EOF ) echo $ID_TOKEN
Dengan
SERVICE_ACCOUNT
adalah alamat email akun layanan tempat workload identity pool dikonfigurasi untuk diakses, danSERVICE_URL
adalah URL layanan Cloud Run yang Anda panggil. Nilai ini harus tetap sebagai URL layanan, bahkan saat membuat permintaan ke tag traffic tertentu.$STS_TOKEN
adalah token Layanan Token Keamanan yang Anda terima pada langkah sebelumnya di petunjuk Workload Identity Federation.
Anda dapat menyertakan token ID dari langkah sebelumnya dalam permintaan ke
layanan menggunakan header Authorization: Bearer ID_TOKEN
atau header X-Serverless-Authorization: Bearer ID_TOKEN
. Jika
kedua header disediakan, hanya header X-Serverless-Authorization
yang akan dicentang.
Menggunakan kunci akun layanan yang didownload dari luar Google Cloud
Jika Workload Identity Federation tidak sesuai dengan lingkungan Anda, Anda dapat menggunakan kunci akun layanan yang didownload untuk melakukan autentikasi dari luar Google Cloud. Perbarui kode klien Anda untuk menggunakan library autentikasi seperti yang dijelaskan sebelumnya dengan Kredensial Default Aplikasi.
Anda dapat memperoleh token ID yang ditandatangani Google menggunakan JWT yang ditandatangani sendiri, tetapi cara ini cukup rumit dan berpotensi rentan mengalami error. Langkah-langkah dasarnya adalah sebagai berikut:
Tanda tangani sendiri JWT akun layanan dengan klaim
target_audience
ditetapkan ke URL layanan penerima atau audiens kustom yang dikonfigurasi. Jika tidak menggunakan domain kustom, nilaitarget_audience
harus tetap sebagai URL layanan, meski saat membuat permintaan ke tag traffic khusus.Tukar JWT yang ditandatangani sendiri dengan token ID yang ditandatangani Google, yang harus memiliki klaim
aud
yang ditetapkan ke URL sebelumnya.Sertakan token ID dalam permintaan ke layanan menggunakan header
Authorization: Bearer ID_TOKEN
atau headerX-Serverless-Authorization: Bearer ID_TOKEN
. Jika kedua header disediakan, hanya headerX-Serverless-Authorization
yang akan dicentang.
Menerima permintaan yang diautentikasi
Dalam layanan pribadi penerima, Anda dapat mengurai header otorisasi untuk menerima informasi yang dikirim oleh token Pemilik.
Python
Langkah selanjutnya
- Pelajari validasi token ID lebih lanjut