Mengotomatiskan pengelolaan sertifikat TLS untuk Cloud Service Mesh gateway masuk menggunakan Certificate Authority Service

Tutorial ini menunjukkan operator platform cara menggunakan Penerbit Certificate Authority Service (CA Service) untuk alat pengelola sertifikat untuk mengotomatiskan pengelolaan sertifikat TLS untuk gateway masuk Cloud Service Mesh. Sertifikat ini memungkinkan gateway masuk untuk menghentikan HTTPS dan TLS serta Traffic mTLS 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 untuk setiap workload dalam mesh layanan. Sertifikat ini mengaktifkan enkripsi dan TLS yang saling diautentikasi (mTLS) komunikasi antar-beban kerja dalam mesh layanan. Salah satu CA yang didukung masalah dan menandatangani sertifikat.

Namun, Cloud Service Mesh tidak secara otomatis menyediakan sertifikat gateway masuk untuk traffic yang memasuki mesh layanan. Solusi umumnya adalah menggunakan cert-manager open source untuk mengotomatisasi pengelolaan sertifikat gateway masuk.

Alat pengelola sertifikat meminta sertifikat dari penerbit, yang mewakili certificate authority (CA). CA Service adalah layanan Layanan Google Cloud yang memungkinkan Anda membuat CA pribadi sendiri. Tujuan alat pengelola sertifikat dapat meminta sertifikat dari CA Service dengan menggunakan fitur open source penerbit eksternal untuk CA Service.

CA pribadi dapat menerbitkan sertifikat TLS yang mengautentikasi dan mengenkripsi traffic di dalam jaringan internal. Gateway masuk Cloud Service Mesh sering kali ditetapkan untuk memungkinkan traffic masuk dari klien yang ada dalam VPC, tetapi di luar mesh layanan. Untuk lalu lintas jaringan internal, Anda dapat menggunakan CA pribadi di {i>CA Service<i} untuk menerbitkan sertifikat untuk yaitu gateway masuknya.

Tutorial ini menunjukkan kepada Anda cara menyiapkan alat pengelola sertifikat dan Penerbit CA Service untuk mengotomatiskan penyediaan sertifikat TLS dan perpanjangan untuk gateway masuk. alat pengelola sertifikat menyediakan sertifikat sebagai Resource Secret Kubernetes jenis TLS. Saat memperpanjang sertifikat, alat pengelola sertifikat akan memperbarui resource Secret dengan sertifikat baru. Gateway masuk menjalankan Envoy Proxy, dan alat ini mendukung Envoy's secret discovery service (SDS). SDS memungkinkan gateway masuk untuk mulai menggunakan sertifikat baru tanpa yang mengharuskan 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 Cloud Service Mesh. Di sini ini, Anda menggunakan CA Service untuk proxy dan ingress file bantuan gateway certificate. Hal ini memungkinkan Anda menggunakan satu root CA untuk semua TLS CA {i>root<i}.

Diagram berikut menunjukkan resource yang Anda sediakan dalam tutorial ini. Anda menyediakan Load Balancer Jaringan passthrough internal untuk gateway masuk. Tujuan Load Balancer Jaringan passthrough internal bukan proxy, sehingga tidak menghentikan koneksi TCP atau melakukan handshake TLS. Sebaliknya, akan mengarahkan koneksi ke pod deployment istio-ingressgateway.

Rahasia hello-example-com-credential berisi sertifikat dan tombol. Gateway hello mengonfigurasi pod istio-ingressgateway deployment 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 dalam namespace cert-manager meminta sertifikat dari CA yang Anda buat di {i>CA Service<i}. Anda membuat binding kebijakan Identity and Access Management yang mengizinkan pod ca-service-isser untuk meniru identitas akun layanan Google menggunakan Workload Identity Federation for GKE. Anda beri akun layanan Google izin ini untuk meminta sertifikat dari CA di Layanan CA 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 Google Cloud baru mungkin memenuhi syarat untuk uji coba gratis.

Setelah menyelesaikan tutorial ini, Anda dapat menghindari penagihan berkelanjutan dengan menghapus resource yang telah dibuat. Untuk informasi selengkapnya, lihat Pembersihan.

