Workload identity federation memungkinkan aplikasi yang berjalan di luar Google Cloud meniru akun layanan menggunakan kredensial dari penyedia identitas eksternal.
Using workload identity federation dapat membantu Anda meningkatkan keamanan dengan memungkinkan aplikasi menggunakan mekanisme autentikasi yang disediakan oleh lingkungan eksternal dan dapat membantu mengganti kunci akun layanan.
Untuk menggunakan workload identity federation dengan aman, Anda harus mengonfigurasinya dengan cara yang melindungi Anda dari ancaman berikut:
- Spoofing: Pihak tidak bertanggung jawab dapat mencoba memalsukan identitas pengguna lain untuk mendapatkan akses tidak sah ke resource Google Cloud.
- Eskalasi akses: Pihak tidak bertanggung jawab dapat memanfaatkan workload identity federation untuk mendapatkan akses ke resource yang tidak dapat mereka akses.
- Non-repudiasi: Pihak tidak bertanggung jawab dapat menyembunyikan identitas dan tindakannya dengan menggunakan kredensial eksternal yang mempersulit pelacakan tindakan pada mereka.
Panduan ini menyajikan praktik terbaik untuk memutuskan kapan harus menggunakan workload identity federation, dan cara mengonfigurasinya dengan cara yang membantu Anda meminimalkan risiko.
Kapan harus menggunakan workload identity federation
Praktik terbaik:
Menggunakan workload identity federation untuk aplikasi yang memiliki akses ke kredensial ambienMenggunakan pertukaran token tambahan untuk menggunakan kredensial ambien yang tidak didukung oleh workload identity federation.
Menggunakan workload identity federation untuk mengurangi jumlah kredensial yang memerlukan rotasi.
Menggunakan workload identity federation untuk aplikasi yang memiliki akses ke kredensial ambien
Aplikasi yang berjalan di penyedia cloud selain Google Cloud sering kali memiliki akses ke kredensial ambien. Ini adalah kredensial yang dapat diperoleh aplikasi tanpa harus melakukan autentikasi tambahan. Beberapa contoh di antaranya:
- Di AWS, aplikasi yang di-deploy di EC2 dapat menggunakan profil instance untuk mengambil peran dan mendapatkan kredensial sementara.
- Di Azure, aplikasi dapat menggunakan identitas terkelola untuk mendapatkan token akses.
- Di GitHub Actions, alur kerja dapat memperoleh token ID yang mencerminkan identitas tugas deployment.
Jika kredensial ambien adalah token OpenID Connect (OIDC), pernyataan SAML, atau kredensial AWS, Anda dapat mengonfigurasi workload identity federation agar aplikasi dapat menukar kredensial ini dengan token akses Google dengan masa berlaku singkat. Jika kredensial ambien menggunakan format yang berbeda, Anda mungkin dapat menukarnya dengan token OIDC atau pernyataan SAML terlebih dahulu, lalu menggunakannya untuk workload identity federation.
Gunakan workload identity federation setiap kali aplikasi perlu mengakses Google Cloud dan memiliki akses ke kredensial ambien.
Menggunakan pertukaran token tambahan untuk menggunakan kredensial ambien yang tidak didukung oleh workload identity federation
Dalam beberapa kasus, aplikasi mungkin memiliki akses ke kredensial ambien, tetapi jenis kredensial tersebut tidak didukung oleh workload identity federation. Dalam kasus ini, periksa apakah pertukaran token tambahan memungkinkan Anda mengonversi kredensial ambien menjadi jenis kredensial yang dapat Anda gunakan untuk workload identity federation.
Misalnya, jika aplikasi Anda berjalan di lingkungan Active Directory, mungkin memiliki akses ke kredensial Kerberos. Jika memiliki penyedia identitas seperti Active Directory Federation Services (AD FS) di lingkungan Anda yang mendukung Autentikasi Windows Terintegrasi, Anda dapat menggunakan kredensial Kerberos ini untuk mengautentikasi ke penyedia identitas dan mendapatkan token akses OAuth yang menggunakan format JWT. Dengan menggunakan token akses dan workload identity federation, Anda dapat membiarkan aplikasi melakukan pertukaran token kedua untuk mendapatkan kredensial Google dengan masa berlaku singkat.
Mengaitkan pertukaran token meningkatkan kompleksitas dan mungkin menimbulkan dependensi tambahan, tetapi dapat membebaskan Anda dari keharusan mengelola dan mengamankan kunci akun layanan.
Menggunakan workload identity federation untuk mengurangi jumlah kredensial yang memerlukan rotasi
Aplikasi yang terintegrasi dengan penyedia identitas OpenID atau SAML sering menggunakan rahasia klien (atau bentuk secret lainnya) untuk mengautentikasi ke penyedia identitas. Biasanya, secret ini disimpan sebagai bagian dari konfigurasi aplikasi. Agar aplikasi tersebut dapat mengakses Google Cloud, Anda harus memutuskan antara:
- Membuat kunci akun layanan dan menyimpannya bersama secret lainnya.
- Menggunakan token yang dikeluarkan oleh penyedia identitas yang ada dan menukarnya dengan kredensial Google menggunakan workload identity federation.
Opsi pertama memerlukan dua secret, tetapi opsi kedua hanya memerlukan satu secret. Mengurangi jumlah secret dapat membantu Anda menyederhanakan rotasi secret, yang nantinya dapat membantu meningkatkan keamanan.
Melindungi dari ancaman spoofing
workload identity pool tidak berisi identitas atau akun pengguna, yang membuatnya berbeda dari direktori pengguna seperti Cloud Identity. Sebaliknya, workload identity pool merepresentasikan tampilan yang menampilkan identitas dari penyedia identitas eksternal sehingga dapat digunakan sebagai IAM utama.
Bergantung pada cara Anda mengonfigurasi workload identity pool dan penyedianya, identitas eksternal yang sama mungkin direpresentasikan sebagai beberapa IAM utama yang berbeda, atau beberapa identitas eksternal dapat dipetakan ke IAM utama yang sama. Ambiguitas tersebut dapat memungkinkan pihak tidak bertanggung jawab untuk meluncurkan serangan spoofing.
Bagian berikut menjelaskan praktik terbaik yang membantu Anda menghindari pemetaan yang ambigu, dan mengurangi risiko ancaman spoofing.
Praktik terbaik:
Gunakan kondisi atribut saat melakukan penggabungan dengan GitHub atau penyedia identitas multi-tenant lainnya.Gunakan project khusus untuk mengelola penyedia dan kumpulan workload identity.
Gunakan batasan kebijakan organisasi untuk menonaktifkan pembuatan penyedia kumpulan workload identity di project lain.
Gunakan satu penyedia per kumpulan identitas workload untuk menghindari konflik subjek.
Hindari melakukan federasi dengan penyedia identitas yang sama dua kali.
Melindungi endpoint metadata OIDC penyedia identitas Anda.
Gunakan URL penyedia kumpulan workload identity sebagai audiens.
Gunakan atribut yang tidak dapat diubah dalam pemetaan atribut.
Gunakan atribut yang tidak dapat digunakan kembali dalam pemetaan atribut.
Jangan izinkan pemetaan atribut diubah.
Jangan mengandalkan atribut yang tidak stabil atau tidak otoritatif.
Gunakan kondisi atribut saat melakukan federasi dengan GitHub atau penyedia identitas multi-tenant lainnya
Gabungan identitas workload tidak mempertahankan direktori akun pengguna;
tetapi menerapkan
identitas berbasis klaim:
Akibatnya, saat dua token dikeluarkan oleh penyedia identitas (IdP) yang sama dan klaim keduanya dipetakan ke nilai
google.subject yang sama, kedua token tersebut diasumsikan untuk mengidentifikasi pengguna yang sama.
Untuk mengetahui IdP mana yang mengeluarkan token, federasi workload akan memeriksa dan memverifikasi URL penerbit token.
Beberapa penyedia, seperti GitHub dan Terraform Cloud, menggunakan URL penerbit tunggal di semua tenantnya. Untuk penyedia ini, URL penerbit mengidentifikasi semua GitHub atau Terraform Cloud, bukan organisasi GitHub atau Terraform Cloud tertentu.
Jika Anda menggunakan penyedia identitas ini, workload identity tidak cukup untuk memeriksa URL penerbit token guna memastikan bahwa token tersebut berasal dari sumber tepercaya dan bahwa klaimnya dapat dipercaya. Sebaiknya konfigurasi kondisi atribut penggabungan identitas workload untuk memeriksa apakah token berasal dari tenant tepercaya atau, untuk GitHub atau Terraform Cloud, organisasi tepercaya.
Untuk mempelajari lebih lanjut, lihat mengonfigurasi kondisi atribut.
Menggunakan project khusus untuk mengelola workload identity pool dan penyedia workload
Daripada mengelola workload identity pools dan penyedia di beberapa project, gunakan satu project khusus untuk mengelola workload identity pools dan penyedia workload Menggunakan proyek khusus membantu Anda untuk:
- Memastikan hanya penyedia identitas tepercaya yang digunakan untuk workload identity federation.
- Mengontrol akses secara terpusat ke konfigurasi workload identity pool dan penyedia workload.
- Menerapkan pemetaan dan kondisi atribut yang konsisten di semua project dan aplikasi.
Anda dapat menggunakan batasan kebijakan organisasi untuk menerapkan disiplin penggunaan project khusus untuk mengelola workload identity pools dan penyedia workload.
Menggunakan batasan kebijakan organisasi untuk menonaktifkan pembuatan penyedia workload identity pool di project lain
Pengguna yang memiliki izin untuk membuat workload identity pool providers dapat membuat workload identity pools dan penyedia workload yang mungkin redundan dengan yang Anda kelola dalam project khusus.
Anda dapat mencegah pembuatan workload identity pool providers baru menggunakan
constraints/iam.workloadIdentityPoolProviders
batasan kebijakan organisasi dengan aturan yang ditetapkan ke Deny All.
Terapkan batasan ini di akar hierarki organisasi untuk menolak pembuatan workload identity pool providers baru secara default. Membuat pengecualian untuk project tempat Anda ingin mengizinkan pengelolaan workload identity pool dan penyedia workload dengan menerapkan batasan kebijakan yang mengizinkan akun AWS atau penyedia OIDC tertentu yang tepercaya.
Menggunakan satu penyedia per workload identity pool untuk menghindari konflik subjek
Workload identity federation memungkinkan Anda membuat lebih dari satu penyedia per workload identity pool. Menggunakan beberapa penyedia dapat berguna jika identitas dikelola oleh beberapa penyedia. Namun, Anda ingin menyembunyikan kompleksitas ini dari workload yang berjalan di Google Cloud.
Menggunakan beberapa penyedia akan menimbulkan risiko benturan subjek, dengan
pemetaan atribut untuk google.subject dari satu penyedia akan menampilkan nilai yang sama
dengan pemetaan atribut untuk penyedia lain. Akibat konflik semacam ini
beberapa identitas eksternal dipetakan ke IAM utama yang sama, sehingga
identitas eksternal tidak dapat dibedakan di Cloud Audit Logs.
Untuk menghindari konflik subjek, gunakan satu penyedia per workload identity pool. Jika Anda perlu melakukan federasi dengan beberapa penyedia, buat beberapa workload identity pool, masing-masing menggunakan satu workload identity provider.
Menghindari melakukan federasi dengan penyedia identitas yang sama dua kali
Anda dapat bergabung dengan penyedia identitas yang sama beberapa kali dengan membuat beberapa workload identity pool providers yang menggunakan konfigurasi yang sama atau serupa. Jika penyedia ini termasuk dalam workload identity pool yang sama, konfigurasi tersebut dapat menyebabkan konflik subjek. Jika penyedia termasuk dalam workload identity pool yang berbeda, konflik subjek tidak dapat terjadi dan identitas eksternal yang sama akan direpresentasikan sebagai IAM utama yang berbeda.
Memetakan satu identitas eksternal ke beberapa IAM utama akan lebih sulit untuk menganalisis resource mana yang dapat diakses oleh identitas eksternal tertentu. Ambiguitas tersebut juga dapat meningkatkan risiko saat mencoba mencabut akses: Administrator mungkin mencabut akses untuk satu akun utama, tetapi mungkin tidak mengetahui keberadaan akun utama lain, sehingga secara tidak sengaja menyebabkan identitas eksternal mempertahankan akses.
Untuk meminimalkan risiko ambiguitas, hindari federasi dengan penyedia identitas yang sama lebih dari sekali. Sebagai gantinya, buat workload identity pool dan penyedia workload tunggal, lalu gunakan pemetaan dan kondisi atribut yang memastikan bahwa workload tersebut dapat digunakan untuk semua identitas eksternal yang memerlukan akses ke resource Google Cloud.
Melindungi endpoint metadata OIDC penyedia identitas Anda
Saat Anda bergabung dengan penyedia OpenID Connect, workload identity federation secara berkala mendownload metadata OIDC dari penyedia identitas Anda. Workload identity federation menggunakan metadata IdP dan Set Kunci Web JSON (JWKS) untuk memvalidasi token.
Untuk memastikan keaslian, komunikasi dengan penyedia identitas Anda akan diamankan menggunakan TLS. Jika penyedia Anda di-deploy di belakang load balancer atau reverse proxy yang menghentikan TLS, koneksi TLS akan memastikan keaslian load balancer atau reverse proxy, tetapi bukan dari penyedia identitas sebenarnya.
Pihak tidak bertanggung jawab mungkin dapat memanfaatkan setup ini dengan meluncurkan serangan man-in-the-middle (MITM) saat mereka mengonfigurasi ulang load balancer untuk mengizinkannya melewati permintaan JWKS ke endpoint berbahaya yang menyajikan serangkaian kunci yang berbeda. Menukar JWKS memungkinkan pihak tidak bertanggung jawab menandatangani token yang dianggap valid oleh workload identity federation dan dapat memungkinkan mereka untuk memalsukan identitas pengguna lain.
Untuk melindungi dari pertukaran JWKS, pastikan IdP Anda di-deploy dengan cara melindungi IdP Anda dari serangan MITM.
Gunakan URL workload identity pool sebagai audiens
Saat Anda bergabung dengan penyedia OpenID Connect, workload identity federation
memverifikasi bahwa audiens token (dienkode dalam klaim aud) cocok dengan
setelan audiens yang diizinkan dari penyedia tersebut. Demikian pula, saat Anda bergabung dengan
penyedia SAML, workload identity federation akan memeriksa apakah pernyataan SAML
menentukan pembatasan audiens that yang cocok dengan audiens yang diharapkan.
Secara default, workload identity federation mengharapkan audiens cocok dengan URL
https://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/providers/PROVIDER_ID
yang secara unik mengidentifikasi penyedia workload identity pool. Mewajibkan token
dan pernyataan untuk menggunakan URL ini sebagai audience dapat membantu mengurangi risiko
serangan
confused deputy. Dalam serangan semacam itu, pihak tidak bertanggung jawab menampilkan token atau pernyataan SAML untuk
workload identity federation yang tidak dimaksudkan digunakan untuk workload identity
federation, tetapi untuk beberapa API lainnya.
Mewajibkan token atau pernyataan untuk memuat URL dari target workload identity pool provider yang membantu Anda memastikan bahwa klien hanya dapat menggunakan token dan pernyataan yang secara khusus dikeluarkan untuk workload identity federation.
Menggunakan atribut yang tidak dapat diubah dalam pemetaan atribut
Untuk memberikan izin identitas eksternal guna meniru identitas akun layanan, anda harus membuat binding IAM yang mereferensikan identitas eksternal berdasarkan subjek, grup, atau atribut khusus. Subjek, grup, dan atribut khusus dari identitas eksternal berasal dari atribut yang diteruskan penyedia identitas eksternal ke workload identity federation selama pertukaran token.
Beberapa penyedia identitas mengizinkan pengguna untuk mengubah beberapa atribut mereka sendiri. Misalnya, pengguna mungkin diizinkan untuk mengubah alamat email atau alias mereka. Jika binding IAM Anda merujuk pada atribut yang dapat diubah, pengguna mungkin kehilangan akses ke resource tertentu secara tidak sengaja karena mengubah profil pengguna mereka. Atau lebih buruk lagi, pihak tidak bertanggung jawab mungkin dapat memperoleh akses tidak sah ke resource lain dengan sengaja mengubah atribut penggunanya agar cocok dengan binding IAM yang ada.
Untuk melindungi dari ancaman spoofing ini, batasi pemetaan atribut ke atribut yang tidak dapat dimodifikasi oleh pengguna, atau tidak dapat dimodifikasi sama sekali.
Menggunakan atribut yang tidak dapat digunakan kembali dalam pemetaan atribut
Jika Anda memberikan izin identitas eksternal untuk meniru identitas akun layanan dan kemudian menghapus pengguna di penyedia identitas eksternal, binding IAM akun layanan akan tetap berlaku.
Jika nantinya Anda menambahkan pengguna baru ke penyedia identitas eksternal, dan pengguna tersebut berbagi atribut tertentu dengan pengguna yang dihapus sebelumnya (misalnya, alamat email yang sama), pengguna lama dan baru tidak akan dapat dibedakan untuk workload identity federation. Akibatnya, binding IAM yang hanya merujuk ke pengguna lama mungkin juga berlaku untuk pengguna baru.
Untuk mencegah ambiguitas semacam itu, gunakan pemetaan atribut yang secara eksklusif mengandalkan atribut yang tidak dapat digunakan kembali dari waktu ke waktu, seperti ID pengguna yang unik.
Jika kebijakan perusahaan Anda mengizinkan penggunaan kembali atribut seperti alamat email, hindari penggunaan atribut ini dalam pemetaan atribut dan gunakan atribut yang berbeda, yang dijamin akan unik dari waktu ke waktu.
Jangan izinkan perubahan pemetaan atribut
Penggunaan workload identity federation pemetaan atribut untuk memilih atribut mana yang disediakan oleh penyedia identitas eksternal yang harus disematkan ke token STS, dan bagaimana nama atribut harus diterjemahkan. Mengonfigurasi pemetaan atribut adalah langkah penting untuk menyiapkan hubungan kepercayaan antara penyedia identitas eksternal dan Google Cloud.
Pemetaan atribut juga penting bagi keamanan penggunaan workload identity federation: Jika Anda telah memberikan prinsipal federasi atau prinsipal, menetapkan kemampuan untuk meniru akun layanan, lalu mengubah pemetaan atribut, Anda dapat mengubah pengguna mana yang memiliki akses ke akun layanan.
Mengubah pemetaan atribut memerlukan
izin iam.googleapis.com/workloadIdentityPoolProviders.update. Peran
yang berisi izin ini meliputi:
- (
roles/owner) Pemilik - Admin IAM Workload Identity Pool
(
roles/iam.workloadIdentityPoolAdmin)
Jika pihak tidak bertanggung jawab memiliki izin untuk mengubah pemetaan atribut, mereka mungkin dapat mengubah aturan pemetaan dengan cara yang memungkinkan mereka memalsukan identitasnya dan mendapatkan akses ke akun layanan. Untuk mencegah modifikasi berbahaya tersebut, pastikan hanya beberapa pengguna administratif yang memiliki izin untuk mengubah pemetaan atribut.
Pertimbangkan untuk membuat project Google Cloud khusus untuk mengelola workload identity pool, yang membantu Anda membatasi risiko pengguna secara tidak sengaja diberi salah satu peran ini pada level yang lebih tinggi dalam hierarki resource.
Jangan mengandalkan atribut yang tidak stabil atau otoritatif
Penyedia identitas menggunakan atribut untuk mengomunikasikan informasi tentang pengguna terautentikasi. Penyedia identitas biasanya menjamin bahwa beberapa atribut bersifat otoritatif, tetapi yang lainnya tidak. Misalnya, penyedia identitas eksternal mungkin menyematkan nama pengguna dan user ID dalam token OIDC. Kedua atribut secara unik mengidentifikasi pengguna dan mungkin tampak dapat saling dipertukarkan. Namun, penyedia identitas eksternal dapat menjamin bahwa ID pengguna stabil dan otoritatif, tetapi mengizinkan nama pengguna diubah.
Jika pemetaan atribut Anda mengandalkan atribut yang tidak stabil atau otoritatif, pihak tidak bertanggung jawab mungkin dapat memalsukan identitas mereka dengan mengubah profil pengguna mereka di penyedia identitas eksternal. Misalnya, mereka mungkin mengubah nama penggunanya menjadi nama pengguna yang baru saja dihapus dihapus di penyedia identitas eksternal, tetapi masih memiliki akses ke akun layanan di Google Cloud.
Untuk mencegah serangan spoofing tersebut, pastikan pemetaan atribut Anda hanya mengandalkan atribut yang dijamin oleh penyedia identitas eksternal sebagai stabil dan otoritatif.
Melindungi dari ancaman non-repudiasi
Setiap kali Anda melihat aktivitas mencurigakan yang memengaruhi salah satu resource Anda di Google Cloud, Log Audit Cloud merupakan sumber informasi penting untuk mencari tahu kapan aktivitas tersebut terjadi dan pengguna mana yang terlibat.
Ketika sebuah aplikasi menggunakan workload identity federation, aplikasi tersebut menyamar sebagai akun layanan. Di Cloud Audit Logs, setiap aktivitas yang dilakukan oleh aplikasi dikaitkan ke akun layanan yang ditiru. Untuk merekonstruksi rangkaian peristiwa lengkap yang menyebabkan aktivitas tersebut, Anda harus dapat menghubungkan Log Audit Cloud dengan log penyedia identitas, sehingga Anda dapat mengetahui identitas eksternal mana yang terlibat, dan mengapa suatu aktivitas dilakukan.
Bagian ini menjelaskan praktik terbaik yang dapat membantu Anda menjaga jejak audit yang tidak dapat disangkal.
Mengaktifkan log akses data untuk API IAM
Untuk membantu Anda mengidentifikasi dan memahami skenario peniruan akun layanan,
seperti Compute Engine menyertakan bagian serviceAccountDelegationInfo
di Log Audit Cloud. Jika aplikasi menggunakan workload identity federation, bagian
ini menyertakan subjek
dari prinsipal yang digunakan untuk menyamar sebagai akun layanan.
Tidak semua layanan menyertakan detail peniruan identitas di Cloud Audit Logs. Untuk membantu menjaga jejak audit yang tidak dapat disangkal, Anda juga harus mencatat semua peristiwa peniruan identitas dengan mengaktifkan log akses data untuk Security Token Service API dan Identity and Access Management API. Mengaktifkan log ini untuk semua project Cloud yang berisi workload identity pools atau kun layanan yang digunakan untuk workload identity federation.
Dengan mengaktifkan log ini, Anda memastikan bahwa sebuah entri ditambahkan ke Log Audit Cloud setiap kali aplikasi menggunakan workload identity federation untuk menukar kredensial eksternal dan meniru identitas akun layanan.
Menggunakan pemetaan subjek unik
The Subjek utama yang digunakan di bagian serviceAccountDelegationInfo dalam
entri Cloud Audit Logs ditentukan oleh pemetaan atribut penyedia
workload identity pool Anda untukgoogle.subject.
Jika Anda menemukan aktivitas mencurigakan dan perlu mencari tahu identitas eksternal
mana yang terlibat, Anda harus dapat mencari identitas eksternal berdasarkan nilai
google.subject yang sesuai.
Demikian pula, ketika identitas eksternal disusupi dan Anda perlu mencari tahu apakah identitas digunakan untuk mengakses resource Google Cloud, Anda harus dapat menemukan entri Log Audit Cloud yang sesuai dengan identitas eksternal.
Saat Anda menentukan pemetaan atribut
untuk penyedia workload identity pool, pilih pemetaan unik untuk google.subject sehingga:
- Identitas eksternal dipetakan ke tepat satu nilai
google.subject. - Nilai
google.subjectdipetakan hanya ke satu identitas eksternal. - Anda dapat mencari identitas eksternal berdasarkan nilai
google.subject-nya.
Menggunakan pemetaan atribut yang memenuhi kriteria keunikan ini membantu
memastikan bahwa Anda dapat mencari identitas eksternal berdasarkan nilai google.subject,
dan sebaliknya.
Melindungi dari ancaman eskalasi akses
Untuk menerapkan prinsip hak istimewa terendah saat menggunakan workload identity federation, Anda harus:
- batasi jumlah identitas eksternal yang dapat meniru identitas akun layanan
- membatasi resource yang dapat diakses akun layanan
Konfigurasi yang terlalu permisif dapat menyebabkan situasi ketika pihak tidak bertanggung jawab dapat menggunakan identitas eksternal untuk mengeskalasi hak istimewanya dan mengakses resource yang seharusnya tidak dapat diakses.
Bagian berikut memberikan praktik terbaik yang dapat membantu Anda melindungi dari ancaman eskalasi hak istimewa.
Praktik terbaik:
Menggunakan akun layanan yang berada dalam project yang sama dengan resource yang perlu Anda akses.Menggunakan akun layanan khusus untuk setiap aplikasi..
Menghindari pemberian akses ke semua anggota kumpulan.
Menggunakan akun layanan yang berada dalam project yang sama dengan resource yang perlu Anda akses
Saat klien menggunakan workload identity federation dengan menggunakan library klien atau REST API, proses ini mengikuti tiga langkah:
- Dapatkan kredensial dari penyedia identitas tepercaya.
- Tukarkan kredensial dengan token dari Security Token Service.
- Gunakan token dari Layanan Token Keamanan untuk meniru identitas akun layanan dan mendapatkan token akses Google yang memiliki masa aktif singkat.
Untuk langkah terakhir, gunakan akun layanan yang berada dalam project yang sama dengan resource yang perlu Anda akses. Menggunakan akun layanan yang dikelola dalam project yang sama akan membantu Anda menerapkan izin akses yang lebih ketat, dan memudahkan Anda untuk memutuskan kapan akun layanan mungkin tidak diperlukan lagi.
Menggunakan akun layanan khusus untuk setiap aplikasi
Jika Anda memiliki beberapa aplikasi yang menggunakan workload identity federation untuk mengakses resource dalam project yang sama, buat akun layanan khusus untuk setiap aplikasi. Menggunakan akun layanan khusus aplikasi membantu Anda menghindari pemberian izin yang berlebihan dengan hanya memberikan akses ke resource yang diperlukan oleh setiap aplikasi.
Menghindari pemberian akses ke semua anggota kumpulan
Sebelum identitas eksternal dapat meniru identitas akun layanan, Anda harus
memberinya peran roles/iam.workloadIdentityUser pada akun layanan. Saat Anda memberikan peran
ini, hindari memberikannya kepada semua anggota workload identity pool. Sebaliknya,
berikan peran tersebut ke identitas eksternal tertentu, atau ke identitas yang cocok
dengan kriteria tertentu.
Awalnya, jumlah pengguna eksternal yang memerlukan akses ke resource Google Cloud mungkin sedikit. Oleh karena itu, kondisi atribut workload identity pool dan konfigurasi penyedia identitas Anda mungkin hanya mengizinkan beberapa identitas eksternal untuk menggunakan workload identity federation.
Saat mengaktivasi workload baru ke Google Cloud, Anda mungkin perlu mengubah konfigurasi penyedia identitas atau kondisi atribut workload identity pool agar memungkinkan identitas eksternal tambahan.
Dengan hanya memberikan peran roles/iam.workloadIdentityUser ke identitas eksternal
tertentu, Anda dapat memastikan bahwa Anda dapat mengembangkan workload identity pool
dengan aman tanpa secara tidak sengaja memberikan lebih banyak akses peniruan identitas eksternal daripada
yang diperlukan.
Langkah selanjutnya
- Pelajari lebih lanjut praktik terbaik untuk menggunakan akun layanan.
- Baca selengkapnya tentang praktik terbaik untuk mengelola kunci akun layanan.