Kredensial akun layanan

Seperti akun utama lainnya, akun layanan dapat mengautentikasi dirinya sendiri ke Google, mendapatkan token akses OAuth 2.0, dan memanggil Google API. Namun, proses ini berfungsi secara berbeda untuk akun layanan dan untuk pengguna.

Autentikasi akun layanan dengan melakukan salah satu hal berikut:

• Memperoleh kredensial berumur pendek
• Menggunakan kunci akun layanan untuk menandatangani Token Web JSON (JWT) dan menukarnya dengan token akses

Kredensial akun layanan berjangka pendek

Cara paling aman untuk mengautentikasi sebagai akun layanan adalah dengan mendapatkan kredensial berjangka pendek untuk akun layanan dalam bentuk token akses OAuth 2.0. Secara default, masa berlaku token ini akan berakhir setelah 1 jam.

Kredensial akun layanan berjangka pendek berguna untuk skenario saat Anda perlu memberikan akses terbatas ke resource untuk akun layanan tepercaya. Kredensial tersebut juga menimbulkan lebih sedikit risiko daripada kredensial yang berumur panjang, seperti kunci akun layanan.

Dalam banyak kasus, kredensial ini diperoleh secara otomatis. Anda tidak perlu membuat atau mengelolanya sendiri. Berikut beberapa contohnya:

• Jika Anda menjalankan perintah Google Cloud CLI dan menyertakan flag --impersonate-service-account, maka gcloud CLI akan membuat kredensial berumur pendek untuk akun layanan dan menjalankan perintah dengan kredensial tersebut.

• Jika Anda menambahkan akun layanan ke instance mesin virtual (VM) Compute Engine, maka workload pada instance tersebut dapat menggunakan Library Klien Cloud untuk mengakses layanan Google Cloud. Library Klien Cloud menggunakan Kredensial Default Aplikasi (ADC) untuk mendapatkan kredensial berumur pendek untuk akun layanan.

  Untuk mengetahui detail tentang proses ini, baca Mengautentikasi aplikasi menggunakan kredensial akun layanan.

• Jika Anda mengonfigurasi federasi identitas workload, Library Klien Cloud dapat menggunakan kredensial dari penyedia identitas Anda untuk membuat kredensial akun layanan berjangka pendek.

Anda juga dapat menggunakan Service Account Credentials API untuk membuat kredensial berjangka pendek secara manual. Misalnya, Anda dapat membuat layanan yang memberi pengguna kredensial akun layanan berjangka pendek agar mereka dapat mengakses resource Google Cloud untuk sementara.

Service Account Credentials API dapat membuat jenis kredensial berikut:

• Token akses OAuth 2.0
• Token ID OpenID Connect (OIDC)
• JSON Web Token (JWT) yang ditandatangani sendiri
• Blob biner yang ditandatangani sendiri

Untuk informasi selengkapnya, lihat Membuat kredensial akun layanan jangka pendek.

Menafsirkan log audit

Cloud Audit Logs membantu Anda menjawab pertanyaan "siapa yang melakukan apa, di mana, dan kapan?" untuk resource Google Cloud Anda.

Jika Anda menggunakan kredensial berjangka pendek untuk meniru identitas akun layanan, sebagian besar layanan Google Cloud akan membuat entri log yang menunjukkan identitas berikut:

• Akun layanan yang ditiru kredensial berjangka pendek
• Identitas yang membuat kredensial berjangka pendek

Anda dapat menggunakan entri log ini untuk mengidentifikasi akun utama yang membuat kredensial berjangka pendek, serta akun layanan yang ditiru oleh akun utama tersebut.

Catatan: Beberapa layanan Google Cloud, termasuk App Engine dan Google Kubernetes Engine, tidak mencatat log identitas yang membuat kredensial berjangka pendek.

Untuk melihat contoh entri log audit yang menunjukkan peniruan identitas akun layanan, lihat Peniruan akun layanan untuk mengakses Google Cloud.

Peniruan identitas

Peniruan identitas diri adalah saat Anda menggunakan kredensial akun layanan sendiri untuk membuat kredensial baru untuk akun layanan.

Service Account Credentials API melarang jenis peniruan diri sendiri berikut ini:

• Menggunakan kredensial berjangka pendek untuk akun layanan guna membuat token akses baru untuk akun layanan.

  Token Web JSON (JWT) yang ditandatangani sendiri merupakan pengecualian untuk aturan ini, Anda dapat menggunakan JWT yang ditandatangani sendiri untuk akun layanan guna membuat token akses baru untuk layanan tersebut.

• Menggunakan kredensial berjangka pendek untuk akun layanan untuk menandatangani objek biner (blob) atau JWT yang dapat digunakan untuk memanggil API berikut:

  • Identity and Access Management API
  • Service Account Credentials API
  • OAuth 2.0 API

