Topik ini menunjukkan cara mengonfigurasi izin Identity and Access Management (IAM) untuk skenario jaringan. Bagian ini berisi panduan tentang peran IAM yang akan diberikan ke peran fungsional terkait jaringan di perusahaan Anda untuk skenario tersebut. Konten ini terutama ditargetkan untuk administrator jaringan dan karyawan yang mengelola tugas jaringan untuk sebuah organisasi. Semua skenario yang dijelaskan di bawah ini mengasumsikan bahwa organisasi Google Cloud telah dikonfigurasi sebelumnya.
Dokumen ini tidak menjelaskan secara detail peran dan izin jaringan. Untuk penjelasan mendetail tentang peran dan izin yang terkait dengan API komputasi dan jaringan, baca Peran IAM Compute Engine bawaan.
Tim tunggal mengelola keamanan & jaringan untuk organisasi
Dalam skenario ini, sebuah organisasi besar memiliki tim pusat yang mengelola kontrol keamanan dan jaringan untuk seluruh organisasi. Developer tidak memiliki izin untuk mengubah setelan jaringan atau keamanan yang ditentukan oleh tim keamanan dan jaringan, tetapi mereka diberi izin untuk membuat resource seperti virtual machine di subnet bersama.
Untuk mempermudah hal ini, organisasi menggunakan VPC bersama (Virtual Private Cloud) VPC bersama memungkinkan pembuatan jaringan VPC ruang IP RFC 1918 yang dapat digunakan oleh project terkait (project layanan). Developer yang menggunakan project terkait dapat membuat instance VM di ruang jaringan VPC bersama. Admin jaringan dan keamanan organisasi dapat membuat subnet, VPN, dan aturan firewall yang dapat digunakan oleh semua project dalam jaringan VPC.
Tabel di bawah ini menjelaskan peran IAM yang perlu diberikan kepada tim keamanan dan admin serta tim pengembangan, berikut dengan level resource tempat peran tersebut diberikan.
Resource: | Organisasi | |
---|---|---|
Peran: | Shared VPC Admin Network Admin Security Admin |
|
Akun utama: | Tim admin keamanan & jaringan |
Resource: | Project Host | Peran ini memberikan izin untuk menggunakan subnet yang telah dibagikan oleh VPC bersama. |
---|---|---|
Peran: | Pengguna jaringan | |
Akun utama: | Developer |
Resource: | Project layanan | Perhatikan bahwa peran ini memberikan izin untuk menggunakan alamat IP Eksternal. Lihat catatan di bawah untuk mendapatkan panduan tentang cara mencegah tindakan ini. |
---|---|---|
Peran: | compute.instanceAdmin | |
Akun utama: | Developer |
Untuk skenario ini, Anda memerlukan tiga kebijakan izin terpisah: satu untuk organisasi, satu untuk project host, dan satu untuk project layanan.
Kebijakan izin pertama, yang perlu dipasang di level organisasi, memberikan peran yang diperlukan jaringan dan keamanan untuk mengelola project host VPC bersama. Termasuk kemampuannya untuk mengaitkan project layanan dengan project host. Hal ini juga memberi tim jaringan dan keamanan kemampuan untuk mengelola semua resource jaringan dan keamanan di semua project dalam organisasi.
{
"bindings": [
{
"role": "roles/compute.xpnAdmin",
"members": [
"group:sec-net@example.com"
]
},
{
"role":"roles/compute.networkAdmin",
"members": [
"group:sec-net@example.com"
]
},
{
"role": "roles/compute.securityAdmin",
"members": [
"group:sec-net@example.com"
]
}
]
}
Kebijakan izin kedua harus dikaitkan dengan project host dan mengizinkan developer di organisasi tersebut untuk menggunakan jaringan bersama dalam project host VPC bersama.
{
"bindings": [
{
"role": "roles/compute.networkUser",
"members": [
"group:developers@example.com"
]
}
]
}
Kebijakan izin ketiga harus dikaitkan dengan setiap project layanan. Dengan ini, developer dapat menggunakan project untuk mengelola instance dalam project layanan dan memanfaatkan kemampuan ini untuk menggunakan subnet bersama dalam project host.
Anda dapat menempatkan semua project layanan dalam folder dan menetapkan kebijakan izin khusus ini pada tingkat hierarki tersebut. Dengan demikian, semua project yang dibuat dalam folder tersebut akan mewarisi izin yang ditetapkan pada folder tempat project layanan dibuat.
Anda juga perlu memberikan peran Network User dalam project layanan kepada developer.
{
"bindings": [
{
"role": "roles/compute.networkUser",
"members": [
"group:developers@example.com"
]
},
{
"role": "roles/compute.instanceAdmin",
"members": [
"group:developers@example.com"
]
}
]
}
Praktik terbaiknya adalah menggunakan grup untuk mengelola akun utama. Pada contoh di atas,
Anda akan menambahkan ID pengguna dari pengguna yang mengelola kontrol keamanan & jaringan
ke grup sec-net
, dan developer ke grup developers
.
Jika perlu mengubah siapa yang dapat menjalankan fungsi, Anda hanya perlu
menyesuaikan keanggotaan grup, sehingga tidak perlu memperbarui kebijakan izin.
Tim jaringan & keamanan terpisah
Dalam skenario ini, sebuah organisasi besar memiliki dua tim pusat: satu yang mengelola kontrol keamanan, dan satu lagi yang mengelola semua resource jaringan lainnya untuk seluruh organisasi. Developer tidak memiliki izin untuk mengubah setelan jaringan atau keamanan yang ditentukan oleh tim keamanan dan jaringan, tetapi mereka diberi izin untuk membuat resource seperti virtual machine di subnet bersama.
Seperti pada skenario pertama, VPC bersama akan digunakan dan izinnya dikonfigurasikan sesuai untuk ketiga grup (jaringan, keamanan, dan developer).
Tabel di bawah ini menjelaskan peran IAM yang perlu diberikan kepada tim keamanan dan admin serta tim pengembangan, dan juga level resource tempat peran diberikan.
Resource: | Organisasi | |
---|---|---|
Peran: | Shared VPC Admin Network Admin |
|
Akun utama: | Tim Network Admin |
Resource: | Organisasi | |
---|---|---|
Peran: | Security Admin Organization Admin |
|
Akun utama: | Tim keamanan |
Resource: | Project Host | Peran ini memberikan izin untuk menggunakan subnet yang telah dibagikan oleh VPC bersama. |
---|---|---|
Peran: | Pengguna jaringan | |
Akun utama: | Developer |
Resource: | Project layanan | Perhatikan bahwa peran ini memberikan izin untuk menggunakan alamat IP Eksternal. Lihat catatan di bawah untuk mendapatkan panduan tentang cara mencegah tindakan ini. |
---|---|---|
Peran: | compute.instanceAdmin | |
Akun utama: | Developer |
Untuk skenario ini, Anda memerlukan tiga kebijakan izin terpisah: satu untuk organisasi, satu untuk project host, dan satu untuk project layanan.
Kebijakan izin pertama, yang perlu dipasang di level organisasi, memberi tim jaringan peran yang diperlukan untuk mengelola project host VPC bersama dan untuk mengelola semua resource jaringan. Termasuk kemampuan untuk mengaitkan project layanan dengan project host. Peran admin jaringan juga memberi tim jaringan kemampuan untuk melihat aturan firewall, tetapi tidak dapat mengubahnya. Selain itu, tim keamanan juga dapat menetapkan kebijakan izin serta mengelola aturan firewall dan sertifikat SSL di semua project dalam organisasi.
{
"bindings": [
{
"role": "roles/compute.xpnAdmin",
"members": [
"group:networks@example.com"
]
},
{
"role": "roles/compute.networkAdmin",
"members": [
"group:networks@example.com"
]
},
{
"role": "roles/compute.securityAdmin",
"members": [
"group:security@example.com"
]
},
{
"role": "roles/resourcemanager.organizationAdmin",
"members": [
"group:security@example.com"
]
}
]
}
Kebijakan izin kedua harus dikaitkan dengan project host. Kebijakan izin ini memungkinkan developer di organisasi untuk menggunakan jaringan bersama dalam project host VPC bersama.
{
"bindings": [
{
"role": "roles/compute.networkUser",
"members": [
"group:developers@example.com"
]
}
]
}
Kebijakan izin ketiga harus dikaitkan dengan setiap project layanan. Dengan ini, developer dapat menggunakan project untuk mengelola instance dalam project layanan dan memanfaatkan kemampuan ini untuk menggunakan subnet bersama dalam project host.
Anda dapat menempatkan semua project layanan dalam folder dan menetapkan kebijakan izin khusus ini pada tingkat hierarki tersebut. Dengan demikian, semua project yang dibuat dalam folder tersebut akan mewarisi izin yang ditetapkan pada folder tempat project layanan dibuat.
{
"bindings": [
{
"role": "roles/compute.networkUser",
"members": [
"group:developers@example.com"
]
},
{
"role": "roles/compute.instanceAdmin",
"members": [
"group:developers@example.com"
]
}
]
}
Setiap tim dapat mengelola jaringannya sendiri
Sebuah perusahaan digital native ingin memberi tim pengembangannya kemampuan untuk bekerja secara mandiri. Mereka tidak memiliki tim admin IT pusat dan memercayakan tim mereka untuk mengelola semua aspek proyek.
Meskipun demikian, mereka juga ingin dapat menerapkan kontrol yang relatif longgar agar mereka dapat mengadopsi konfigurasi yang lebih formal seiring bertumbuhnya perusahaan dan produk mereka memasuki ketersediaan tinggi.
Untuk menerapkan skenario ini, setiap tim developer diberi foldernya sendiri. Struktur ini memastikan bahwa setiap project yang dibuat di bawah folder mewarisi izin yang sesuai, sekaligus memungkinkan setiap tim untuk bekerja secara independen. Setiap tim tetap harus mengikuti prinsip hak istimewa terendah saat menetapkan kebijakan izin untuk resource-nya sendiri.
Praktik terbaiknya adalah dengan membuat grup terpisah untuk mengerjakan tugas logis. Meskipun awalnya anggota tim yang sama akan mengelola resource jaringan dan resource yang sesungguhnya dalam project.
Pendekatan ini memudahkan pembatasan akses ke resource yang dibutuhkan staf sementara atau mungkin staf baru yang memerlukan pelatihan sebelum mereka dapat memodifikasi resource jaringan. Hal ini juga memungkinkan untuk mengubah siapa yang memiliki akses ke resource tanpa harus mengubah kebijakan izin setiap kali terjadi pergantian personel.
Resource: | Folder | Akun layanan dapat digunakan untuk membuat dan memiliki project. |
---|---|---|
Peran: | Project Creator Folder Admin |
|
Akun utama: | Pimpinan Tim Developer Akun layanan |
Resource: | Folder | |
---|---|---|
Peran: | Network Admin Security Admin |
|
Akun utama: | Tim jaringan & keamanan |
Resource: | Folder | Peran ini memungkinkan developer mengelola semua aspek BigQuery dan Compute Engine. |
---|---|---|
Peran: | Instance Admin BigQuery Admin |
|
Akun utama: | Developer |
Tindakan ini memerlukan kebijakan izin yang terikat di setiap folder yang dialokasikan milik tim.
{
"bindings": [
{
"role": "roles/resourcemanager.foldersAdmin",
"members": [
"group:devteamleads01@example.com",
"serviceAccount:dev01-project-creator@shared-resources-proj.iam.gserviceaccount.com"
]
},
{
"role":"roles/resourcemanager.projectCreator",
"members": [
"group:devteamleads01@example.com",
"serviceAccount:dev01-project-creator@shared-resources-proj.iam.gserviceaccount.com"
]
},
{
"role": "roles/compute.securityAdmin",
"members": [
"group:net-sec-dev01@example.com"
]
},
{
"role": "roles/compute.networkAdmin",
"members": [
"group:net-sec-dev01@example.com"
]
},
{
"role": "roles/compute.instanceAdmin",
"members": [
"group:dev01@example.com"
]
},
{
"role": "roles/bigquery.admin",
"members": [
"group:dev01@example.com"
]
}
]
}