Sebelum memulai

  1. Di Konsol Google Cloud, buka halaman pemilih project, dan kemudian memilih atau membuat sebuah proyek.

  2. Pastikan penagihan diaktifkan untuk project Google Cloud Anda.

  3. Di konsol Google Cloud, buka Cloud Shell.

    Di bagian bawah konsol Google Cloud, ada sesi Cloud Shell terbuka dan menampilkan prompt command line. Anda 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 Cloud Anda proyek.

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

  5. 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 CA Service

Di bagian ini, Anda akan membuat CA {i>root<i} dan dua CA subordinat di CA. Satu subordinate CA menerbitkan sertifikat ke traffic masuk dan subordinate CA lainnya menerbitkan sertifikat untuk {i>proxy<i} file bantuan di jalanya.

Untuk mempermudah, gunakan project yang sama untuk cluster GKE dan CA {i>root<i} dan subordinate dalam tutorial ini. Di lingkungan Anda sendiri, Anda dapat gunakan 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. Contoh, root-ca-pool-tutorial.
    • CA_LOCATION adalah lokasi kumpulan CA. Contoh, us-central1.

    Anda dapat mencantumkan lokasi CA Service yang tersedia menggunakan perintah: gcloud privateca locations list

  2. Membuat dan mengaktifkan root CA:

    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 Kanada. Contoh, root-ca-tutorial.

  3. Membuat kumpulan CA untuk digunakan bagi CA subordinat yang menerbitkan sertifikat untuk gateway masuknya:

    gcloud privateca pools create SUBORDINATE_CA_POOL_GATEWAYS \
    --location CA_LOCATION \
    --tier devops
    • SUBORDINATE_CA_POOL_GATEWAYS adalah nama CA. Contoh, subordinate-ca-mtls-pool-gateways-tutorial.

  4. Membuat dan mengaktifkan subordinate CA yang menerbitkan sertifikat untuk ingress {i>gateway<i}:

    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 Anda inginkan digunakan untuk subordinate CA. Contoh, subordinate-ca-mtls-gateways-tutorial.
    • Flag --use-preset-profile mengonfigurasi subordinate CA untuk menggunakan mTLS bawahan profil sertifikat. Profil ini memungkinkan CA bawahan untuk menerbitkan sertifikat TLS klien dan server untuk mTLS.

    Jika Anda ingin gateway masuk Anda menggunakan TLS sederhana, bukan mTLS, subordinate hanya perlu menerbitkan sertifikat TLS server. Dalam hal ini, Anda dapat menggunakan TLS server Subordinate (subordinate_server_tls_pathlen_0) sebagai gantinya.

  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 jala tersebut.

  6. Membuat kumpulan CA untuk digunakan bagi CA subordinat yang menerbitkan sertifikat untuk 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 CA. Contoh, subordinate-ca-mtls-pool-sidecars-tutorial.

  7. Membuat dan mengaktifkan subordinate CA yang menerbitkan sertifikat ke file bantuan {i>proxy<i} di {i>mesh<i}:

    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 Anda inginkan digunakan untuk subordinate CA. Contoh, 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 gugus ini. Contoh, asm-ingress-cert-manager-ca-service.

    Ganti ZONE dengan zona yang ingin Anda gunakan untuk . Contoh, us-central1-f.

    Perhatikan hal-hal berikut terkait perintah ini:

    • Flag --release-channel memilih Saluran rilis GKE untuk cluster tersebut.
    • Cloud Service Mesh dan penerbit CA Service untuk alat pengelola sertifikat mengharuskan Anda menetapkan cakupan cloud-platform di node cluster.
    • Argumen --workload-pool mengaktifkan Workload Identity Federation for GKE, yang memungkinkan akun layanan Kubernetes penerbit Layanan CA meniru akun layanan Google. Peniruan identitas ini berarti bahwa Pod penerbit CA Service dapat mengakses CA Service API tanpa mendownload file kunci untuk akun layanan Google.

  2. Memberikan 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 diberikan oleh cluster-admin Kubernetes ClusterRole untuk membuat kontrol akses berbasis peran (RBAC) untuk Cloud Service Mesh, dan cara menginstal alat pengelola sertifikat.

Menginstal bidang kontrol Anthos Service Mesh

