Ringkasan mTLS backend dengan identitas workload terkelola

Pratinjau

Fitur ini tunduk pada "Persyaratan Penawaran Pra-GA" di bagian Persyaratan Layanan Umum dari Persyaratan Khusus Layanan. Fitur pra-GA tersedia "sebagaimana adanya" dan mungkin memiliki dukungan terbatas. Untuk mengetahui informasi selengkapnya, lihat deskripsi tahap peluncuran.

Anda dapat mencapai mTLS backend dengan atau tanpa identitas workload terkelola. Untuk mempelajari lebih lanjut mTLS backend tanpa identitas beban kerja terkelola, lihat Ringkasan TLS yang diautentikasi backend dan mTLS backend.

Dokumen ini memberikan ringkasan tentang penggunaan identitas workload terkelola untuk mencapai TLS timbal balik (mTLS) antara Load Balancer Aplikasi dan backend-nya. Managed workload identity secara otomatis menyediakan dan mengelola sertifikat X.509 dari Certificate Authority Service.

Catatan: Untuk Pratinjau, managed workload identity hanya dapat ditetapkan ke layanan backend Load Balancer Aplikasi eksternal global.

Informasi dalam dokumen ini didasarkan pada konsep yang diperkenalkan dalam dokumen berikut:

• Ringkasan identitas workload terkelola
• Secure Production Identity Framework For Everyone (SPIFFE)
• Certificate Authority Service
• Ringkasan TLS yang diautentikasi backend dan mTLS backend

Pengantar identitas workload terkelola untuk load balancer

Tanpa managed workload identity, penyiapan mTLS backend memerlukan konfigurasi beberapa resource. Saat Anda menetapkan identitas terkelola ke layanan backend load balancer, identitas workload terkelola akan otomatis membuat resource yang diperlukan untuk mTLS, seperti sertifikat klien, konfigurasi kepercayaan, dan konfigurasi autentikasi backend.

Untuk mTLS backend, resource layanan backend load balancer bertindak sebagai workload sumber yang mengautentikasi dirinya ke backend, yang merupakan workload tujuan.

Anda dapat menetapkan identitas terkelola—yang diwakili oleh SPIFFE ID— ke layanan backend load balancer. Google Cloud Certificate Authority Service secara otomatis menyediakan sertifikat X.509 untuk SPIFFE ID. Sertifikat X.509 untuk ID SPIFFE ini juga dikenal sebagai Dokumen Identitas yang Dapat Diverifikasi (SVID) SPIFFE. Layanan backend load balancer dan backend-nya menggunakan SVID untuk saling mengautentikasi melalui autentikasi mTLS.

Diagram berikut menunjukkan load balancer (beban kerja sumber) dan backend (beban kerja tujuan) yang saling mengautentikasi menggunakan identitas beban kerja terkelola.

mTLS backend menggunakan managed workload identity (klik untuk memperbesar).

Berikut adalah contoh X.509-SVID yang berfungsi sebagai wrapper untuk SPIFFE ID. ID SPIFFE, yang ditampilkan sebagai URI, dienkode dalam Nama Alternatif Subjek (SAN) sertifikat X.509.

Issuer:
    C=US
    O=Example Inc.
    CN=Example CA

Validity:
    Not Before: Jun 14 00:00:00 2025 GMT
    Not After : Jun 16 00:00:00 2025 GMT

Subject (Distinguished Name):
    C=US
    O=Example Inc.
    OU=Production
    CN=api.example.com

Subject Public Key Info:
    Public Key Algorithm: RSA Encryption
    RSA Public-Key: (2048 bit)

X.509v3 Extensions:
    Subject Alternative Name (SAN):
        DNS: api.example.com
        URI: spiffe://WORKLOAD_IDENTITY_POOL_ID.global.PROJECT_NUMBER.workload.id.goog/ns/NAMESPACE_ID/sa/MANAGED_IDENTITY_ID

Output ini mencakup nilai-nilai berikut:

• WORKLOAD_IDENTITY_POOL_ID: ID workload identity pool
• PROJECT_NUMBER: nomor project Google Cloud Anda
• NAMESPACE_ID: ID namespace
• MANAGED_IDENTITY_ID: ID identitas terkelola

Manfaat menggunakan identitas workload terkelola

Berikut adalah beberapa manfaat menggunakan identitas workload terkelola untuk mTLS backend:

• Peningkatan keamanan: dengan bergabung ke workload identity pool, load balancer dan backend-nya menjadi bagian dari domain tepercaya. Google Cloud Jika digunakan bersama dengan mTLS backend, load balancer dan workload backend akan saling mengautentikasi. Autentikasi bersama ini mencegah workload yang tidak sah mengakses layanan Anda dan mengenkripsi data dalam pengiriman.

