Topik ini menunjukkan cara mengonfigurasi izin Identity and Access Management (IAM) untuk serangkaian contoh skenario penagihan. Bagian ini memberikan panduan tentang peran IAM yang akan diberikan kepada peran fungsional terkait penagihan di perusahaan Anda untuk skenario tersebut. Contoh ini terutama ditargetkan pada administrator penagihan dan karyawan yang mengelola tugas penagihan untuk organisasi.
Dokumen ini tidak menjelaskan secara detail peran dan izin penagihan. Untuk deskripsi mendetail tentang peran dan izin untuk Billing API, baca halaman Kontrol Akses untuk Penagihan.
Perusahaan kecil yang mengonfigurasi izin penagihan
Dalam skenario ini, sebuah perusahaan kecil mencoba mengonfigurasi dan menggunakan akun penagihan Google. Ada beberapa engineer yang mengembangkan dan mengelola aplikasi, tetapi tidak satu pun dari mereka yang mengelola penagihan. Mereka memiliki manajer kantor, yang bertanggung jawab untuk mencocokkan pembayaran dengan invoice, tetapi karena alasan kepatuhan, manajer kantor tidak diizinkan untuk memiliki akses ke resource Google Cloud dalam project. CEO juga memegang dan mengelola detail kartu kredit.
Tabel di bawah ini menjelaskan peran IAM penagihan yang dapat diberikan oleh Administrator Organisasi (yang merupakan CEO dalam skenario ini) kepada persona lain di perusahaan, dan level resource yang perannya diberikan.
Peran: | Organization Administrator | Peran Administrator Organisasi memberi CEO kemampuan untuk memberikan izin kepada Manajer Kantor. |
---|---|---|
Resource: | Organisasi | |
Utama: | CEO |
Peran: | Billing Account Administrator | Peran Billing Account Administrator memungkinkan manajer kantor dan CEO mengelola pembayaran dan invoice tanpa memberikan izin untuk melihat konten project. |
---|---|---|
Resource: | Organisasi | |
Utama: | Manajer Kantor, CEO |
Kebijakan izinkan yang dilampirkan ke resource organisasi untuk skenario ini akan terlihat seperti berikut:
{
"bindings": [
{
"role": "roles/resourcemanager.organizationAdmin",
"members": [
"user:ceo@example.com"
]
},
{
"role": "roles/billing.admin",
"members": [
"group:finance-admins-group@example.com"
]
}
]
}
Praktik terbaiknya adalah menggunakan grup untuk mengelola akun utama. Pada contoh
di atas, untuk binding kedua, Anda akan menambahkan CEO dan manajer kantor ke
finance-admins-group
. Jika perlu mengubah siapa yang dapat melakukan
fungsi, Anda hanya perlu menyesuaikan keanggotaan grup, sehingga tidak perlu
memperbarui kebijakan izinkan. Sehingga dua akun pengguna individual tidak muncul di
binding peran.
Tim keuangan yang mengelola anggaran
Dalam skenario ini, sebuah organisasi besar ingin tim keuangan di setiap divisi dapat menetapkan anggaran dan melihat pengeluaran tim di divisi tersebut, tetapi tidak memiliki akses ke resource Google Cloud. Mereka tidak keberatan jika developer melihat pengeluaran untuk project mereka sendiri, tetapi gambaran umum pengeluaran tidak boleh diizinkan kepada developer.
Berikan peran dalam tabel di bawah kepada manajer keuangan dari setiap divisi dan developer:
Peran: | Billing Account Administrator | Peran ini memberikan izin kepada manajer keuangan dari setiap divisi untuk menetapkan anggaran dan melihat pengeluaran untuk akun penagihan di divisi mereka, tetapi tidak memberi mereka izin untuk melihat isi project. |
---|---|---|
Resource: | Akun Penagihan | |
Utama: | Manajer keuangan setiap divisi |
Peran: | Billing Account Viewer | Peran Billing Account Viewer memungkinkan developer melihat pengeluaran untuk akun penagihan. |
---|---|---|
Resource: | Akun Penagihan | |
Utama: | Developer project. |
Untuk skenario ini, gunakan konsol penagihan untuk memberikan peran Billing Account Administrator kepada pengelola keuangan di akun penagihan. Selain itu, berikan peran Billing Account Viewer kepada developer di akun penagihan.
Setelah selesai, kebijakan izinkan untuk akun penagihan akan terlihat seperti berikut:
{
"bindings": [
{
"role": "roles/billing.admin",
"members": [
"group:finance-admins-group@example.com"
]
},
{
"role": "roles/billing.viewer",
"members": [
"group:developers@example.com"
]
}
],
"etag": "BwUjMhCsNvY=",
"version": 1
}
Portal layanan mandiri pelanggan, Developer tidak dapat menyesuaikan penagihan
Dalam skenario ini, tim IT pusat pelanggan memberikan resource Google Cloud kepada developer sebagai bagian dari portal layanan mandiri mereka. Developer meminta akses ke project Google Cloud dan layanan cloud lainnya yang disetujui melalui portal. Pusat biaya developer membayar tim IT pusat untuk resource cloud yang terpakai.
Tim TI pusat harus mampu:
- Kaitkan project dengan akun penagihan.
- Nonaktifkan penagihan untuk project.
- Lihat informasi kartu kredit.
Mereka tidak boleh memiliki izin untuk melihat konten project.
Developer harus dapat melihat biaya sebenarnya dari resource Google Cloud yang digunakan, tetapi tidak dapat menonaktifkan penagihan, mengaitkan penagihan dengan project, dan melihat informasi kartu kredit.
Peran: | Billing Account Administrator | Peran Billing Account Administrator memberi departemen IT
izin untuk mengaitkan project dengan akun penagihan,
menonaktifkan penagihan untuk project, dan melihat informasi kartu kredit
untuk akun yang mereka jual kembali ke pelanggan mereka.
Ini tidak memberi mereka izin untuk melihat isi project. |
---|---|---|
Resource: | Akun Penagihan | |
Utama: | Departemen IT |
Peran: | Billing Account User | Peran Billing Account User memberi akun layanan izin untuk mengaktifkan penagihan (mengaitkan project dengan akun penagihan organisasi untuk semua project dalam organisasi) dan dengan demikian mengizinkan akun layanan untuk mengaktifkan API yang memerlukan penagihan yang akan diaktifkan. |
---|---|---|
Resource: | Organisasi | |
Utama: | Akun layanan yang digunakan untuk mengotomatiskan pembuatan project. |
Peran: | Billing Account Viewer | Peran Billing Account Viewer memungkinkan developer melihat pengeluaran untuk akun penagihan. |
---|---|---|
Resource: | Akun Penagihan | |
Utama: | Developer project. |
Untuk skenario ini, Anda memerlukan dua operasi terpisah untuk menetapkan kebijakan izinkan yang sesuai karena kebijakan tersebut melekat pada tingkat hierarki yang berbeda.
Gunakan konsol penagihan untuk memberikan peran Billing Account Administrator ke departemen IT di akun penagihan. Selain itu, berikan peran Billing Account Viewer kepada developer di akun penagihan.
Kemudian, Anda harus melampirkan kebijakan izinkan di tingkat organisasi. Kebijakan izin ini memberikan peran Pengguna Akun Penagihan ke akun layanan. Bagian ini serupa dengan berikut:
{
"bindings": [
{
"role": "roles/billing.user",
"members": [
"serviceAccount:my-project-creator@shared-resources-proj.iam.gserviceaccount.com"
]
}
],
"etag": "BwWKmjvelug=",
"version": 1
}
Developer yang membuat project yang ditagih
Perusahaan native digital berukuran besar ingin mengizinkan semua developernya untuk membuat project yang ditagih di akun organisasi yang ditagih tanpa memberikan hak Administrator Akun Penagihan kepada mereka.
Project harus mengaktifkan penagihan untuk memastikan bahwa API di luar default dapat diaktifkan. Jadi, jika developer membuat project, mereka harus mengaitkannya dengan akun penagihan untuk mengaktifkan API.
Peran: | Billing Account User | Peran Billing Account User memungkinkan developer untuk melampirkan akun penagihan ke project baru dalam organisasi. |
---|---|---|
Resource: | Organisasi | |
Utama: | Developer |
Kebijakan izinkan untuk skenario ini perlu dilampirkan pada tingkat organisasi, dan akan terlihat seperti berikut:
{
"bindings": [
{
"role": "roles/billing.user",
"members": [
"group:developers@example.com"
]
}
],
"etag": "BwUjMhCsNvY=",
"version": 1
}
Agregasi biaya
Dalam skenario ini, perusahaan ingin menghitung dan melacak berapa banyak biaya yang dikenakan kepada setiap tim, departemen, layanan, atau project. Misalnya, memantau biaya deployment pengujian setiap bulan.
Hal ini dapat dilacak menggunakan praktik berikut:
- Gunakan project untuk mengatur resource. Biaya ditampilkan per project dan ID project disertakan dalam ekspor penagihan.
- Anotasikan project dengan label yang merepresentasikan informasi pengelompokan
tambahan. Misalnya,
environment=test
. Label disertakan dalam ekspor penagihan untuk memungkinkan Anda mengelompokkan lebih lanjut. Namun, label pada project diberi izin dengan cara yang sama seperti metadata project lainnya, yang berarti pemilik project dapat mengubah label. Anda dapat mengedukasi karyawan tentang hal-hal yang tidak boleh diubah, lalu memantaunya (melalui log audit), atau hanya memberi mereka izin terperinci agar mereka tidak dapat mengubah metadata project.
Anda dapat mengekspor ke JSON dan CSV, tetapi solusi yang kami rekomendasikan adalah mengekspor langsung ke BigQuery. Hal ini mudah dikonfigurasi dari bagian ekspor penagihan pada konsol penagihan.
Jika setiap pusat biaya harus membayar invoice terpisah atau membayar dalam mata uang terpisah untuk beberapa beban kerja, akun penagihan terpisah untuk setiap pusat biaya diperlukan. Namun, pendekatan ini akan memerlukan perjanjian afiliasi yang ditandatangani untuk setiap akun penagihan.