Dalam tutorial ini, Anda menginstal Cloud Service Mesh yang dikelola untuk cluster GKE di Google Cloud, dengan semua resource di satu proyek. Di lingkungan Anda sendiri, Anda dapat menerapkan solusi yang dijelaskan di dokumen ini menggunakan Cloud Service Mesh terkelola bidang kontrol dalam cluster.

Cloud Service Mesh menyediakan berbagai opsi penginstalan untuk berbagai skenario. Setelah menyelesaikan tutorial ini, sebaiknya Anda meninjau panduan penginstalan untuk memilih opsi yang paling sesuai dengan lingkungan Anda.

  1. Di Cloud Shell, download asmcli alat penginstalan:

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

chmod +x asmcli

    Anda menggunakan asmcli untuk menginstal bidang kontrol Cloud Service Mesh.

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

    Penginstalan memerlukan waktu beberapa menit. Saat penginstalan selesai, Anda lihat output berikut:

    asmcli: Successfully installed ASM.

Menginstal gateway masuk

  1. Di Cloud Shell, buat namespace Kubernetes untuk traffic masuk {i>gateway<i}:

    kubectl create namespace GATEWAY_NAMESPACE
    • GATEWAY_NAMESPACE adalah nama yang ingin Anda gunakan untuk gateway masuknya. Contoh, istio-ingress.

  2. Mencadangkan alamat IP internal statis untuk digunakan untuk Load Balancer Jaringan passthrough gateway masuk:

    LOAD_BALANCER_IP=$(gcloud compute addresses create \
    asm-ingress-gateway-ilb \
    --region REGION \
    --subnet default \
    --format 'value(address)')
    • Ganti REGION dengan wilayah yang berisi 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 tempat Anda tentukan.

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

  4. Membuat manifes penginstalan gateway masuk menggunakan manifes operator dan istioctl alat yang didownload 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 alat cert-manager manifes penginstalan:

    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

    Penginstalan alat pengelola sertifikat dapat memerlukan waktu sekitar satu menit.

Menginstal pengontrol penerbit CA Service

Pengontrol penerbit Layanan CA mengaktifkan alat pengelola sertifikat untuk meminta sertifikat menggunakan CA. Pengontrol menggunakan alat pengelola sertifikat penerbit eksternal mekanisme ekstensif.

  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 layanan Google menggunakan akun layanan. Contoh, cert-manager-ca-service-issuer.

    Pengontrol penerbit Certificate Authority Service menggunakan layanan Google ini untuk mengautentikasi ke Certificate Authority Service API.

  2. Buat binding kebijakan Identity and Access Management yang memungkinkan Akun layanan Google pengontrol penerbit Certificate Authority Service untuk diminta sertifikat dari kumpulan CA yang berisi CA subordinate 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 untuk mengizinkan ksa-google-cas-issuer akun layanan Kubernetes di cert-manager untuk 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 CA Service menggunakan ksa-google-cas-issuer akun layanan Kubernetes.

  5. Instal pengontrol penerbit CA Service di Cluster GKE:

    kubectl apply --filename ca-service-issuer.yaml

  6. Tambahkan anotasi Workload Identity Federation untuk GKE iam.gke.io/gcp-service-account ke akun layanan Kubernetes yang digunakan oleh penerbit CA Service pod pengontrol:

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

Membuat penerbit sertifikat

  1. Di Cloud Shell, buat dan terapkan GoogleCASIssuer manifes:

    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 mengaktifkan alat pengelola sertifikat untuk menyediakan sertifikat dari kumpulan CA subordinat 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 CA. Untuk memverifikasi, Anda men-deploy aplikasi contoh dengan konfigurasi perutean permintaan, dan sertifikat untuk gerbang masuk.

  1. Di Cloud Shell, buat namespace untuk aplikasi contoh referensi:

    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 dari 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. Contoh, 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, karena perubahan bisa memengaruhi seluruh mesh layanan. pengelola sertifikat membuat resource Rahasia untuk sertifikat TLS di namespace. Berarti, administrator aplikasi tidak perlu memiliki akses ke namespace gateway masuk.

    Anda dapat menambahkan nama host lain di daftar dnsNames di Sertifikat. Nama {i>host<i} ini disertakan dalam sertifikat sebagai Nama Alternatif Subjek (SAN).

  5. Buat 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 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 MUTUAL TLS (mTLS). Jika ingin mengonfigurasi gateway untuk TLS reguler, setel TLS. mode 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 platform administrator yang memiliki izin untuk mengubah resource saat traffic masuk namespace gateway.

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