• Pengelolaan sertifikat otomatis: setelah pengesahan beban kerja berhasil, Google Cloud secara otomatis menyediakan dan merotasi sertifikat X.509 untuk beban kerja yang berpartisipasi dalam domain tepercaya kumpulan identitas beban kerja. Pengelolaan otomatis sertifikat X.509 ini menghilangkan proses pengelolaan sertifikat manual yang kompleks dan rentan error.

• Identitas yang dapat dioperasikan: workload identity pool menggunakan framework SPIFFE—standar untuk mengelola identitas di seluruh sistem terdistribusi, yang memungkinkan autentikasi dan otorisasi dalam arsitektur berbasis microservice modern.

• Tata kelola terpusat: workload identity pool menyediakan titik kontrol terpusat. Administrator dapat menentukan domain tepercaya dan membuat kebijakan pengesahan untuk mengatur workload mana yang dapat menerima sertifikat X.509 untuk identitas terkelola.

Arsitektur mTLS backend menggunakan identitas workload terkelola

Komponen berikut bekerja sama untuk mencapai mTLS backend menggunakan managed workload identity:

• Layanan backend load balancer (Compute Engine API)
• Domain tepercaya Identity and Access Management (Identity and Access Management API)
• Kumpulan otoritas sertifikat (Certificate Authority Service API)
• Konfigurasi autentikasi backend (Network Security API)
• Konfigurasi kepercayaan Certificate Manager (Certificate Manager API)
• Sertifikat identitas terkelola Certificate Manager (Certificate Manager API)

Diagram berikut menunjukkan identitas terkelola pada layanan backend load balancer, yang memungkinkan load balancer mengautentikasi dirinya sendiri ke backend. Dalam diagram, langkah 1-3 merepresentasikan resource yang dibuat secara eksplisit, sedangkan langkah 4-5 merepresentasikan resource yang dibuat secara otomatis.

1. Konfigurasi kumpulan CA Certificate Authority Service untuk menerbitkan sertifikat ke identitas workload terkelola.
2. Konfigurasi domain tepercaya dengan membuat workload identity pool. Kumpulan ini memerlukan namespace, identitas terkelola, kebijakan pengesahan, resource config penerbitan sertifikat inline, dan resource config kepercayaan inline.
3. Konfigurasi layanan backend load balancer dengan identitas terkelola.

4. Identitas beban kerja terkelola secara otomatis membuat sertifikat identitas terkelola Certificate Manager dan konfigurasi kepercayaan Certificate Manager.

   Sertifikat identitas terkelola Certificate Manager dibuat berdasarkan konfigurasi penerbitan sertifikat di workload identity pool. Konfigurasi kepercayaan Certificate Manager disinkronkan dengan konfigurasi kepercayaan inline workload identity pool.

5. Managed workload identity secara otomatis membuat konfigurasi autentikasi backend.

   Konfigurasi kepercayaan Certificate Manager dilampirkan ke konfigurasi autentikasi backend. Sertifikat identitas terkelola (X.509-SVID) Certificate Manager juga dilampirkan ke konfigurasi autentikasi backend, yang kemudian digunakan untuk melakukan autentikasi ke backend.

Untuk mempelajari lebih lanjut konfigurasi mTLS backend menggunakan identitas terkelola, lihat Menyiapkan mTLS backend menggunakan identitas beban kerja terkelola.

Arsitektur mTLS backend menggunakan identitas beban kerja terkelola (klik untuk memperbesar).

Resource yang dibuat selama mTLS backend menggunakan identitas terkelola

Seperti yang ditunjukkan dalam diagram arsitektur sebelumnya, saat menetapkan identitas terkelola ke layanan backend, Anda tidak perlu mengonfigurasi konfigurasi autentikasi backend, konfigurasi kepercayaan Certificate Manager, dan sertifikat Certificate Manager. Resource ini dibuat secara otomatis oleh managed workload identity.

Bagian ini akan membahas lebih lanjut berbagai bagian dari proses konfigurasi identitas terkelola yang berfokus pada resource yang dibuat secara eksplisit dan yang dibuat secara otomatis.

Resource yang dibuat secara eksplisit

Resource berikut harus dibuat secara eksplisit saat mengonfigurasi mTLS backend menggunakan managed workload identity.

Kumpulan certificate authority

Untuk mengonfigurasi identitas workload terkelola untuk load balancer, Anda harus mengonfigurasi otoritas sertifikat terlebih dahulu, dan secara opsional, satu atau beberapa CA subordinat. Penyiapan ini disebut sebagai hierarki CA.

