Mengotomatiskan pengelolaan sertifikat TLS untuk gateway masuk Cloud Service Mesh menggunakan Certificate Authority Service
Tutorial ini menunjukkan cara operator platform menggunakan penerbit Certificate Authority Service (Layanan CA) untuk alat cert-manager guna mengotomatiskan pengelolaan sertifikat TLS untuk gateway masuk Cloud Service Mesh. Sertifikat memungkinkan gateway masuk untuk menghentikan traffic HTTPS dan TLS serta mTLS lainnya yang berasal dari klien di Virtual Private Cloud (VPC) Anda, tetapi di luar mesh layanan. Tutorial ini mengasumsikan Anda telah memiliki pengetahuan dasar tentang Kubernetes dan sertifikat TLS.
Pengantar
Cloud Service Mesh menyediakan sertifikat TLS ke setiap workload di mesh layanan. Sertifikat ini memungkinkan komunikasi yang dienkripsi dan TLS yang diautentikasi bersama (mTLS) antarbeban kerja di mesh layanan. Salah satu CA yang didukung akan menerbitkan dan menandatangani sertifikat.
Namun, Cloud Service Mesh tidak otomatis menyediakan sertifikat ke gateway masuk untuk traffic yang memasuki mesh layanan. Solusi umum adalah menggunakan alat cert-manager open source untuk mengotomatiskan pengelolaan sertifikat gateway ingress.
Alat cert-manager meminta sertifikat dari penerbit, yang mewakili otoritas sertifikasi (CA). Layanan CA adalah layanan Google Cloud yang memungkinkan Anda membuat CA pribadi Anda sendiri. Alat pengelola sertifikat dapat meminta sertifikat dari Layanan CA dengan menggunakan penerbit eksternal untuk Layanan CA open source.
CA pribadi dapat menerbitkan sertifikat TLS yang mengautentikasi dan mengenkripsi traffic di dalam jaringan internal. Gateway traffic masuk Cloud Service Mesh sering kali disiapkan untuk mengizinkan traffic masuk dari klien yang berada di dalam VPC Anda, tetapi di luar service mesh. Untuk traffic jaringan internal, Anda dapat menggunakan CA pribadi di Layanan CA untuk menerbitkan sertifikat untuk gateway masuk.
Tutorial ini menunjukkan cara menyiapkan alat cert-manager dan penerbit Layanan CA untuk mengotomatiskan penyediaan dan perpanjangan sertifikat TLS untuk gateway ingress. Alat cert-manager menyediakan sertifikat sebagai resource Secret Kubernetes dari jenis TLS. Saat memperpanjang sertifikat, alat cert-manager akan memperbarui resource Secret dengan sertifikat baru. Gateway masuk menjalankan Proxy Envoy, dan mendukung layanan penemuan secret (SDS) Envoy. SDS memungkinkan gateway masuk mulai menggunakan sertifikat baru tanpa memerlukan administrator untuk memulai ulang atau memuat ulang proses.
Proksi sidecar yang merupakan bagian dari mesh dapat memperoleh sertifikat TLS dari otoritas sertifikat CA Service atau Cloud Service Mesh. Dalam tutorial ini, Anda akan menggunakan Layanan CA untuk sertifikat proxy sidecar dan gateway ingress. Hal ini memungkinkan Anda menggunakan satu root CA untuk semua sertifikat TLS.
Diagram berikut menunjukkan resource yang Anda sediakan dalam tutorial ini.
Anda menyediakan Load Balancer Jaringan passthrough internal untuk gateway masuk. Load Balancer Jaringan passthrough internal
bukan proxy, sehingga
tidak menghentikan koneksi TCP atau melakukan handshake TLS. Sebagai gantinya, pod ini merutekan
koneksi ke pod deployment istio-ingressgateway
.
Secret hello-example-com-credential
berisi sertifikat dan kunci
pribadi. Gateway hello
mengonfigurasi pod deployment istio-ingressgateway
untuk menggunakan sertifikat dan kunci pribadi ini guna melakukan TLS handshake untuk
permintaan dengan nama host hello.example.com
.
Pod deployment google-cas-issuer
di namespace cert-manager
meminta sertifikat dari CA yang Anda buat di CA Service. Anda membuat
binding kebijakan Identity and Access Management yang memungkinkan pod ca-service-isser
meniru identitas akun layanan Google menggunakan
Workload Identity Federation untuk GKE. Anda
memberikan izin akun layanan Google ini untuk meminta sertifikat dari
CA di CA Service dengan membuat binding kebijakan IAM
di kumpulan CA.
Tujuan
- Mengonfigurasi Layanan CA
- Membuat cluster GKE
- Menginstal bidang kontrol Cloud Service Mesh
- Menginstal gateway traffic masuk
- Menginstal alat cert-manager
- Menginstal pengontrol penerbit CA Service
- Membuat penerbit sertifikat
- Men-deploy aplikasi sampel
- Memverifikasi solusi
- (Opsional) Menambahkan sertifikat CA ke penyimpanan kepercayaan
Biaya
Tutorial ini menggunakan komponen Google Cloud yang dapat ditagih berikut:
Untuk membuat perkiraan biaya berdasarkan proyeksi penggunaan Anda, gunakan kalkulator harga. Pengguna baru Google Cloud mungkin memenuhi syarat untuk mendapatkan uji coba gratis.
Setelah menyelesaikan tutorial ini, Anda dapat menghindari penagihan berkelanjutan dengan menghapus resource yang Anda buat. Untuk informasi selengkapnya, lihat Pembersihan.
Sebelum memulai
Di konsol Google Cloud, buka halaman pemilih project, lalu pilih atau buat project.
Pastikan penagihan diaktifkan untuk project Google Cloud Anda.
Di konsol Google Cloud, buka Cloud Shell.
Di bagian bawah Konsol Google Cloud, sesi Cloud Shell akan terbuka dan menampilkan perintah command line. Anda menggunakan Cloud Shell untuk menjalankan semua perintah dalam tutorial ini.
Tetapkan project konsol Google Cloud yang ingin Anda gunakan untuk tutorial ini:
gcloud config set core/project PROJECT_ID
Ganti PROJECT_ID dengan project ID project Cloud Anda.
Di dialog Izinkan Cloud Shell, klik Izinkan. Dengan mengklik Authorize, Anda mengizinkan perintah
gcloud
yang dijalankan di Cloud Shell untuk menggunakan kredensial pengguna Anda guna melakukan autentikasi ke Google API.Aktifkan Resource Manager, GKE, GKE Hub, certificate authority Cloud Service Mesh, dan CA Service API:
gcloud services enable \ cloudresourcemanager.googleapis.com \ container.googleapis.com \ gkehub.googleapis.com \ meshca.googleapis.com \ privateca.googleapis.com
Mengonfigurasi Layanan CA
Di bagian ini, Anda akan membuat CA root dan dua CA subordinat di Layanan CA. Satu CA subordinat menerbitkan sertifikat ke gateway entrance, dan CA subordinat lainnya menerbitkan sertifikat ke proxy sidecar di mesh.
Untuk memudahkan, Anda menggunakan project yang sama untuk cluster GKE dan root CA serta CA subordinat dalam tutorial ini. Di lingkungan Anda sendiri, Anda dapat menggunakan project yang berbeda untuk cluster GKE dan CA.
Di Cloud Shell, buat kumpulan CA yang akan digunakan untuk CA root:
gcloud privateca pools create ROOT_CA_POOL \ --location CA_LOCATION \ --tier enterprise
- ROOT_CA_POOL adalah nama kumpulan CA. Contoh,
root-ca-pool-tutorial
. - CA_LOCATION adalah lokasi kumpulan CA. Contoh,
us-central1
.
Anda dapat mencantumkan lokasi Layanan CA yang tersedia menggunakan perintah ini:
gcloud privateca locations list
- ROOT_CA_POOL adalah nama kumpulan CA. Contoh,
Buat dan aktifkan CA root:
gcloud privateca roots create ROOT_CA \ --auto-enable \ --key-algorithm ec-p384-sha384 \ --location CA_LOCATION \ --pool ROOT_CA_POOL \ --subject "CN=Example Root CA, O=Example Organization" \ --use-preset-profile root_unconstrained
- ROOT_CA adalah nama yang ingin Anda gunakan untuk root
CA. Contoh,
root-ca-tutorial
.
- ROOT_CA adalah nama yang ingin Anda gunakan untuk root
CA. Contoh,
Buat kumpulan CA yang akan digunakan untuk CA subordinat yang menerbitkan sertifikat ke gateway masuk:
gcloud privateca pools create SUBORDINATE_CA_POOL_GATEWAYS \ --location CA_LOCATION \ --tier devops
- SUBORDINATE_CA_POOL_GATEWAYS adalah nama kumpulan CA. Contoh,
subordinate-ca-mtls-pool-gateways-tutorial
.
- SUBORDINATE_CA_POOL_GATEWAYS adalah nama kumpulan CA. Contoh,
Buat dan aktifkan CA subordinat yang menerbitkan sertifikat ke gateway entrance:
gcloud privateca subordinates create SUBORDINATE_CA_GATEWAYS \ --auto-enable \ --issuer-location CA_LOCATION \ --issuer-pool ROOT_CA_POOL \ --key-algorithm ec-p256-sha256 \ --location CA_LOCATION \ --pool SUBORDINATE_CA_POOL_GATEWAYS \ --subject "CN=Example Gateway mTLS CA, O=Example Organization" \ --use-preset-profile subordinate_mtls_pathlen_0
- SUBORDINATE_CA_GATEWAYS adalah nama yang ingin Anda
gunakan untuk CA subordinat. Contoh,
subordinate-ca-mtls-gateways-tutorial
. - Flag
--use-preset-profile
mengonfigurasi CA subordinat untuk menggunakan profil sertifikat Subordinate mTLS. Profil ini memungkinkan CA bawahan menerbitkan sertifikat TLS klien dan server untuk mTLS.
Jika Anda ingin gateway masuk menggunakan TLS sederhana, bukan mTLS, CA subordinat Anda hanya perlu menerbitkan sertifikat TLS server. Dalam hal ini, Anda dapat menggunakan profil sertifikat TLS server Subordinate (
subordinate_server_tls_pathlen_0
) sebagai gantinya.- SUBORDINATE_CA_GATEWAYS adalah nama yang ingin Anda
gunakan untuk CA subordinat. Contoh,
Buat kebijakan penerbitan sertifikat:
cat << EOF > policy.yaml baselineValues: keyUsage: baseKeyUsage: digitalSignature: true keyEncipherment: true extendedKeyUsage: serverAuth: true clientAuth: true caOptions: isCa: false identityConstraints: allowSubjectPassthrough: false allowSubjectAltNamesPassthrough: true celExpression: expression: subject_alt_names.all(san, san.type == URI && san.value.startsWith("spiffe://PROJECT_ID.svc.id.goog/ns/") ) EOF
Kebijakan penerbitan ini membatasi CA untuk hanya menerbitkan sertifikat untuk workload dalam mesh.
Buat kumpulan CA yang akan digunakan untuk CA subordinat yang menerbitkan sertifikat ke proxy sidecar di mesh. Terapkan kebijakan penerbitan ke kumpulan CA:
gcloud privateca pools create SUBORDINATE_CA_POOL_SIDECARS \ --issuance-policy policy.yaml \ --location CA_LOCATION \ --tier devops
- SUBORDINATE_CA_POOL_SIDECARS adalah nama kumpulan CA. Contoh,
subordinate-ca-mtls-pool-sidecars-tutorial
.
- SUBORDINATE_CA_POOL_SIDECARS adalah nama kumpulan CA. Contoh,
Buat dan aktifkan CA subordinat yang menerbitkan sertifikat ke proxy sidecar dalam mesh:
gcloud privateca subordinates create SUBORDINATE_CA_SIDECARS \ --auto-enable \ --issuer-location CA_LOCATION \ --issuer-pool ROOT_CA_POOL \ --key-algorithm ec-p256-sha256 \ --location CA_LOCATION \ --pool SUBORDINATE_CA_POOL_SIDECARS \ --subject "CN=Example Sidecar mTLS CA, O=Example Organization" \ --use-preset-profile subordinate_mtls_pathlen_0
- SUBORDINATE_CA_GATEWAYS adalah nama yang ingin Anda
gunakan untuk CA subordinat. Contoh,
subordinate-ca-mtls-sidecars-tutorial
.
- SUBORDINATE_CA_GATEWAYS adalah nama yang ingin Anda
gunakan untuk CA subordinat. Contoh,
Membuat cluster Google Kubernetes Engine
Di Cloud Shell, buat cluster GKE:
gcloud container clusters create CLUSTER_NAME \ --enable-ip-alias \ --num-nodes 4 \ --release-channel regular \ --scopes cloud-platform \ --workload-pool PROJECT_ID.svc.id.goog \ --zone ZONE
Ganti CLUSTER_NAME dengan nama yang ingin Anda gunakan untuk cluster. Contoh,
asm-ingress-cert-manager-ca-service
.Ganti ZONE dengan zona yang ingin Anda gunakan untuk cluster. Contoh,
us-central1-f
.Perhatikan hal-hal berikut tentang perintah ini:
- Flag
--release-channel
memilih saluran rilis GKE untuk cluster. - Cloud Service Mesh dan penerbit Layanan CA untuk
alat cert-manager mengharuskan Anda menetapkan cakupan
cloud-platform
di node cluster. - Argumen
--workload-pool
memungkinkan Workload Identity Federation untuk GKE, yang memungkinkan akun layanan Kubernetes penerbit Layanan CA untuk meniru identitas akun layanan Google. Peniruan identitas ini berarti bahwa pod penerbit Layanan CA dapat mengakses CA Service API tanpa mendownload file kunci untuk akun layanan Google.
- Flag
Berikan izin administrator cluster ke akun pengguna Anda:
kubectl create clusterrolebinding cluster-admin-binding \ --clusterrole cluster-admin \ --user $(gcloud config get-value core/account)
Anda memerlukan izin yang disediakan oleh ClusterRole
cluster-admin
Kubernetes untuk membuat aturan kontrol akses berbasis peran (RBAC) untuk Cloud Service Mesh, dan untuk menginstal alat cert-manager.
Menginstal bidang kontrol Anthos Service Mesh
Dalam tutorial ini, Anda akan menginstal Cloud Service Mesh terkelola untuk cluster GKE di Google Cloud, dengan semua resource dalam satu project. Di lingkungan Anda sendiri, Anda dapat menerapkan solusi yang dijelaskan dalam dokumen ini menggunakan Cloud Service Mesh terkelola atau bidang kontrol dalam cluster.
Cloud Service Mesh menyediakan berbagai opsi penginstalan untuk berbagai skenario. Setelah menyelesaikan tutorial ini, sebaiknya tinjau panduan penginstalan untuk memilih opsi yang paling sesuai dengan lingkungan Anda.
Di Cloud Shell, download alat penginstalan
asmcli
:curl --location --output asmcli https://storage.googleapis.com/csm-artifacts/asm/asmcli_1.19 chmod +x asmcli
Anda menggunakan
asmcli
untuk menginstal bidang kontrol Cloud Service Mesh.Instal bidang kontrol Cloud Service Mesh:
./asmcli install \ --ca gcp_cas \ --ca_pool projects/PROJECT_ID/locations/CA_LOCATION/caPools/SUBORDINATE_CA_POOL_SIDECARS \ --cluster_location ZONE \ --cluster_name CLUSTER_NAME \ --enable_all \ --enable_registration \ --fleet_id PROJECT_ID \ --managed \ --output_dir asm-files \ --project_id PROJECT_ID \ --verbose
Flag
--ca gcp_cas
dan--ca_pool
mengonfigurasi bidang kontrol Cloud Service Mesh untuk menggunakan kumpulan CA sidecar di CA Service untuk menerbitkan sertifikat ke proxy sidecar di mesh.Flag
--enable_registration
mendaftarkan cluster GKE ke fleet dalam project yang ditentukan oleh flag--fleet_id
. Dalam tutorial ini, cluster GKE dan fleet menggunakan project yang sama.Flag
--managed
menyiapkan bidang kontrol Cloud Service Mesh terkelola.Flag
--output_dir
menentukan direktori yang digunakanasmcli
untuk mendownload file dan konfigurasi yang diperlukan untuk menginstal Cloud Service Mesh. Anda akan menggunakan file ini nanti dalam tutorial.
Penginstalan memerlukan waktu beberapa menit. Setelah penginstalan selesai, Anda akan melihat output berikut:
asmcli: Successfully installed ASM.
Menginstal gateway traffic masuk
Di Cloud Shell, buat namespace Kubernetes untuk gateway ingress:
kubectl create namespace GATEWAY_NAMESPACE
- GATEWAY_NAMESPACE adalah nama
namespace yang ingin Anda gunakan untuk gateway masuk. Contoh,
istio-ingress
.
- GATEWAY_NAMESPACE adalah nama
namespace yang ingin Anda gunakan untuk gateway masuk. Contoh,
Cadangkan alamat IP internal statis untuk digunakan pada Load Balancer Jaringan passthrough internal gateway masuk:
LOAD_BALANCER_IP=$(gcloud compute addresses create \ asm-ingress-gateway-ilb \ --region REGION \ --subnet default \ --format 'value(address)')
- Ganti REGION dengan region yang berisi zona atau zona yang digunakan node cluster GKE Anda. Misalnya,
jika cluster Anda menggunakan zona
us-central1-f
, ganti REGION denganus-central1
.
Perintah ini mencadangkan alamat IP dari subnet default di region yang Anda tentukan.
- Ganti REGION dengan region yang berisi zona atau zona yang digunakan node cluster GKE Anda. Misalnya,
jika cluster Anda menggunakan zona
Buat manifes operator untuk gateway masuk:
cat << EOF > ingressgateway-operator.yaml apiVersion: install.istio.io/v1alpha1 kind: IstioOperator metadata: name: ingressgateway-operator annotations: config.kubernetes.io/local-config: "true" spec: profile: empty revision: asm-managed components: ingressGateways: - name: istio-ingressgateway namespace: GATEWAY_NAMESPACE enabled: true k8s: overlays: - apiVersion: apps/v1 kind: Deployment name: istio-ingressgateway patches: - path: spec.template.metadata.annotations value: inject.istio.io/templates: gateway - path: spec.template.metadata.labels.sidecar\.istio\.io/inject value: "true" - path: spec.template.spec.containers[name:istio-proxy] value: name: istio-proxy image: auto service: loadBalancerIP: $LOAD_BALANCER_IP serviceAnnotations: networking.gke.io/load-balancer-type: Internal networking.gke.io/internal-load-balancer-allow-global-access: "true" EOF
Perhatikan hal-hal berikut tentang manifes operator:
Kolom
revision
menentukan saluran rilis Cloud Service Mesh terkelola yang akan digunakan untuk bidang data. Ubah nilai kolom ini jika Anda menggunakan saluran rilis Cepat atau Stabil untuk platform kontrol.annotation
,label
, danimage
yang ditentukan di bagianoverlays
memungkinkan injeksi otomatis konfigurasi proxy untuk deployment gateway traffic masuk.Kolom
loadBalancerIP
menentukan alamat IP yang akan digunakan untuk load balancer. Jika Anda menghapus kolom ini dari manifes, load balancer akan menggunakan alamat IP sementara.Anotasi layanan
networking.gke.io/load-balancer-type: Internal
di gateway masuk berarti GKE menyediakan Load Balancer Jaringan passthrough internal di depan pod gateway masuk. Jika Anda menghapus anotasi ini, GKE akan menyediakan Load Balancer Jaringan passthrough eksternal.Anotasi layanan opsional
networking.gke.io/internal-load-balancer-allow-global-access: "true"
memungkinkan klien dari region mana pun di VPC Anda mengakses Load Balancer Jaringan passthrough internal. Jika Anda menghapus anotasi ini, Load Balancer Jaringan passthrough internal hanya akan menerima traffic dari klien di region yang sama di VPC Anda.
Buat manifes penginstalan gateway ingress menggunakan manifes operator dan alat
istioctl
yang didownload skripasmcli
saat Anda menginstal bidang kontrol:./asm-files/istioctl manifest generate \ --filename ingressgateway-operator.yaml \ --output ingressgateway
Instal gateway traffic masuk:
kubectl apply --recursive --filename ingressgateway/
Menginstal alat cert-manager
Di Cloud Shell, download dan terapkan manifes penginstalan alat cert-manager:
CERT_MANAGER_VERSION=v1.5.4 curl --location --output cert-manager.yaml "https://github.com/jetstack/cert-manager/releases/download/${CERT_MANAGER_VERSION}/cert-manager.yaml" kubectl apply --filename cert-manager.yaml
Menginstal alat cert-manager memerlukan waktu sekitar satu menit.
Menginstal pengontrol penerbit Layanan CA
Pengontrol penerbit Layanan CA memungkinkan alat pengelola sertifikat meminta sertifikat menggunakan Layanan CA. Pengontrol menggunakan mekanisme ekstensi penerbit eksternal alat cert-manager.
Di Cloud Shell, buat akun layanan Google:
gcloud iam service-accounts create CAS_ISSUER_GSA \ --display-name "CA Service issuer for cert-manager"
- CAS_ISSUER_GSA adalah nama akun layanan Google. Contoh,
cert-manager-ca-service-issuer
.
Pengontrol penerbit Certificate Authority Service menggunakan akun layanan Google ini untuk mengautentikasi ke Certificate Authority Service API.
- CAS_ISSUER_GSA adalah nama akun layanan Google. Contoh,
Buat binding kebijakan Identity and Access Management yang memungkinkan akun layanan Google pengontrol penerbit Certificate Authority Service meminta sertifikat dari kumpulan CA yang berisi CA subordinasi Anda:
gcloud privateca pools add-iam-policy-binding SUBORDINATE_CA_POOL_GATEWAYS \ --location CA_LOCATION \ --member "serviceAccount:CAS_ISSUER_GSA@PROJECT_ID.iam.gserviceaccount.com" \ --role roles/privateca.certificateRequester
Download manifes penginstalan pengontrol penerbit Certificate Authority Service:
CAS_ISSUER_VERSION=v0.5.3 curl --location --output ca-service-issuer.yaml "https://github.com/jetstack/google-cas-issuer/releases/download/${CAS_ISSUER_VERSION}/google-cas-issuer-${CAS_ISSUER_VERSION}.yaml"
Buat binding kebijakan IAM agar
ksa-google-cas-issuer
akun layanan Kubernetes di namespacecert-manager
dapat meniru identitas akun layanan Google (GSA) menggunakan Workload Identity Federation untuk GKE:gcloud iam service-accounts add-iam-policy-binding \ CAS_ISSUER_GSA@PROJECT_ID.iam.gserviceaccount.com \ --member "serviceAccount:PROJECT_ID.svc.id.goog[cert-manager/ksa-google-cas-issuer]" \ --role roles/iam.workloadIdentityUser
Pod pengontrol penerbit Layanan CA menggunakan akun layanan Kubernetes
ksa-google-cas-issuer
.Instal pengontrol penerbit Layanan CA di cluster GKE Anda:
kubectl apply --filename ca-service-issuer.yaml
Tambahkan Workload Identity Federation untuk anotasi GKE
iam.gke.io/gcp-service-account
ke akun layanan Kubernetes yang digunakan oleh pod pengontrol penerbit Layanan CA:kubectl annotate serviceaccount ksa-google-cas-issuer --namespace cert-manager \ "iam.gke.io/gcp-service-account=CAS_ISSUER_GSA@PROJECT_ID.iam.gserviceaccount.com"
Anotasi ini memberi tahu GKE bahwa akun layanan Kubernetes dapat meniru identitas akun layanan Google untuk mengakses API Google.
Membuat penerbit sertifikat
Di Cloud Shell, buat dan terapkan manifes GoogleCASIssuer:
cat << EOF > gateway-cas-issuer.yaml apiVersion: cas-issuer.jetstack.io/v1beta1 kind: GoogleCASIssuer metadata: name: gateway-cas-issuer namespace: GATEWAY_NAMESPACE spec: caPoolId: SUBORDINATE_CA_POOL_GATEWAYS location: CA_LOCATION project: PROJECT_ID EOF kubectl apply --filename gateway-cas-issuer.yaml
Penerbit memungkinkan alat cert-manager menyediakan sertifikat dari kumpulan CA subordinat di namespace gateway masuk
Menerapkan aplikasi sampel
Di bagian ini, Anda akan memverifikasi bahwa alat cert-manager dapat menggunakan penerbit Layanan CA untuk mendapatkan sertifikat dari Layanan CA. Untuk memverifikasi, Anda men-deploy aplikasi contoh dengan konfigurasi pemilihan rute permintaan dan sertifikat untuk gateway masuk.
Di Cloud Shell, buat namespace untuk resource aplikasi contoh:
cat << EOF > sample-app-namespace.yaml apiVersion: v1 kind: Namespace metadata: name: APP_NAMESPACE annotations: mesh.cloud.google.com/proxy: '{"managed":"true"}' labels: istio.io/rev: asm-managed EOF kubectl apply --filename sample-app-namespace.yaml
- APP_NAMESPACE adalah nama namespace untuk
aplikasi contoh. Contoh,
sample-app
.
Anotasi
mesh.cloud.google.com/proxy
mengaktifkan bidang data terkelola untuk namespace.Label
istio.io/rev: asm-managed
memilih Saluran rilis reguler untuk platform data terkelola di namespace aplikasi contoh. Ubah nilai label ini jika Anda menggunakan saluran rilis Cepat atau Stabil.- APP_NAMESPACE adalah nama namespace untuk
aplikasi contoh. Contoh,
Buat resource Deployment untuk aplikasi contoh:
cat << EOF > deployment.yaml apiVersion: apps/v1 kind: Deployment metadata: name: hello namespace: APP_NAMESPACE labels: app: hello spec: replicas: 1 selector: matchLabels: app: hello template: metadata: labels: app: hello spec: containers: - image: gcr.io/google-samples/hello-app:1.0 name: hello-app ports: - containerPort: 8080 EOF kubectl apply --filename deployment.yaml
Buat resource Service untuk aplikasi contoh:
cat << EOF > service.yaml apiVersion: v1 kind: Service metadata: name: SERVICE_NAME namespace: APP_NAMESPACE spec: ports: - name: http-hello port: 8080 selector: app: hello type: ClusterIP EOF kubectl apply --filename service.yaml
- SERVICE_NAME adalah nama layanan. Contoh,
hello
.
- SERVICE_NAME adalah nama layanan. Contoh,
Buat resource Sertifikat untuk nama domain
hello.example.com
menggunakan penerbit sertifikat:cat << EOF > certificate.yaml apiVersion: cert-manager.io/v1 kind: Certificate metadata: name: hello-example-com-certificate namespace: GATEWAY_NAMESPACE spec: secretName: hello-example-com-credential commonName: hello.example.com dnsNames: - hello.example.com duration: 24h renewBefore: 8h issuerRef: group: cas-issuer.jetstack.io kind: GoogleCASIssuer name: gateway-cas-issuer EOF kubectl apply --filename certificate.yaml
Namespace Sertifikat harus cocok dengan namespace gateway ingress. Biasanya, hanya administrator platform yang dapat mengubah resource di namespace ini, karena perubahan dapat memengaruhi seluruh mesh layanan. Alat cert-manager membuat resource Secret untuk sertifikat TLS di namespace yang sama. Artinya, administrator aplikasi tidak perlu memiliki akses ke namespace gateway masuk.
Anda dapat menambahkan nama host tambahan dalam daftar
dnsNames
di Sertifikat. Nama host ini disertakan dalam sertifikat sebagai Nama Alternatif Subjek (SAN).Buat resource Gateway untuk aplikasi contoh:
cat << EOF > gateway.yaml apiVersion: networking.istio.io/v1beta1 kind: Gateway metadata: name: GATEWAY_NAME namespace: GATEWAY_NAMESPACE spec: selector: istio: ingressgateway servers: - hosts: - APP_NAMESPACE/hello.example.com port: name: https-hello number: 443 protocol: HTTPS tls: credentialName: hello-example-com-credential mode: MUTUAL EOF kubectl apply --filename gateway.yaml
- GATEWAY_NAME adalah nama gateway. Contoh,
hello
. - Kolom
credentialName
di Gateway cocok dengan kolomsecretName
di Sertifikat. Alat cert-manager membuat Kubernetes Secret dengan sertifikat TLS dari Layanan CA. Sertifikat ini memungkinkan gateway masuk untuk menghentikan traffic TLS yang dituju kehello.example.com
.
Manifes Gateway menentukan TLS MUTUAL (mTLS). Jika Anda ingin mengonfigurasi gateway untuk TLS reguler, tetapkan mode TLS Gateway ke
SIMPLE
.- GATEWAY_NAME adalah nama gateway. Contoh,
Buat resource VirtualService untuk aplikasi contoh:
cat << EOF > virtual-service.yaml apiVersion: networking.istio.io/v1beta1 kind: VirtualService metadata: name: hello namespace: APP_NAMESPACE spec: hosts: - hello.example.com gateways: - GATEWAY_NAMESPACE/GATEWAY_NAME http: - route: - destination: host: SERVICE_NAME port: number: 8080 EOF kubectl apply --filename virtual-service.yaml
Gateway dan VirtualService menggunakan namespace yang berbeda. Pola umum ini membatasi perubahan pada perutean berbasis host di Gateway untuk administrator platform yang memiliki izin untuk mengubah resource di namespace gateway masuk.
Administrator aplikasi yang memiliki izin untuk mengedit VirtualService di namespace aplikasi contoh dapat mengubah pemilihan rute berdasarkan kolom permintaan lain, seperti jalur URL, tanpa berkoordinasi dengan administrator platform.
Jika Anda ingin mempelajari opsi konfigurasi lainnya, baca dokumentasi API untuk resource Certificate, Gateway, dan VirtualService.
Anda dapat menerapkan kebijakan autentikasi dan otorisasi ke traffic yang memasuki mesh layanan melalui gateway masuk. Untuk melakukannya, baca dokumentasi untuk API PeerAuthentication dan AuthorizationPolicy Istio.
Memverifikasi solusi
Di bagian ini, Anda akan memverifikasi bahwa Anda dapat mengirim permintaan HTTPS menggunakan mTLS ke aplikasi contoh dari luar mesh layanan. Untuk memverifikasi, Anda membuat instance VM Compute Engine, meminta sertifikat TLS klien dari Layanan CA, dan menggunakan sertifikat ini untuk mengautentikasi permintaan ke aplikasi contoh.
Anda memerlukan akses SSH ke instance VM. Jaringan default menyertakan aturan firewall yang mengizinkan akses SSH. Jika Anda tidak memiliki akses SSH, ikuti dokumentasi aturan firewall untuk membuat aturan firewall yang mengizinkan koneksi TCP masuk di port 22.
Di Cloud Shell, buat akun layanan Google:
gcloud iam service-accounts create CLIENT_VM_GSA \ --display-name "CA Service tutorial VM instance service account"
- CLIENT_VM_GSA adalah nama akun layanan Google. Contoh,
cas-tutorial-client
.
Anda menetapkan akun layanan Google ini ke instance VM Compute Engine.
- CLIENT_VM_GSA adalah nama akun layanan Google. Contoh,
Berikan peran CA Service Certificate Requester di kumpulan CA subordinasi gateway ke akun layanan Google:
gcloud privateca pools add-iam-policy-binding SUBORDINATE_CA_POOL_GATEWAYS \ --location CA_LOCATION \ --member "serviceAccount:CLIENT_VM_GSA@PROJECT_ID.iam.gserviceaccount.com" \ --role roles/privateca.certificateRequester
Peran ini memberikan izin untuk meminta sertifikat dari kumpulan CA.
Buat instance VM Compute Engine di VPC yang sama dengan cluster GKE:
gcloud compute instances create cas-tutorial-client \ --scopes cloud-platform \ --service-account CLIENT_VM_GSA@PROJECT_ID.iam.gserviceaccount.com \ --zone ZONE
Instance VM memerlukan cakupan
cloud-platform
untuk mengakses CA Service API.Simpan alamat IP Load Balancer Jaringan passthrough internal gateway masuk ke file:
kubectl get services istio-ingressgateway \ --namespace GATEWAY_NAMESPACE \ --output jsonpath='{.status.loadBalancer.ingress[0].ip}' > ilb-ip.txt
Simpan sertifikat kunci publik root CA Anda ke file:
gcloud privateca roots describe ROOT_CA \ --location CA_LOCATION \ --pool ROOT_CA_POOL \ --format 'value(pemCaCertificates)' > root-ca-cert.pem
Salin sertifikat root CA dan file yang berisi alamat IP Load Balancer Jaringan passthrough internal gateway masuk ke instance VM:
gcloud compute scp root-ca-cert.pem ilb-ip.txt cas-tutorial-client:~ \ --zone ZONE
Hubungkan ke instance VM menggunakan SSH:
gcloud compute ssh cas-tutorial-client --zone ZONE
Jalankan perintah lainnya di bagian ini dari sesi SSH.
Instal paket
ca-certificates
dancoreutils
, serta alat command linecurl
,openssl
, danjq
:sudo apt-get update --yes sudo apt-get install --yes ca-certificates coreutils curl jq openssl
Buat pasangan kunci untuk sertifikat TLS klien:
openssl genrsa -out private-key.pem 2048 openssl rsa -in private-key.pem -pubout -out public-key.pem
Buat kueri server metadata untuk mendapatkan alamat email identitas akun layanan Google yang terpasang ke instance VM:
GSA_EMAIL=$(curl --silent --header "Metadata-Flavor: Google" http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/email)
Buat file JSON yang Anda gunakan sebagai isi permintaan saat meminta sertifikat TLS klien dari Certificate Authority Service API:
cat << EOF > request.json { "config": { "publicKey": { "format": "PEM", "key": "$(base64 --wrap 0 public-key.pem)" }, "subjectConfig": { "subject": { "commonName": "$(hostname --short)", "organization": "Example Organization" }, "subjectAltName": { "dnsNames": [ "$(hostname --fqdn)" ], "emailAddresses": [ "$GSA_EMAIL" ] } }, "x509Config": { "caOptions": { "isCa": false }, "keyUsage": { "baseKeyUsage": { "digitalSignature": true, "keyEncipherment": true }, "extendedKeyUsage": { "clientAuth": true } } } }, "lifetime": "86400s" } EOF
Untuk mempelajari lebih lanjut kolom di bagian konfigurasi, lihat jenis
CertificateConfig
dalam dokumentasi CA Service API.Minta token akses OAuth 2.0 dari server metadata:
TOKEN=$(curl --silent --header "Metadata-Flavor: Google" http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token | jq --raw-output ".access_token")
Token akses ini memberikan izin yang diberikan ke akun layanan Google yang dilampirkan ke instance VM.
Minta sertifikat TLS klien dari CA Service API dan simpan isi respons dalam file:
curl --silent --request POST \ --header "Authorization: Bearer $TOKEN" \ --header "Content-Type: application/json" \ --data @request.json \ --output response.json \ "https://privateca.googleapis.com/v1/projects/PROJECT_ID/locations/CA_LOCATION/caPools/SUBORDINATE_CA_POOL_GATEWAYS/certificates"
Perintah ini menggunakan token akses untuk mengautentikasi permintaan API.
Simpan sertifikat klien dan rantai sertifikat ke file:
jq --raw-output --join-output ".pemCertificate , .pemCertificateChain[]" response.json > client-cert-chain.pem
Gunakan
curl
untuk mengirim permintaan HTTPS dari instance VM ke aplikasi contoh:curl --cert client-cert-chain.pem --key private-key.pem \ --cacert root-ca-cert.pem \ --resolve hello.example.com:443:$(cat ilb-ip.txt) \ --silent https://hello.example.com | head -n1
Outputnya akan terlihat seperti ini:
Hello, world!
Respons ini menunjukkan bahwa
curl
berhasil mengirim permintaan HTTPS menggunakan mTLS. Aplikasi contoh merespons dengan pesan yang Anda lihat di output terminal.Perintah
curl
tersebut melakukan hal berikut:Flag
--cert
dan--key
menginstruksikancurl
untuk menggunakan sertifikat TLS klien dan kunci pribadi untuk mengautentikasi permintaan. File sertifikat klien berisi rantai sertifikat lengkap, dari sertifikat klien ke root CA.Flag
--cacert
menginstruksikancurl
untuk memverifikasi bahwa root CA yang Anda buat dalam tutorial ini, atau salah satu CA bawahannya, telah menerbitkan sertifikat server.Jika Anda menghapus tanda ini,
curl
akan mencoba memverifikasi sertifikat server menggunakan paket CA default sistem operasi Anda, seperti paketca-certificates
di Debian. Verifikasi gagal karena paket CA default tidak menyertakan root CA yang Anda buat dalam tutorial ini.Flag
--resolve
menginstruksikancurl
untuk menggunakan alamat IP Load Balancer Jaringan passthrough internal sebagai tujuan untuk permintaan guna menghostinghello.example.com
di port 443.Jika Anda menghilangkan tanda ini,
curl
akan mencoba menggunakan DNS untuk me-resolve nama hosthello.example.com
. Resolusi DNS gagal karena tidak ada entri DNS untuk nama host ini.Di lingkungan Anda sendiri, sebaiknya buat data A DNS yang mengarah ke alamat IP Network Load Balancer passthrough internal (
$LOAD_BALANCER_IP
). Buat data ini menggunakan Cloud DNS, dengan mengikuti dokumentasi tentang mengelola data.Flag
--silent
akan menyembunyikan pelaporan progres download respons di output terminal.Perintah ini menyalurkan output curl ke
head -n1
. Hasilnya adalah output di terminal hanya menyertakan baris pertama isi respons.
Keluar dari sesi SSH:
exit
Di bagian ini, Anda meminta sertifikat TLS klien langsung dari CA Service API. Jika klien adalah gateway eksekusi dari mesh layanan lain di cluster Kubernetes terpisah, Anda dapat menggunakan alat pengelola sertifikat dan penerbit Certificate Authority Service dengan root CA yang sama untuk memberikan sertifikat klien ke gateway eksekusi.
Dalam situasi lain, Anda dapat menggunakan alat seperti Hashicorp Vault, Terraform, atau
gcloud
untuk meminta sertifikat TLS klien untuk beban kerja di luar mesh
layanan. Untuk mengetahui informasi selengkapnya, lihat dokumentasi Layanan CA untuk
contoh solusi, dan
dokumentasi gcloud
untuk Layanan CA.
(Opsional) Menambahkan sertifikat CA ke penyimpanan tepercaya
Bagian opsional ini menunjukkan cara menambahkan sertifikat CA ke penyimpanan sertifikat CA tepercaya untuk distribusi Debian Linux. Petunjuk ini juga berlaku untuk distribusi yang berasal dari Debian, seperti Ubuntu.
Menambahkan sertifikat CA ke penyimpanan ini berarti Anda tidak perlu menentukan
lokasi sertifikat CA tepercaya saat mengirim permintaan HTTPS menggunakan curl
,
Python, Go, dan Ruby.
Hubungkan ke instance VM menggunakan SSH:
gcloud compute ssh cas-tutorial-client --zone ZONE
Jalankan perintah lainnya di bagian ini dari sesi SSH.
Salin sertifikat root CA ke direktori
/usr/local/share/ca-certificates
, dan pastikan file memiliki ekstensi.crt
:sudo cp root-ca-cert.pem /usr/local/share/ca-certificates/cas-rootca.crt
Tetapkan izin file agar semua pengguna dapat membaca file sertifikat root CA:
sudo chmod 644 /usr/local/share/ca-certificates/cas-rootca.crt
Jalankan skrip
update-ca-certificates
:sudo update-ca-certificates
Skrip ini menambahkan sertifikat ke kumpulan sertifikat tepercaya di direktori
/etc/ssl/certs
, dan ke file/etc/ssl/certs/ca-certificates.crt
.Outputnya adalah sebagai berikut:
Updating certificates in /etc/ssl/certs... 1 added, 0 removed; done. Running hooks in /etc/ca-certificates/update.d... done.
Gunakan
curl
untuk mengirim permintaan HTTPS dari instance VM ke aplikasi contoh:curl --cert client-cert-chain.pem --key private-key.pem \ --resolve hello.example.com:443:$(cat ilb-ip.txt) \ --silent https://hello.example.com | head -n1
Outputnya akan terlihat seperti ini:
Hello, world!
Respons ini menunjukkan bahwa
curl
berhasil mengirim permintaan HTTPS menggunakan mTLS, dan memvalidasi sertifikat TLS server dari gateway masuk menggunakan penyimpanan sertifikat CA default.Keluar dari sesi SSH:
exit
Memecahkan masalah
Jika pengontrol penerbit Layanan CA tidak membuat secret sertifikat TLS, lihat log pengontrol penerbit Layanan CA:
kubectl logs deployment/google-cas-issuer --namespace cert-manager
Jika Anda mengalami masalah saat menginstal Cloud Service Mesh,
jalankan alat asmcli
untuk memvalidasi project Cloud dan cluster GKE Anda.
Jika Anda mengalami masalah lain dengan tutorial ini, sebaiknya tinjau dokumen berikut:
- Pertanyaan umum (FAQ) Layanan CA
- Pemecahan masalah Cloud Service Mesh langkah demi langkah
- Menyelesaikan masalah Cloud Service Mesh terkelola
- Masalah umum operasi Istio
- Pemecahan masalah GKE
- Memecahkan masalah cluster Kubernetes
Pembersihan
Agar tidak dikenai biaya berkelanjutan pada akun Google Cloud Anda untuk resource yang digunakan dalam tutorial ini, Anda dapat menghapus project atau menghapus setiap resource.
Menghapus project
Di Cloud Shell, hapus project:
gcloud projects delete PROJECT_ID
Menghapus resource
Jika ingin menyimpan project Google Cloud yang digunakan dalam tutorial ini, hapus setiap resource:
Di Cloud Shell, batalkan pendaftaran cluster GKE dari GKE Hub:
gcloud container hub memberships unregister CLUSTER_NAME \ --gke-cluster ZONE/CLUSTER_NAME
Hapus cluster GKE:
gcloud container clusters delete CLUSTER_NAME \ --zone ZONE --async --quiet
Hapus binding kebijakan IAM di kumpulan CA bawahan:
gcloud privateca pools remove-iam-policy-binding SUBORDINATE_CA_POOL_GATEWAYS \ --location CA_LOCATION \ --member "serviceAccount:CAS_ISSUER_GSA@PROJECT_ID.iam.gserviceaccount.com" \ --role roles/privateca.certificateRequester gcloud privateca pools remove-iam-policy-binding SUBORDINATE_CA_POOL_GATEWAYS \ --location CA_LOCATION \ --member "serviceAccount:CLIENT_VM_GSA@PROJECT_ID.iam.gserviceaccount.com" \ --role roles/privateca.certificateRequester
Nonaktifkan dan jadwalkan penghapusan CA subordinat dan CA root:
gcloud privateca subordinates disable SUBORDINATE_CA_GATEWAYS \ --location CA_LOCATION \ --pool SUBORDINATE_CA_POOL_GATEWAYS \ --quiet gcloud privateca subordinates delete SUBORDINATE_CA_GATEWAYS \ --location CA_LOCATION \ --pool SUBORDINATE_CA_POOL_GATEWAYS \ --ignore-active-certificates \ --quiet gcloud privateca subordinates disable SUBORDINATE_CA_SIDECARS \ --location CA_LOCATION \ --pool SUBORDINATE_CA_POOL_SIDECARS \ --quiet gcloud privateca subordinates delete SUBORDINATE_CA_SIDECARS \ --location CA_LOCATION \ --pool SUBORDINATE_CA_POOL_SIDECARS \ --ignore-active-certificates \ --quiet gcloud privateca roots disable ROOT_CA \ --location CA_LOCATION \ --pool ROOT_CA_POOL \ --quiet gcloud privateca roots delete ROOT_CA \ --location CA_LOCATION \ --pool ROOT_CA_POOL \ --ignore-active-certificates \ --quiet
Hapus binding kebijakan IAM untuk akun layanan Google pengontrol penerbit Layanan CA:
gcloud iam service-accounts remove-iam-policy-binding \ CAS_ISSUER_GSA@PROJECT_ID.iam.gserviceaccount.com \ --member "serviceAccount:PROJECT_ID.svc.id.goog[cert-manager/ksa-google-cas-issuer]" \ --role roles/iam.workloadIdentityUser
Hapus akun layanan Google:
gcloud iam service-accounts delete --quiet \ CAS_ISSUER_GSA@PROJECT_ID.iam.gserviceaccount.com gcloud iam service-accounts delete --quiet \ CLIENT_VM_GSA@PROJECT_ID.iam.gserviceaccount.com
Hapus alamat IP load balancer yang dicadangkan:
gcloud compute addresses delete asm-ingress-gateway-ilb \ --region REGION --quiet
Hapus instance VM Compute Engine:
gcloud compute instances delete cas-tutorial-client \ --zone ZONE --quiet
Langkah selanjutnya
- Pelajari panduan cara kerja Certificate Authority Service lainnya.
- Pelajari lebih lanjut Cloud Service Mesh, serangkaian alat berbasis Istio yang membantu Anda memantau dan mengelola mesh layanan yang andal di infrastruktur lokal dan di Google Cloud.
- Pelajari panduan cara kerja Cloud Service Mesh.