Jika Anda ingin mempelajari opsi konfigurasi lainnya, baca dokumentasi API untuk Sertifikat, Gateway, dan VirtualService Google Cloud Platform.

Anda dapat menerapkan kebijakan autentikasi dan otorisasi untuk traffic yang memasuki melalui gateway masuk. Untuk melakukannya, baca dokumentasi tentang Istio PeerAuthentication Istio dan AuthorizationPolicy Google Cloud Platform.

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 di instance VM Compute Engine, minta sertifikat TLS klien dari CA Service, dan menggunakan sertifikat ini untuk mengautentikasi permintaan ke aplikasi contoh.

Anda memerlukan akses SSH ke instance VM. Jaringan default berisi aturan firewall yang mengizinkan akses SSH. Jika Anda tidak memiliki akses SSH, ikuti dokumentasi aturan firewall untuk membuat firewall aturan yang mengizinkan koneksi TCP yang masuk pada porta 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 layanan Google menggunakan akun layanan. Contoh, cas-tutorial-client.

    Anda menetapkan akun layanan Google ini ke VM Compute Engine di instance Compute Engine.

  2. Berikan Pemohon Sertifikat Layanan CA terkait kumpulan CA bawahan 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 public key certificate CA root Anda ke file:

    gcloud privateca roots describe ROOT_CA \
    --location CA_LOCATION \
    --pool ROOT_CA_POOL \
    --format 'value(pemCaCertificates)' > root-ca-cert.pem

  6. Salin sertifikat CA root 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 curl, openssl, dan jq alat command line:

    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 email alamat 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 lebih lanjut tentang kolom di bagian konfigurasi, lihat dokumentasi CertificateConfig di dokumentasi CA Service API.

  12. Meminta 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 layanan Google yang terpasang 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 tersebut 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 sampel aplikasi:

    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 menginstruksikan curl untuk menggunakan TLS klien sertifikat dan kunci pribadi untuk mengotentikasi permintaan. Klien file sertifikat berisi rantai sertifikat lengkap, dari klien sertifikat ke CA {i>root<i}.

    • Tanda --cacert menginstruksikan curl untuk memverifikasi bahwa CA root yang Anda buat dalam tutorial ini, atau salah satu CA bawahannya, memberikan CA {i>root<i}.

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

    • Tanda --resolve menginstruksikan curl untuk menggunakan IP Load Balancer Jaringan passthrough internal sebagai tujuan bagi 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 DNS untuk nama {i>host<i} ini.

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

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

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

  16. Keluar dari sesi SSH:

    exit

Di bagian ini, Anda meminta sertifikat TLS klien langsung dari CA Service API. Dalam situasi saat klien menjadi traffic keluar gateway mesh layanan lain di cluster Kubernetes terpisah, Anda bisa 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 layanan {i>mesh.<i} Untuk informasi lebih lanjut, lihat dokumentasi Layanan CA untuk 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 Sertifikat CA 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. Menyalin sertifikat CA root 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 CA root:

    sudo chmod 644 /usr/local/share/ca-certificates/cas-rootca.crt

  4. Menjalankan update-ca-certificates skrip:

    sudo update-ca-certificates

    Skrip ini akan menambahkan sertifikat ke kumpulan sertifikat tepercaya dalam 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.

  5. Gunakan curl untuk mengirim permintaan HTTPS dari instance VM ke sampel aplikasi:

    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 {i>default<i}.

  6. Keluar dari sesi SSH:

    exit

Memecahkan masalah

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

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-dokumen ini:

Pembersihan

Agar tidak menimbulkan biaya berkelanjutan ke akun Google Cloud Anda selama resource yang digunakan dalam tutorial ini, Anda dapat menghapus project resource individual.

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 Hub GKE:

    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. Menonaktifkan dan menjadwalkan penghapusan CA subordinate 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