Praktik terbaik untuk menggunakan akun layanan di pipeline

Dengan pipeline deployment, Anda dapat mengotomatiskan proses pengambilan kode atau artefak siap pakai dan men-deploy-nya ke lingkungan Google Cloud. Nantinya, pipeline tersebut dapat menjadi alternatif untuk menggunakan alat interaktif seperti Konsol Google Cloud atau Google Cloud CLI.

Pipeline deployment berbeda dengan alat interaktif seperti Konsol Google Cloud atau gcloud CLI dalam cara mereka berinteraksi dengan Identity and Access Management. Untuk itu, Anda harus mempertimbangkan perbedaan ini saat mengamankan resource Google Cloud Anda.

Sebelum mengizinkan Anda mengakses resource, Google Cloud melakukan pemeriksaan akses. Untuk melakukan pemeriksaan ini, IAM biasanya mempertimbangkan:

• Identitas Anda
• Resource yang ingin Anda akses serta kebijakan izin dan tolak IAM
• Konteks permintaan Anda (mungkin termasuk waktu dan lokasi)

Dalam pipeline deployment, Anda akan jarang memanggil Google Cloud API secara langsung. Sebagai gantinya, Anda akan menggunakan alat untuk mengakses resource Google Cloud. Fitur seperti Konsol Google Cloud atau gcloud CLI mengharuskan Anda menyetujui fitur tersebut terlebih dahulu untuk mengakses resource atas nama Anda. Dengan memberikan otorisasi ini, Anda memberi alat tersebut izin untuk menggunakan identitas Anda saat melakukan panggilan API.

Seperti Konsol Google Cloud atau gcloud CLI, pipeline deployment bertindak atas nama Anda: Tindakan ini akan mengambil perubahan Anda, dinyatakan sebagai kode sumber, dan men-deploy-nya ke Google Cloud. Namun, tidak seperti Konsol Google Cloud atau gcloud CLI, pipeline deployment biasanya tidak menggunakan identitas Anda untuk melakukan deployment:

1. Sebagai pengguna, Anda biasanya tidak berinteraksi dengan pipeline deployment secara langsung. Sebagai gantinya, Anda akan berinteraksi dengan sistem kontrol sumber (SCM) dengan mengirim perubahan kode ke repositori sumber, atau menyetujui peninjauan kode.

2. Pipeline deployment membaca perubahan kode yang dikirim dari sistem SCM dan men-deploy-nya ke Google Cloud.

   Untuk menjalankan deployment, pipeline deployment biasanya tidak dapat menggunakan identitas Anda karena:

   1. Kode sumber dan metadatanya mungkin tidak menunjukkan bahwa Anda adalah penulisnya, atau informasi penulis tidak dapat dimodifikasi (seperti pada kasus commit Git yang tidak ditandatangani)
   2. Identitas yang Anda gunakan untuk mengirimkan kode sumber mungkin berbeda dengan identitas Google Anda, dan kedua identitas tersebut tidak dapat dipetakan

   Oleh karena itu, sebagian besar pipeline deployment melakukan deployment dengan identitasnya sendiri menggunakan akun layanan.

3. Saat pipeline deployment mengakses Google Cloud, IAM mengizinkan atau menolak akses hanya berdasarkan identitas akun layanan yang digunakan oleh pipeline, bukan identitas akun pengguna Anda.

Ada beberapa keuntungan saat mengizinkan pipeline deployment menggunakan akun layanan untuk mengakses Google Cloud:

• Siklus proses akun layanan terputus dari siklus proses akun pengguna. Dengan mengonfigurasi pipeline untuk menggunakan akun layanan, berarti Anda memastikan bahwa kode dapat di-deploy meskipun penulis kode tidak lagi bekerja di organisasi Anda.
• Saat mengelola resource menggunakan pipeline deployment, Anda tidak perlu memberi pengguna akses ke resource, atau Anda dapat membatasi izin akses hanya baca. Pendekatan ini dapat memudahkan pengelolaan kebijakan IAM dan memungkinkan Anda memaksa pengguna menggunakan pipeline deployment untuk melakukan semua modifikasi.

Namun, penggunaan akun layanan juga menimbulkan ancaman baru. Layanan tersebut meliputi:

• Spoofing: Pihak tidak bertanggung jawab dapat mencoba memalsukan identitas pipeline deployment atau mencuri kredensialnya untuk mendapatkan akses ke resource.
• Eskalasi akses: Pipeline dapat dimanipulasi untuk melakukan tindakan yang tidak seharusnya dilakukan, sehingga menjadi deputi yang membingungkan.
• Non-repudiasi: Setelah pipeline melakukan operasi, pipeline mungkin sulit merekonstruksi alasan tindakan, developer, atau perubahan kode mana yang memicunya.
• Penyalahgunaan: Pipeline dapat disalahgunakan untuk melemahkan integritas atau kontrol keamanan lingkungan cloud Anda.
• Pengungkapan informasi: Pihak tidak bertanggung jawab mungkin mencoba menggunakan pipeline deployment untuk memindahkan data rahasia.

Perlindungan dari ancaman spoofing

Untuk memberikan akses pipeline deployment ke Google Cloud, biasanya Anda perlu melakukan hal berikut:

1. Membuat akun layanan
2. Memberi akun layanan akses ke resource yang diperlukan
3. Mengonfigurasi pipeline deployment untuk menggunakan akun layanan

Dari perspektif IAM, akun layanan mewakili pipeline deployment, tetapi pipeline deployment dan akun layanan adalah dua entitas yang berbeda. Jika tidak diamankan dengan benar, pihak tidak bertanggung jawab mungkin dapat menggunakan akun layanan yang sama, yang memungkinkan mereka "meniru" identitas pipeline deployment.

Bagian berikut menjelaskan cara terbaik yang dapat membantu Anda mengurangi risiko ancaman tersebut.

Praktik terbaik:

Hindari memasang akun layanan ke instance VM yang digunakan oleh sistem CI/CD.
Gunakan akun layanan khusus per pipeline deployment.
Gunakan workload identity federation jika memungkinkan.
Gunakan Kontrol Layanan VPC untuk mengurangi dampak kebocoran kredensial.

Hindari memasang akun layanan ke instance VM yang digunakan oleh sistem CI/CD

Untuk aplikasi yang di-deploy pada Compute Engine yang memerlukan akses ke resource Google Cloud, sebaiknya lampirkan akun layanan ke instance VM yang mendasarinya. Untuk sistem CI/CD yang menggunakan VM Compute Engine untuk menjalankan pipeline deployment yang berbeda, praktik ini dapat menimbulkan masalah. Ini terjadi jika instance VM yang sama digunakan untuk menjalankan pipeline deployment berbeda, dengan masing-masing instance memerlukan akses ke resource yang berbeda.

Daripada menggunakan akun layanan yang terpasang untuk mengizinkan pipeline deployment mengakses resource, izinkan setiap pipeline deployment menggunakan akun layanan terpisah. Hindari memasang akun layanan ke instance VM yang digunakan oleh sistem CI/CD, atau memasang akun layanan yang terbatas untuk mengakses layanan penting seperti Cloud Logging saja.

Gunakan akun layanan khusus per pipeline deployment

Ketika berbagai pipeline deployment digunakan dengan akun layanan yang sama, IAM tidak dapat membedakan pipeline-nya: Pipeline memiliki akses ke resource yang sama, dan log audit mungkin tidak berisikan informasi yang memadai untuk menentukan pipeline deployment mana yang memicu resource untuk diakses atau diubah.

Untuk menghindari ambiguitas tersebut, pertahankan hubungan langsung antara pipeline deployment dan akun layanan. Buat akun layanan khusus untuk setiap pipeline deployment dan pastikan untuk:

• Menyertakan nama atau ID pipeline deployment ke alamat email akun layanan. Mengikuti skema penamaan yang konsisten akan membantu Anda menentukan pipeline deployment dari nama akun layanan, dan sebaliknya.
• Hanya berikan akses akun layanan ke resource yang dibutuhkan pipeline deployment tertentu.

Gunakan workload identity federation jika memungkinkan

Beberapa sistem CI/CD seperti GitHub Actions atau GitLab memungkinkan pipeline deployment mendapatkan token yang sesuai dengan OpenID Connect, yang menyatakan identitas pipeline deployment. Anda dapat mengizinkan pipeline deployment menggunakan token ini untuk meniru identitas akun layanan dengan menggunakan workload identity federation.

Menggunakan workload identity federation membantu Anda menghindari risiko yang terkait dengan penggunaan kunci akun layanan.

Gunakan Kontrol Layanan VPC untuk mengurangi dampak kebocoran kredensial

Jika pihak tidak bertanggung jawab berhasil mencuri token akses atau kunci akun layanan dari salah satu pipeline deployment Anda, kemungkinan kredensial dan resource Anda diakses dari komputer lain yang mereka kontrol.

