Mengotomatiskan pengelolaan sertifikat TLS untuk gateway ingress Anthos Service Mesh menggunakan Certificate Authority Service

Tutorial ini menunjukkan kepada operator platform cara menggunakan penerbit Certificate Authority Service (CA Service) untuk alat pengelola sertifikat guna mengotomatiskan pengelolaan sertifikat TLS untuk gateway ingress Anthos Service Mesh. Dengan sertifikat tersebut, gateway masuk dapat menghentikan HTTPS serta traffic TLS dan mTLS lainnya yang berasal dari klien di Virtual Private Cloud (VPC) Anda, tetapi di luar mesh layanan. Tutorial ini mengasumsikan bahwa Anda telah memiliki pengetahuan dasar tentang sertifikat Kubernetes dan TLS.

Pengantar

Anthos Service Mesh menyediakan sertifikat TLS ke setiap workload di mesh layanan. Sertifikat ini memungkinkan komunikasi TLS (mTLS) yang dienkripsi dan antar-beban kerja di mesh layanan. Salah satu masalah CA yang didukung dan menandatangani sertifikat.

Namun, Anthos Service Mesh tidak otomatis menyediakan sertifikat ke gateway masuk untuk traffic yang masuk ke mesh layanan. Solusi umumnya adalah menggunakan alat cert-manager open source untuk mengotomatiskan pengelolaan sertifikat gateway masuk.