Google Cloud melarang peniruan identitas diri semacam ini karena memungkinkan pelaku berbahaya memperbarui token yang dicuri tanpa batas.

Jika Anda mencoba menggunakan peniruan identitas dengan salah satu cara yang dilarang, Anda mungkin akan mengalami error seperti berikut ini:

FAILED_PRECONDITION: You can't create a token for the same service account that
you used to authenticate the request.

Jika Anda mengalami error ini, coba gunakan kredensial yang berbeda untuk membuat kredensial baru yang berjangka pendek untuk akun layanan Anda, misalnya, kredensial pengguna akhir atau kredensial akun layanan yang berbeda.

Kunci akun layanan

Setiap akun layanan dikaitkan dengan pasangan kunci RSA publik/pribadi. Service Account Credentials API menggunakan pasangan kunci internal ini untuk membuat kredensial akun layanan berjangka pendek dan untuk menandatangani blob dan Token Web JSON (JWT). Pasangan kunci ini dikenal sebagai pasangan kunci yang dikelola Google.

Selain itu, Anda dapat membuat beberapa pasangan kunci RSA publik/pribadi, yang dikenal sebagai pasangan kunci yang dikelola pengguna dan menggunakan kunci pribadi tersebut untuk melakukan autentikasi dengan Google API. Kunci pribadi ini dikenal sebagai kunci akun layanan.

Pasangan kunci yang dikelola Google

Pasangan kunci yang dikelola Google digunakan oleh Service Account Credentials API dan oleh layanan Google Cloud seperti App Engine dan Compute Engine untuk menghasilkan kredensial berjangka pendek untuk akun layanan.

Pasangan kunci yang dikelola Google dirotasi secara otomatis dan digunakan untuk penandatanganan selama maksimum dua minggu. Proses rotasi bersifat probabilistik; penggunaan kunci baru akan meningkat dan menurun secara bertahap selama masa pakai kunci tersebut.

Kunci pribadi dalam pasangan kunci yang dikelola Google selalu disimpan di dalam dana jaminan dan Anda tidak akan pernah dapat mengaksesnya secara langsung.

Kunci publik dalam pasangan kunci yang dikelola Google dapat diakses secara publik, sehingga siapa saja dapat memverifikasi tanda tangan yang dibuat dengan kunci pribadi. Anda dapat mengakses kunci publik dalam beberapa format berbeda:

• Sertifikat X.509: https://www.googleapis.com/service_accounts/v1/metadata/x509/SERVICE_ACCOUNT_EMAIL
• Kunci Web JSON (JWK): https://www.googleapis.com/service_accounts/v1/jwk/SERVICE_ACCOUNT_EMAIL
• Format raw: https://www.googleapis.com/service_accounts/v1/metadata/raw/SERVICE_ACCOUNT_EMAIL

Jika Anda mendownload dan meng-cache kunci publik, sebaiknya simpan kunci publik tersebut dalam cache maksimal selama 24 jam untuk memastikan Anda selalu memiliki kunci terbaru. Terlepas dari kapan Anda mengambil kunci publik, kunci tersebut akan valid setidaknya selama 24 jam setelah Anda mengambilnya.

Pasangan kunci yang dikelola pengguna

Anda dapat membuat pasangan kunci yang dikelola pengguna untuk akun layanan, lalu gunakan kunci pribadi dari setiap pasangan kunci untuk mengautentikasi Google API. Kunci pribadi ini disebut sebagai kunci akun layanan.

Library Klien Cloud dapat menggunakan kunci akun layanan untuk mendapatkan token akses OAuth 2.0 secara otomatis. Anda juga dapat menggunakan kunci akun layanan untuk menandatangani JWT secara manual, lalu gunakan JWT yang ditandatangani untuk meminta token akses. Untuk mengetahui detailnya, lihat Menggunakan OAuth 2.0 untuk aplikasi server ke server.

Perhatian: Kunci akun layanan memiliki risiko keamanan jika tidak dikelola dengan benar. Anda harus memilih alternatif yang lebih aman untuk kunci akun layanan jika memungkinkan. Jika harus melakukan autentikasi dengan kunci akun layanan, Anda bertanggung jawab atas keamanan kunci pribadi dan untuk operasi lain yang dijelaskan dalam Praktik terbaik untuk mengelola kunci akun layanan. Jika Anda tidak dapat membuat kunci akun layanan, pembuatan kunci akun layanan mungkin dinonaktifkan untuk organisasi Anda. Untuk mengetahui informasi selengkapnya, lihat Mengelola resource organisasi yang aman secara default.

Setiap akun layanan dapat memiliki hingga 10 kunci akun layanan. Google hanya menyimpan bagian publik dari pasangan kunci yang dikelola pengguna.