Secara default, IAM tidak mempertimbangkan lokasi geografis, alamat IP sumber, atau asal project Google Cloud saat membuat keputusan akses. Oleh karena itu, kredensial yang dicuri mungkin dapat diakses dari mana saja.

Anda dapat membatasi sumber tempat resource Google Cloud dapat diakses dengan menempatkan project di perimeter layanan VPC dan menggunakan aturan ingress:

• Jika pipeline deployment Anda berjalan di Google Cloud, Anda dapat mengonfigurasi aturan ingress agar hanya mengizinkan akses dari project yang berisi sistem CI/CD Anda.
• Jika pipeline deployment berjalan di luar Google Cloud, Anda dapat membuat tingkat akses yang hanya mengizinkan akses dari lokasi geografis atau rentang IP tertentu. Kemudian buat aturan ingress yang mengizinkan akses untuk klien yang memenuhi tingkat akses ini.

Catatan: Membatasi akses berdasarkan rentang IP mungkin kurang efektif atau tidak mungkin dilakukan jika Anda menggunakan sistem Software as a Service (SaaS) untuk menjalankan pipeline deployment Anda: Alamat IP sumber yang digunakan oleh penyedia SaaS mungkin tidak diketahui sebelumnya, atau mungkin dibagikan ke semua pelanggan mereka.

Perlindungan dari ancaman penyalahgunaan

Untuk beberapa data yang tersimpan di Google Cloud, penting untuk mencegah terjadinya modifikasi atau penghapusan yang tidak sah. Jika modifikasi atau penghapusan yang tidak sah ini menjadi masalah khusus, Anda dapat menetapkan data tersebut sebagai data berintegritas tinggi.

Untuk menjaga integritas data, Anda harus memastikan bahwa resource Google Cloud yang digunakan untuk menyimpan dan mengelola data tersebut dikonfigurasi dengan aman dan terjaga integritasnya.

Pipeline deployment dapat membantu Anda mempertahankan integritas data dan resource, tetapi juga dapat menimbulkan risiko: Jika pipeline salah satu komponennya tidak memenuhi persyaratan integritas resource yang dikelolanya, pipeline deployment bisa menjadi titik lemah yang memungkinkan pihak tidak bertanggung jawab menyalahgunakan data atau resource Anda.

Bagian berikut menjelaskan cara terbaik yang dapat membantu Anda mengurangi risiko penyalahgunaan tersebut.

Praktik terbaik:

Hindari membiarkan pipeline deployment mengelola kontrol keamanan.

Batasi akses ke kontrol keamanan

Untuk memastikan keamanan dan integritas data serta resource Anda di Google Cloud, gunakan kontrol keamanan seperti:

• Mengizinkan dan menolak kebijakan
• Memberikan batasan pada kebijakan organisasi
• Menggunakan perimeter Kontrol Layanan VPC, tingkat akses, dan kebijakan ingress

Kontrol keamanan ini adalah resource itu sendiri. Merusak kontrol keamanan membahayakan integritas resource tempat kontrol keamanan diterapkan. Oleh karena itu, penting untuk menganggap integritas kontrol keamanan sama pentingnya dengan integritas resource yang diterapkan.

Jika Anda membiarkan pipeline deployment mengelola kontrol keamanan, maka pipeline deployment akan bertanggung jawab untuk mempertahankan integritas kontrol keamanan. Oleh karena itu, Anda harus menganggap integritas pipeline deployment sama pentingnya dengan integritas kontrol keamanan yang dikelolanya, dan juga resource yang menerapkan kontrol ini.

Anda dapat membatasi dampak pipeline deployment pada integritas resource Anda dengan cara:

• Tidak memberi akses pipeline deployment untuk mengizinkan kebijakan, menolak kebijakan, dan kontrol keamanan lainnya, serta membatasi akses mereka ke resource lain
• Hanya memberikan akses ke kontrol keamanan yang dipilih, seperti kebijakan izin dan kebijakan tolak untuk resource atau project tertentu, namun tidak memberikan akses ke kontrol yang lebih luas yang memengaruhi banyak resource atau project

Jika pipeline deployment Anda, komponennya, dan infrastruktur yang mendasarinya tidak dapat memenuhi tuntutan integritas dari kontrol keamanan tertentu, sebaiknya jangan biarkan pipeline deployment mengelola kontrol keamanan ini.

Perlindungan dari ancaman non-repudiasi