Anda dapat menggunakan kumpulan CA Service untuk menyiapkan hierarki ini.

Workload identity pool terikat ke CA pool dengan memperbarui workload identity pool menggunakan konfigurasi penerbitan sertifikat inline.

Workload identity terkelola

Anda perlu membuat identitas workload terkelola di namespace workload identity pool. Managed identity adalah SPIFFE ID yang ditentukan sepenuhnya dan digunakan dalam SVID yang ditampilkan oleh workload load balancer.

Kebijakan pengesahan

Kebijakan pengesahan berisi aturan untuk Google Cloud IAM guna memverifikasi apakah layanan backend memenuhi syarat untuk menerima sertifikat X.509 untuk identitas terkelola yang ditetapkan ke layanan backend.

Jika verifikasi kebijakan pengesahan berhasil, IAM akan meminta sertifikat X.509 untuk identitas terkelola dari Certificate Authority Service. Sertifikat X.509 dibuat di kumpulan CA yang terikat ke identitas terkelola. Layanan CA menyediakan sertifikat melalui pencerminan identitas, dengan ID SPIFFE yang dikonfigurasi dicerminkan ke sertifikat X.509.

Konfigurasi penerbitan sertifikat inline

Saat menyiapkan workload identity pool, Anda mengonfigurasi konfigurasi penerbitan sertifikat inline. Konfigurasi ini menentukan kumpulan CA mana dari instance Certificate Authority Service Anda yang digunakan untuk membuat sertifikat X.509 bagi identitas dalam workload identity pool. File konfigurasi juga menentukan masa berlaku sertifikat, persentase periode rotasi, dan algoritma kunci.

Kumpulan CA menerbitkan sertifikat X.509 ke identitas workload terkelola setelah pemberlakuan kebijakan pengesahan berhasil.

Konfigurasi kepercayaan inline workload identity pool

Secara default, workload Anda dalam domain tepercaya yang sama dapat saling melakukan autentikasi menggunakan identitas workload terkelola. Jika Anda ingin beban kerja yang berada di domain tepercaya yang berbeda untuk saling mengautentikasi, Anda harus secara eksplisit menyatakan hubungan kepercayaan di kumpulan identitas beban kerja. Anda melakukannya dengan membuat konfigurasi kepercayaan inline yang mengenali dan menerima sertifikat dari domain kepercayaan lain. Sertifikat ini digunakan untuk membangun rantai kepercayaan dan memverifikasi identitas beban kerja dari domain lain.

Konfigurasi kepercayaan inline berisi serangkaian anchor kepercayaan yang digunakan identitas workload terkelola untuk memvalidasi sertifikat peer. Konfigurasi kepercayaan Certificate Manager mencakup penyimpanan tepercaya SPIFFE, yang tetap disinkronkan dengan konfigurasi kepercayaan inline workload identity pool.

Karena workload identity pool terikat ke CA pool, workload identity pool secara otomatis memercayai sertifikat root dari CA pool yang sama. Anda tidak perlu menambahkan root CA pool ke konfigurasi kepercayaan inline karena kepercayaan tersebut sudah bawaan.

Layanan backend (Compute Engine API)

Untuk menetapkan identitas terkelola ke load balancer, Anda perlu mengonfigurasi layanan backend load balancer sehingga atribut tlsSettings-nya mengarah ke properti identity baru (backendService.tlsSettings.identity).

Perhatikan batasan berikut yang berlaku saat menggunakan kolom identity pada layanan backend load balancer:

• Jika Anda menetapkan properti identity, Anda tidak dapat menetapkan kolom berikut secara manual pada atribut tlsSettings:

  • tlsSettings.sni
  • tlsSettings.subjectAltNames
  • tlsSettings.authenticationConfig

• Kolom identity hanya dapat ditetapkan selama pembuatan layanan backend.

• Kolom identity tidak dapat diubah. Setelah ditetapkan ke layanan backend load balancer, alamat IP tidak dapat diupdate atau dihapus.

Sumber daya yang dibuat secara otomatis

Setelah Anda menetapkan properti identity (backendService.tlsSettings.identity) di layanan backend load balancer, resource berikut di Certificate Manager API dan Network Security API akan dibuat secara otomatis oleh identitas workload terkelola.

Resource yang dibuat secara otomatis dibuat dalam project yang sama dengan layanan backend dan menggunakan kuota standar dalam project tersebut.

Konfigurasi kepercayaan Certificate Manager (Certificate Manager API)