Ada beberapa cara untuk membuat pasangan kunci yang dikelola pengguna untuk akun layanan:

• Gunakan IAM API untuk membuat pasangan kunci yang dikelola pengguna secara otomatis. Google menghasilkan pasangan kunci publik/pribadi; hanya menyimpan kunci publik; dan mengembalikan kunci pribadi kepada Anda.
• Buat sendiri pasangan kunci yang dikelola pengguna, lalu upload kunci publik saja. Google tidak pernah melihat kunci pribadi.

Kunci yang dikelola pengguna merupakan kredensial yang sangat penting. Untuk membatasi penggunaan kunci yang dikelola pengguna, Anda dapat menerapkan batasan kebijakan organisasi berikut dalam organisasi, project, atau folder:

• constraints/iam.disableServiceAccountKeyCreation: Mencegah akun utama dari membuat kunci akun layanan yang dikelola pengguna.
• constraints/iam.disableServiceAccountKeyUpload: Mencegah akun utama dari mengupload kunci publik untuk akun layanan.

Jika Anda menerapkan batasan ini karena menggunakan workload identity federation , pertimbangkan untuk menggunakan batasan kebijakan organisasi untuk workload identity federation untuk menentukan identitas mana yang diperbolehkan.

Expiry time untuk kunci yang dikelola pengguna

Secara default, saat Anda membuat kunci akun layanan yang dikelola pengguna, masa berlaku kunci tersebut tidak akan pernah berakhir. Anda dapat mengubah setelan default ini dengan menetapkan expiry time untuk semua kunci yang baru dibuat di project, folder, atau organisasi Anda. Expiry time menentukan jumlah jam validitas kunci yang baru dibuat.

Gunakan expiry time saat Anda memerlukan akses sementara ke sistem yang memerlukan kunci akun layanan. Misalnya, gunakan expiry time jika Anda melakukan hal berikut:

• Mengembangkan kode dalam lingkungan non-produksi untuk aplikasi yang hanya dapat melakukan autentikasi dengan kunci akun layanan
• Menggunakan alat pihak ketiga yang hanya dapat mengautentikasi dengan kunci akun layanan

Hindari penggunaan expiry time untuk skenario berikut:

• Workload produksi. Dalam proses produksi, kunci akun layanan yang sudah tidak berlaku dapat menyebabkan penghentian yang tidak disengaja. Sebagai gantinya, gunakan kunci yang tidak memiliki masa berlaku dan kelola siklus prosesnya dengan rotasi kunci.
• Workload non-produksi yang memerlukan akses permanen, seperti pipeline continuous integration (CI).
• Sistem rotasi kunci yang mencegah kunci digunakan setelah jangka waktu tertentu. Untuk mempelajari strategi rotasi kunci yang direkomendasikan, lihat Rotasi kunci akun layanan.

Untuk membantu mencegah pemadaman layanan, sebaiknya Anda tidak menetapkan expiry time kecuali jika constraints/iam.disableServiceAccountKeyCreation batasan kebijakan organisasi diterapkan dalam jangka waktu yang lama. Saat menetapkan expiry time, Anda juga harus berhenti menerapkan batasan constraints/iam.disableServiceAccountKeyCreation. Untuk mengetahui detail tentang batasan ini, lihat Membatasi masa pakai kunci akun layanan.

Penting: Jika batasan constraints/iam.disableServiceAccountKeyCreation tidak diterapkan, Anda harus bekerja sama dengan pengguna project, folder, atau organisasi untuk mengonfirmasi bahwa tidak satu pun dari sumber daya yang ada memerlukan kunci akun layanan permanen. Jika resource memerlukan kunci akun layanan permanen dan Anda menetapkan expiry time, Anda dapat menyebabkan gangguan.

Untuk menyetel expiry time, lakukan hal berikut:

1. Identifikasi project, folder, atau organisasi tempat Anda ingin menetapkan expiry time untuk kunci akun layanan.
2. Tambahkan kebijakan organisasi yang menerapkan batasan constraints/iam.serviceAccountKeyExpiryHours. Setelah Anda menerapkan batasan ini untuk project, folder, atau organisasi, expiry time akan berlaku untuk semua kunci akun layanan yang baru dibuat dalam resource induk tersebut. Kunci yang ada tidak terpengaruh.

Expiry time diukur dalam jam. Sebagai praktik terbaik, gunakan expiry time yang singkat, seperti 8 jam; 24 jam (1 hari); atau 168 jam (7 hari). Expiry time yang singkat membantu memastikan tim Anda memiliki proses yang teruji dengan baik untuk mengupdate kunci. Mulailah dengan expiry time tersingkat yang memenuhi kebutuhan Anda dan tingkatkan hanya jika diperlukan.