Pada saat tertentu, Anda mungkin melihat aktivitas mencurigakan yang memengaruhi salah satu resource Anda di Google Cloud. Jika demikian, Anda harus dapat mengetahui aktivitas tersebut lebih lanjut dan, idealnya, dapat merekonstruksi rantai peristiwa yang mengarah ke aktivitas tersebut.

Dengan Cloud Audit Logs, Anda dapat mengetahui kapan resource diakses atau diubah, dan pengguna mana yang terlibat. Meskipun Cloud Audit Logs memberitahu titik awal untuk menganalisis aktivitas yang mencurigakan ini, namun informasi yang diberikan oleh log ini mungkin tidak cukup: jika Anda menggunakan pipeline deployment, Anda juga harus dapat menghubungkan Cloud Audit Logs dengan log yang dihasilkan oleh pipeline deployment Anda.

Bagian ini berisi cara terbaik yang dapat membantu Anda mempertahankan jejak audit di seluruh Google Cloud dan pipeline deployment Anda.

Praktik terbaik:

Pastikan Anda dapat menghubungkan log pipeline deployment dengan Cloud Audit Logs.
Selaraskan periode retensi log pipeline deployment dan Cloud Audit Logs.

Pastikan Anda dapat menghubungkan log pipeline deployment dengan Cloud Audit Logs

Cloud Audit Logs berisi stempel waktu dan informasi tentang pengguna yang memulai aktivitas. Jika Anda menggunakan akun layanan khusus untuk setiap pipeline deployment, maka informasi ini memungkinkan Anda mengidentifikasi pipeline deployment yang memulai aktivitas. Dan juga dapat membantu Anda mempersempit perubahan kode dan pipeline mana yang mungkin menjadi penyebabnya. Namun, menentukan dengan tepat operasi pipeline dan perubahan kode yang menyebabkan aktivitas tersebut bisa sulit dilakukan tanpa informasi lebih lanjut yang memungkinkan Anda menghubungkan Cloud Audit Logs dengan log pipeline deployment Anda.

Anda dapat memperkaya Cloud Audit Logs untuk menampung lebih banyak informasi dengan berbagai cara, termasuk:

• Saat Anda menggunakan Terraform, tentukan alasan permintaan yang menunjukkan bahwa pipeline CI/CD dijalankan.
• Menambahkan header HTTP X-Goog-Request-Reason ke permintaan API dan teruskan ID dari pipeline deployment yang dijalankan.
• Menggunakan User-Agent kustom yang menyematkan ID operasi pipeline deployment.

Anda juga dapat memperkaya log yang dikeluarkan oleh pipeline deployment Anda:

• Log permintaan API yang dilakukan oleh setiap operasi pipeline CI/CD.
• Setiap kali API menampilkan ID operasi, catat ID tersebut dalam log sistem CI/CD.

Selaraskan periode retensi log pipeline deployment dan Cloud Audit Logs

Untuk menganalisis aktivitas mencurigakan yang terkait dengan pipeline deployment, biasanya Anda memerlukan beberapa jenis log, termasuk log audit Aktivitas Admin, log audit Akses Data, dan log dari pipeline deployment Anda.

Cloud Logging hanya menyimpan log selama jangka waktu tertentu. Secara default, periode retensi data log audit Akses Data lebih singkat daripada log audit Aktivitas Admin. Sistem yang menjalankan pipeline deployment Anda mungkin juga menghapus lognya setelah jangka waktu tertentu. Bergantung pada sifat pipeline deployment dan pentingnya resource yang dikelola pipeline deployment, periode retensi default ini mungkin tidak mencukupi atau tidak selaras.

Untuk memastikan log tersedia saat Anda membutuhkannya, pastikan periode retensi log yang digunakan oleh sistem yang berbeda sesuai dan cukup lama.

Jika perlu, sesuaikan periode retensi data untuk log audit Akses Data, atau siapkan sink kustom untuk merutekan log ke lokasi penyimpanan kustom.

Praktik terbaik:

Hindari memberikan akses langsung ke data rahasia.
Gunakan Kontrol Layanan VPC untuk membantu mencegah pemindahan data yang tidak sah.

Perlindungan dari ancaman pengungkapan informasi

Jika akun layanan pipeline deployment memiliki akses ke data rahasia, pihak tidak bertanggung jawab mungkin mencoba menggunakan pipeline deployment untuk memindahkan data tersebut. Akses pipeline deployment ke data dapat dilakukan secara langsung atau tidak langsung:

• Langsung: Akun layanan pipeline deployment mungkin memiliki izin untuk membaca data rahasia dari Cloud Storage, BigQuery, atau lokasi lainnya. Akses ini mungkin telah diberikan dengan sengaja, namun mungkin juga merupakan akibat ketidaksengajaan karena terlalu banyak memberikan akses.

  Jika pihak tidak bertanggung jawab mendapatkan akses ke pipeline deployment dengan akses langsung ke data rahasia, mereka mungkin mencoba menggunakan token akses akun layanan untuk mengakses dan memindahkan data secara tidak sah.

• Tidak langsung: Untuk men-deploy konfigurasi atau versi software baru, akun layanan pipeline deployment mungkin memiliki izin untuk membuat atau men-deploy ulang instance VM, aplikasi Cloud Run, atau resource komputasi lainnya. Beberapa resource komputasi ini mungkin memiliki akun layanan terpasang yang memberikan aksess ke data rahasia.

  Dalam situasi ini, pihak tidak bertanggung jawab mungkin mencoba menyusupi pipeline deployment sehingga dapat men-deploy kode berbahaya ke salah satu resource komputasi, dan membiarkan kode ini memindahkan data rahasia secara tidak sah.

Bagian ini berisi cara terbaik yang dapat membantu Anda membatasi risiko pengungkapan data rahasia.

Hindari pemberian akses langsung ke data rahasia

Untuk men-deploy infrastruktur, konfigurasi, atau versi software baru, pipeline deployment sering kali tidak memerlukan akses ke data yang sudah ada. Sebaliknya, cukup dengan membatasi akses ke resource yang tidak berisi data apa pun, atau setidaknya tidak berisi data rahasia.

Cara meminimalkan akses ke data yang berpotensi rahasia, meliputi:

• Alih-alih memberi akun layanan pipeline deployment akses ke seluruh project, hanya berikan akses ke resource tertentu.
• Berikan akses-buat tanpa mengizinkan akses-baca. Misalnya, dengan memberikan peran Storage Object Creator (roles/storage.objectCreator), Anda dapat mengizinkan akun layanan untuk mengupload objek baru ke bucket Cloud Storage tanpa memberikan izin akses untuk membaca data yang ada.
• Batasi Infrastructure as Code (IaC) ke resource yang tidak terlalu rahasia. Misalnya, gunakan IaC untuk mengelola instance atau jaringan VM, tetapi bukan untuk mengelola set data BigQuery yang bersifat rahasia.

Menggunakan Kontrol Layanan VPC untuk membantu mencegah pemindahan data yang tidak sah

Anda dapat mengurangi risiko pemindahan data yang tidak sah secara langsung dengan men-deploy resource Google Cloud di perimeter Kontrol Layanan VPC.

Jika pipeline deployment berjalan di luar Google Cloud, atau merupakan bagian dari perimeter yang berbeda, Anda dapat memberi akses akun layanan pipeline ke perimeter dengan mengonfigurasi aturan ingress. Jika memungkinkan, konfigurasikan aturan ingress agar hanya mengizinkan akses dari alamat IP yang digunakan oleh pipeline deployment, dan hanya mengizinkan akses ke layanan yang benar-benar diperlukan pipeline deployment.

Perlindungan dari ancaman eskalasi akses

Terlepas dari developer atau pengguna yang menulis kode atau perubahan konfigurasi, ketika pipeline deployment menggunakan akun layanan untuk mengakses resource Google Cloud, hal tersebut dilakukan tanpa mempertimbangkan individu yang melakukan modifikasi. Terputusnya akun layanan pipeline dan identitas developer membuat pipeline deployment rentan terhadap serangan deputi yang membingungkan. Ini dapat membuat pihak tidak bertanggung jawab mengelabui untuk melakukan tindakan yang tidak boleh dilakukan, bahkan oleh pipeline sekalipun.

Bagian ini berisi cara terbaik yang dapat membantu Anda mengurangi risiko penyalahgunaan pipeline deployment untuk eskalasi akses.

Praktik terbaik:

Batasi akses ke pipeline deployment dan semua input.
Hindari mengizinkan pipeline deployment mengubah kebijakan.
Jangan ungkapkan kredensial akun layanan di log.

Batasi akses ke pipeline deployment dan semua input