Konfigurasi tepercaya Certificate Manager dibuat secara otomatis dan tidak dapat diedit atau dihapus secara langsung.

Konfigurasi tepercaya Certificate Manager berisi kolom yang disebut spiffeTrustStores. Kolom spiffeTrustStores berisi paket kepercayaan yang terkait dengan domain tepercaya workload identity pool dan paket kepercayaan tambahan yang ditentukan oleh kolom additionalTrustBundles dalam konfigurasi kepercayaan inline workload identity pool.

Untuk memvalidasi sertifikat SPIFFE, kolom spiffeTrustStores dalam konfigurasi tepercaya Certificate Manager diaktifkan secara otomatis saat menggunakan identitas beban kerja terkelola. Dengan kolom spiffeTrustStores diaktifkan, kolom trustStores tetap kosong.

Kolom spiffeTrustStores adalah struktur data peta dengan pasangan nilai kunci sebagai berikut:

• Kuncinya dapat berupa domain tepercaya yang terkait dengan kumpulan workload identity (dalam format yang diakhiri dengan .workload.id.goog), atau domain tepercaya tambahan.
• Nilai adalah objek TrustStore. Objek ini berisi kumpulan sertifikat root tepercaya (dikenal sebagai paket kepercayaan) yang digunakan untuk memvalidasi sertifikat SPIFFE dari domain kepercayaan tertentu tersebut.

Pada dasarnya, peta ini memungkinkan load balancer dikonfigurasi untuk mempercayai penyimpanan dari beberapa domain keamanan yang berbeda. Saat backend menyajikan sertifikatnya, load balancer akan mengekstrak ID SPIFFE, mengidentifikasi domain tepercaya, dan menggunakan peta untuk mencari trust store yang benar yang diperlukan untuk memvalidasi sertifikat tersebut.

Sertifikat identitas terkelola Certificate Manager (Certificate Manager API)

Sertifikat identitas terkelola Certificate Manager dibuat secara otomatis oleh identitas workload terkelola. Sertifikat identitas terkelola Certificate Manager bersifat hanya baca dan tidak dapat diedit atau dihapus secara langsung menggunakan Certificate Manager API. Sertifikat identitas terkelola Certificate Manager didasarkan pada konfigurasi penerbitan sertifikat inline, yang ditentukan di workload identity pool.

Sertifikat identitas terkelola Certificate Manager memiliki properti managedIdentity, yang mengidentifikasinya sebagai sertifikat identitas terkelola. Resource sertifikat identitas terkelola Certificate Manager menyimpan X.509-SVID dalam format berenkode PEM. X.509-SVID ini berisi SPIFFE ID yang dienkode sebagai URI di kolom SAN. ID SPIFFE ini sesuai dengan identitas terkelola di workload identity pool.

Cakupan sertifikat identitas yang dikelola Certificate Manager adalah CLIENT_AUTH, yang menunjukkan bahwa sertifikat ini digunakan sebagai sertifikat klien dalam mTLS backend.

Konfigurasi autentikasi backend (Network Security API)

Konfigurasi autentikasi backend dibuat secara otomatis oleh workload identity terkelola. Konfigurasi autentikasi backend bersifat hanya baca dan tidak dapat diedit atau dihapus secara langsung menggunakan Network Security API.

Konfigurasi kepercayaan Certificate Manager dilampirkan ke konfigurasi autentikasi backend.

Sertifikat identitas yang dikelola Pengelola Sertifikat juga dilampirkan ke konfigurasi autentikasi backend, dan digunakan sebagai X.509-SVID dalam permintaan mTLS backend antara load balancer dan workload tujuan.

Batasan

• mTLS backend dengan identitas beban kerja terkelola hanya dapat dikonfigurasi untuk Load Balancer Aplikasi eksternal global. Load Balancer Aplikasi Klasik tidak mendukung mTLS backend.

• mTLS backend tidak didukung untuk backend NEG internet global.

• Jika Anda menetapkan identitas terkelola ke layanan backend (backendService.tlsSettings.identity), Anda tidak dapat menetapkan kolom berikut secara manual pada properti tlsSettings layanan backend:

  • backendService.tlsSettings.sni
  • backendService.tlsSettings.subjectAltNames
  • backendService.tlsSettings.authenticationConfig

• Identitas terkelola hanya dapat ditetapkan pada saat pembuatan layanan backend.

• Identitas terkelola tidak dapat diubah. Setelah menetapkan identitas terkelola ke layanan backend load balancer, identitas tersebut tidak dapat diupdate atau dihapus.

Langkah berikutnya

• Menyiapkan mTLS backend menggunakan managed workload identity