Alat pengelola sertifikat meminta sertifikat dari penerbit, yang mewakili certificate authority (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 open source untuk Layanan CA.

CA pribadi dapat menerbitkan sertifikat TLS yang mengautentikasi dan mengenkripsi traffic di dalam jaringan internal. Gateway ingress Anthos Service Mesh sering kali disiapkan untuk memungkinkan traffic masuk dari klien yang ada di dalam VPC Anda, tetapi di luar mesh layanan. Untuk traffic jaringan internal, Anda dapat menggunakan CA pribadi di Layanan CA guna menerbitkan sertifikat untuk gateway masuk.

Tutorial ini menunjukkan cara menyiapkan fitur pengelola sertifikat dan penerbit Layanan CA untuk mengotomatiskan penyediaan dan perpanjangan sertifikat TLS untuk gateway masuk. Fitur pengelola sertifikat menyediakan sertifikat sebagai resource Kubernetes Secret jenis TLS. Saat memperpanjang sertifikat, alat pengelola sertifikat akan memperbarui resource Secret dengan sertifikat baru. Gateway masuk menjalankan Envoy Proxy, dan mendukung layanan penemuan rahasia Envoy (SDS). SDS memungkinkan gateway masuk untuk mulai menggunakan sertifikat baru tanpa memerlukan administrator untuk memulai ulang atau memuat ulang proses.

Proxy file bantuan yang merupakan bagian dari mesh dapat memperoleh sertifikat TLS dari CA Service atau certificate authority Anthos Service Mesh (Mesh CA). Dalam tutorial ini, Anda akan menggunakan CA Service untuk sertifikat gateway masuk dan proxy sidecar. Hal ini memungkinkan Anda menggunakan satu root CA untuk semua sertifikat TLS.

Diagram berikut menunjukkan referensi 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, sistem akan mengarahkan 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 handshake TLS untuk permintaan dengan nama host hello.example.com.

pengelolaan mtls dengan layanan ca

Pod deployment google-cas-issuer di namespace cert-manager meminta sertifikat dari CA yang Anda buat di Layanan CA. Anda membuat binding kebijakan Identity and Access Management yang memungkinkan pod ca-service-isser untuk meniru identitas akun layanan Google menggunakan Workload Identity. Anda memberikan izin kepada akun layanan Google ini untuk meminta sertifikat dari CA Anda di CA Service dengan membuat binding kebijakan IAM pada kumpulan CA Anda.

Tujuan

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

  1. Di konsol Google Cloud, buka halaman project selector, lalu pilih atau buat project.

  2. Pastikan penagihan diaktifkan untuk project Google Cloud Anda.

  3. Di konsol Google Cloud, buka Cloud Shell.

    Di bagian bawah Konsol Google Cloud, sesi Cloud Shell akan terbuka dan menampilkan perintah command line. Anda dapat menggunakan Cloud Shell untuk menjalankan semua perintah dalam tutorial ini.

  4. 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.

    Pada dialog Otorisasi Cloud Shell, klik Authorize. Dengan mengklik Authorize, Anda mengizinkan perintah gcloud yang dijalankan di Cloud Shell untuk menggunakan kredensial pengguna Anda untuk melakukan autentikasi ke Google API.

  5. Aktifkan Resource Manager, GKE, GKE Hub, certificate authority Anthos Service Mesh, dan CA Service API:

    gcloud services enable \
        cloudresourcemanager.googleapis.com \
        container.googleapis.com \
        gkehub.googleapis.com \
        meshca.googleapis.com \
        privateca.googleapis.com
    

Konfigurasi Layanan CA

Di bagian ini, Anda akan membuat CA root dan dua CA subordinat di Layanan CA. Satu CA subordinat menerbitkan sertifikat ke gateway masuk, dan CA subordinat lainnya menerbitkan sertifikat ke proxy file bantuan di mesh.

Untuk mempermudah, gunakan project yang sama untuk cluster GKE serta CA root dan subordinate dalam tutorial ini. Di lingkungan Anda sendiri, Anda dapat menggunakan project yang berbeda untuk cluster GKE dan CA.

  1. 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. Misalnya, root-ca-pool-tutorial.
    • CA_LOCATION adalah lokasi kumpulan CA. Misalnya, us-central1.

    Anda dapat menampilkan daftar lokasi Layanan CA yang tersedia menggunakan perintah ini: gcloud privateca locations list

  2. 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.
  3. Buat kumpulan CA untuk digunakan bagi CA bawahan 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.
  4. Buat dan aktifkan CA subordinat yang menerbitkan sertifikat ke gateway masuk:

    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. Misalnya, subordinate-ca-mtls-gateways-tutorial.
    • Tanda --use-preset-profile mengonfigurasi CA subordinat untuk menggunakan profil sertifikat Subordinate mTLS. Profil ini memungkinkan CA subordinat menerbitkan sertifikat TLS klien dan server untuk mTLS.

    Jika Anda ingin gateway ingress Anda menggunakan TLS sederhana, bukan mTLS, CA subordinat Anda hanya perlu menerbitkan sertifikat TLS server. Dalam hal ini, Anda dapat menggunakan profil sertifikat TLS server subordinat (subordinate_server_tls_pathlen_0).

  5. 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 agar hanya menerbitkan sertifikat untuk workload di mesh.

  6. Buat kumpulan CA untuk digunakan bagi CA bawahan yang menerbitkan sertifikat ke proxy file bantuan 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.
  7. Buat dan aktifkan CA subordinat yang menerbitkan sertifikat ke proxy bantuan di 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. Misalnya, subordinate-ca-mtls-sidecars-tutorial.

Membuat cluster Google Kubernetes Engine

  1. 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:

    • Flag --release-channel memilih saluran rilis GKE untuk cluster tersebut.
    • Baik Anthos Service Mesh maupun penerbit CA Service untuk alat pengelola sertifikat mengharuskan Anda menetapkan cakupan cloud-platform di node cluster.
    • Argumen --workload-pool memungkinkan Workload Identity, yang memungkinkan akun layanan Kubernetes penerbit Layanan CA untuk meniru 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.
  2. 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 guna membuat aturan kontrol akses berbasis peran (RBAC) untuk Anthos Service Mesh, dan menginstal alat pengelola sertifikat.

Instal bidang kontrol Anthos Service Mesh

Dalam tutorial ini, Anda akan menginstal Anthos Service Mesh yang 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 Anthos Service Mesh terkelola atau bidang kontrol dalam cluster.

Anthos 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.

  1. Di Cloud Shell, download alat penginstalan asmcli:

    curl --location --output asmcli https://storage.googleapis.com/csm-artifacts/asm/asmcli_1.20
    
    chmod +x asmcli
    

    Anda menggunakan asmcli untuk menginstal bidang kontrol Anthos Service Mesh.

  2. Instal bidang kontrol Anthos 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
    
    .

    Penginstalan memerlukan waktu beberapa menit. Setelah penginstalan selesai, Anda akan melihat output berikut:

    asmcli: Successfully installed ASM.
    

Menginstal gateway masuk (ingress gateway)

  1. Di Cloud Shell, buat namespace Kubernetes untuk ingress gateway:

    kubectl create namespace GATEWAY_NAMESPACE
    
    • GATEWAY_NAMESPACE adalah nama namespace yang ingin Anda gunakan untuk gateway masuk. Misalnya, istio-ingress.
  2. Cadangkan alamat IP internal statis yang akan digunakan untuk Load Balancer Jaringan passthrough jaringan 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 dengan us-central1.

    Perintah ini mencadangkan alamat IP dari subnet default di region yang Anda tentukan.

  3. Buat manifes operator untuk gateway masuknya:

    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:

  4. Buat manifes penginstalan gateway masuk menggunakan manifes operator dan alat istioctl yang didownload oleh skrip asmcli saat Anda menginstal bidang kontrol:

    ./asm-files/istioctl manifest generate \
        --filename ingressgateway-operator.yaml \
        --output ingressgateway
    
  5. Instal gateway masuk:

    kubectl apply --recursive --filename ingressgateway/
    

Menginstal alat pengelola sertifikat

  1. Di Cloud Shell, download dan terapkan manifes penginstalan alat pengelola sertifikat:

    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 pengelola sertifikat memerlukan waktu sekitar satu menit.

Menginstal pengontrol penerbit CA Service

Pengontrol penerbit Layanan CA memungkinkan alat pengelola sertifikat untuk meminta sertifikat menggunakan Layanan CA. Pengontrol menggunakan mekanisme ekstensi penerbit eksternal alat pengelola sertifikat.

  1. 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 melakukan autentikasi ke Certificate Authority Service API.

  2. Buat binding kebijakan Identity and Access Management yang memungkinkan akun layanan Google pengontrol layanan Certificate Authority Service untuk meminta sertifikat dari kumpulan CA yang berisi CA subordinat 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
    
  3. 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"
    
  4. Buat binding kebijakan IAM agar akun layanan Kubernetes ksa-google-cas-issuer di namespace cert-manager dapat meniru identitas akun layanan Google (GSA) menggunakan Workload Identity:

    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 CA Service menggunakan akun layanan Kubernetes ksa-google-cas-issuer.

  5. Instal pengontrol penerbit CA Service di cluster GKE Anda:

    kubectl apply --filename ca-service-issuer.yaml
    
  6. Tambahkan anotasi Workload Identity iam.gke.io/gcp-service-account ke akun layanan Kubernetes yang digunakan oleh pod pengontrol penerbit CA Service:

    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 akun layanan Google untuk mengakses Google API.

Membuat penerbit sertifikat

  1. 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 pengelola sertifikat untuk menyediakan sertifikat dari kumpulan CA bawahan Anda di namespace gateway masuk Anda

Menerapkan aplikasi sampel

Di bagian ini, Anda memverifikasi bahwa alat pengelola sertifikat dapat menggunakan penerbit Layanan CA untuk mendapatkan sertifikat dari Layanan CA. Untuk memverifikasi, Anda akan men-deploy aplikasi contoh dengan konfigurasi perutean permintaan dan sertifikat untuk gateway masuk.

  1. 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 bidang data terkelola dalam namespace aplikasi contoh. Ubah nilai label ini jika Anda menggunakan Saluran rilis Cepat atau Stabil.

  2. 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
    
  3. 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. Misalnya, hello.
  4. 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 masuk. Biasanya, hanya administrator platform yang dapat mengubah resource dalam namespace ini, karena perubahan dapat memengaruhi seluruh mesh layanan. alat pengelola sertifikat 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 lain dalam daftar dnsNames di Sertifikat. Nama host ini disertakan dalam sertifikat sebagai Nama Alternatif Subjek (SAN).

  5. 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. Misalnya, hello.
    • Kolom credentialName di Gateway cocok dengan kolom secretName di Sertifikat. alat pengelola sertifikat membuat Secret Kubernetes dengan sertifikat TLS dari CA Service. Sertifikat ini memungkinkan gateway masuk untuk menghentikan traffic TLS yang ditujukan ke hello.example.com.

    Manifes Gateway menentukan TLS MUTUAL (mTLS). Jika Anda ingin mengonfigurasi gateway untuk TLS reguler, tetapkan mode TLS Gateway ke SIMPLE.

  6. 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 ke administrator platform yang memiliki izin untuk mengubah resource di namespace gateway masuk.

    Administrator aplikasi dengan izin untuk mengedit VirtualService dalam namespace aplikasi contoh dapat mengubah pemilihan rute oleh kolom permintaan lainnya, seperti jalur URL, tanpa berkoordinasi dengan administrator platform.

Jika Anda ingin mempelajari opsi konfigurasi lainnya, baca dokumentasi API untuk resource Sertifikat, 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 Istio PeerAuthentication dan AuthorizationPolicy.

Verifikasi solusi

Di bagian ini, Anda 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.

  1. 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.

  2. Berikan peran Pemohon Sertifikat Layanan CA di kumpulan CA subordinate 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.

  3. 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.

  4. Simpan alamat IP Load Balancer Jaringan passthrough gateway masuk ke file:

    kubectl get services istio-ingressgateway \
       --namespace GATEWAY_NAMESPACE \
       --output jsonpath='{.status.loadBalancer.ingress[0].ip}' > ilb-ip.txt
    
  5. Simpan sertifikat kunci publik dari root CA Anda ke dalam file:

    gcloud privateca roots describe ROOT_CA \
        --location CA_LOCATION \
        --pool ROOT_CA_POOL \
        --format 'value(pemCaCertificates)' > root-ca-cert.pem
    
  6. Salin sertifikat root CA dan file yang berisi alamat IP Load Balancer Jaringan passthrough gateway masuk ke instance VM:

    gcloud compute scp root-ca-cert.pem ilb-ip.txt cas-tutorial-client:~ \
       --zone ZONE
    
  7. Hubungkan ke instance VM menggunakan SSH:

    gcloud compute ssh cas-tutorial-client --zone ZONE
    

    Jalankan perintah lainnya di bagian ini dari sesi SSH.

  8. Instal paket ca-certificates dan coreutils, serta alat command line curl, openssl, dan jq:

    sudo apt-get update --yes
    
    sudo apt-get install --yes ca-certificates coreutils curl jq openssl
    
  9. 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
    
  10. Buat kueri server metadata untuk mendapatkan alamat email identitas akun layanan Google yang dilampirkan ke instance VM:

    GSA_EMAIL=$(curl --silent --header "Metadata-Flavor: Google" http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/email)
    
  11. 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 kolom di bagian konfigurasi lebih lanjut, lihat jenis CertificateConfig dalam dokumentasi CA Service API.

  12. 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.

  13. 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 menggunakan token akses untuk mengautentikasi permintaan API.

  14. Simpan sertifikat klien dan rantai sertifikat ke file:

    jq --raw-output --join-output ".pemCertificate , .pemCertificateChain[]" response.json > client-cert-chain.pem
    
  15. 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 memerintahkan curl untuk menggunakan sertifikat TLS klien dan kunci pribadi untuk mengautentikasi permintaan. File sertifikat klien berisi rantai lengkap sertifikat, dari sertifikat klien hingga CA root.

    • Tanda --cacert menginstruksikan curl untuk memverifikasi bahwa root CA yang Anda buat dalam tutorial ini, atau salah satu CA subordinatnya, menerbitkan sertifikat server.

      Jika Anda menghapus tanda ini, curl akan mencoba memverifikasi sertifikat server menggunakan paket CA default sistem operasi Anda, seperti paket ca-certificates di Debian. Verifikasi gagal karena paket CA default tidak menyertakan CA root yang Anda buat dalam tutorial ini.

    • Flag --resolve menginstruksikan curl untuk menggunakan alamat IP Load Balancer Jaringan passthrough internal sebagai tujuan untuk permintaan untuk menghosting hello.example.com di port 443.

      Jika Anda menghapus tanda ini, curl akan mencoba menggunakan DNS untuk me-resolve nama host hello.example.com. Resolusi DNS gagal karena tidak ada entri DNS untuk nama {i>host<i} ini.

      Di lingkungan Anda sendiri, sebaiknya buat data A DNS yang mengarah ke alamat IP Load Balancer Jaringan passthrough internal ($LOAD_BALANCER_IP). Buat data ini menggunakan Cloud DNS, dengan mengikuti dokumentasi tentang mengelola data.

    • Flag --silent menyembunyikan pelaporan progres download respons di output terminal.

    • Perintah menyalurkan output curl ke head -n1. Hasilnya adalah output di terminal hanya menyertakan baris pertama dari isi respons.

  16. Keluar dari sesi SSH:

    exit
    

Di bagian ini, Anda meminta sertifikat TLS klien langsung dari CA Service API. Jika klien adalah gateway keluar dari mesh layanan lain di cluster Kubernetes yang terpisah, Anda dapat menggunakan alat pengelola sertifikat dan penerbit Certificate Authority Service dengan root CA yang sama untuk memberikan sertifikat klien ke gateway keluar.

Dalam situasi lain, Anda dapat menggunakan alat seperti Hashicorp Vault, Terraform, atau gcloud untuk meminta sertifikat TLS klien untuk workload di luar mesh layanan. Untuk mengetahui informasi selengkapnya, lihat dokumentasi CA Service untuk mengetahui contoh solusi, dan dokumentasi gcloud untuk CA Service.

(Opsional) Menambahkan sertifikat CA ke trust store

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.

  1. Hubungkan ke instance VM menggunakan SSH:

    gcloud compute ssh cas-tutorial-client --zone ZONE
    

    Jalankan perintah lainnya di bagian ini dari sesi SSH.

  2. Salin sertifikat root CA ke direktori /usr/local/share/ca-certificates, dan pastikan file tersebut memiliki ekstensi .crt:

    sudo cp root-ca-cert.pem /usr/local/share/ca-certificates/cas-rootca.crt
    
  3. Setel izin file agar semua pengguna dapat membaca file sertifikat root CA:

    sudo chmod 644 /usr/local/share/ca-certificates/cas-rootca.crt
    
  4. Jalankan skrip update-ca-certificates:

    sudo update-ca-certificates
    

    Skrip ini menambahkan sertifikat tersebut ke kumpulan sertifikat tepercaya dalam direktori /etc/ssl/certs, dan ke file /etc/ssl/certs/ca-certificates.crt.

    Output-nya adalah sebagai berikut:

    Updating certificates in /etc/ssl/certs...
    1 added, 0 removed; done.
    Running hooks in /etc/ca-certificates/update.d...
    done.
    
  5. 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.

  6. Keluar dari sesi SSH:

    exit
    

Memecahkan masalah

Jika pengontrol penerbit CA Service tidak membuat rahasia sertifikat TLS, lihat log pengontrol penerbit CA Service:

kubectl logs deployment/google-cas-issuer --namespace cert-manager

Jika Anda mengalami masalah saat menginstal Anthos Service Mesh, jalankan alat asmcli untuk memvalidasi project Cloud dan cluster GKE.

Jika Anda mengalami masalah lain dengan tutorial ini, sebaiknya tinjau dokumen berikut:

Pembersihan

Agar tidak menimbulkan biaya berkelanjutan pada akun Google Cloud Anda untuk resource yang digunakan dalam tutorial ini, Anda dapat menghapus project atau menghapus setiap resource.

Menghapus project

  1. 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:

  1. Di Cloud Shell, batalkan pendaftaran cluster GKE dari GKE Hub:

    gcloud container hub memberships unregister CLUSTER_NAME \
        --gke-cluster ZONE/CLUSTER_NAME
    
  2. Hapus cluster GKE:

    gcloud container clusters delete CLUSTER_NAME \
        --zone ZONE --async --quiet
    
  3. Hapus binding kebijakan IAM pada kumpulan CA subordinat:

    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
    
  4. 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
    
  5. 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
    
  6. 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
    
  7. Hapus alamat IP load balancer yang dicadangkan:

    gcloud compute addresses delete asm-ingress-gateway-ilb \
        --region REGION --quiet
    
  8. Hapus instance VM Compute Engine:

    gcloud compute instances delete cas-tutorial-client \
        --zone ZONE --quiet
    

Langkah selanjutnya