Sebagian besar pipeline deployment menggunakan repositori kode sumber sebagai sumber input utamanya dan dapat terpicu secara otomatis begitu mendeteksi perubahan kode di cabang tertentu (misalnya, cabang main). Pipeline deployment biasanya tidak dapat memeriksa apakah kode dan konfigurasi yang ditemukan di repositori kode sumber merupakan kode asli dan tepercaya atau bukan. Oleh karena itu, keamanan arsitektur ini bergantung pada:

• Pengontrolan siapa yang dapat mengirimkan kode dan konfigurasi ke repositori serta cabang yang digunakan oleh pipeline deployment.
• Penerapan kriteria yang harus dipenuhi sebelum perubahan dapat diterapkan – misalnya, berhasil meninjau kode, analisis statis, atau pengujian otomatis.

Untuk menjamin keefektifan kontrol ini, Anda juga harus memastikan bahwa pihak tidak bertanggung jawab dapat mengabaikannya dengan:

• Memodifikasi konfigurasi dari repositori kode sumber atau pipeline deployment.
• Merusak infrastruktur (seperti VM dan penyimpanan) yang mendasari pipeline deployment.
• Memodifikasi atau mengganti input di luar repositori kode sumber, seperti paket, image container, atau library.

Jika dikelola oleh pipeline deployment, resource Anda di Google Cloud tingkat keamanannya hanya bisa setingkat pipeline deployment, konfigurasi, infrastruktur, dan inputnya. Oleh karena itu, Anda harus melindungi komponen ini sebaik Anda ingin melindungi resource Google Cloud Anda.

Hindari agar pipeline deployment tidak mengubah kebijakan

Untuk sebagian besar jenis resource, IAM yang menentukan izin RESOURCE_TYPE.setIamPolicy. Dengan izin ini, pengguna dapat mengubah kebijakan izin IAM resource, baik untuk memberikan akses kepada pengguna lain maupun untuk mengubah dan memperluas akses mereka sendiri. Kecuali jika dibatasi oleh kebijakan tolak, memberikan izin *.setIamPolicy kepada pengguna atau akun layanan akan memberi mereka akses penuh ke resource.

Jika memungkinkan, hindari memberi izin pipeline deployment mengubah akses ke resource. Saat memberi akun layanan pipeline akses ke resource Google Cloud, gunakan peran yang tidak menyertakan izin *.setIamPolicy dan hindari penggunaan peran dasar Editor dan Pemilik.

Untuk beberapa pipeline deployment, mungkin perlu memberikan izin untuk mengubah kebijakan izin atau kebijakan tolak: Misalnya, jika tujuan pipeline deployment digunakan untuk membuat resource baru atau mengelola akses ke resource yang ada. Dalam skenario ini, Anda masih dapat membatasi sejauh mana deployment dapat mengubah akses dengan:

• Hanya memberikan izin *.setIamPolicy untuk resource tertentu, bukan untuk seluruh project.
• Menggunakan kebijakan penolakan IAM untuk membatasi kumpulan izin yang dapat diberikan, atau untuk membatasi akun utama yang dapat diberikan izin.
• Menggunakan IAM Conditions untuk membatasi peran yang boleh diberikan oleh pipeline, dan hanya mengizinkan peran yang tidak menyertakan izin *.setIamPolicy.

Jangan ungkapkan kredensial akun layanan di log

Log yang dihasilkan oleh pipeline deployment sering kali dapat diakses oleh kelompok pengguna yang lebih besar, termasuk pengguna yang tidak memiliki izin untuk mengubah konfigurasi pipeline. Log ini dapat secara tidak sengaja mengungkapkan kredensial dengan melakukan echo:

• Isi dari variabel lingkungan
• Argumen command line
• Output diagnostik

Jika log secara tidak sengaja mengungkapkan kredensial seperti token akses, maka kredensial ini dapat disalahgunakan oleh pihak tidak bertanggung jawab untuk mengeskalasikan hak istimewanya. Cara mencegah log mengungkap kredensial meliputi:

• Hindari meneruskan token akses atau kredensial lainnya sebagai argumen command line
• Hindari menyimpan kredensial dalam variabel lingkungan
• Konfigurasikan sistem CI/CD Anda untuk mendeteksi dan menyamarkan token serta kredensial lainnya secara otomatis jika memungkinkan

Langkah selanjutnya

• Pelajari lebih lanjut tentang workload identity federation dan praktik terbaik untuk menggunakan workload identity federation .
• Tinjau blueprint dasar-dasar perusahaan dan panduan kami tentang autentikasi dan otorisasi.
• Pelajari lebih lanjut tentang praktik terbaik untuk menggunakan akun layanan.