Mengaktifkan fitur opsional di bidang kontrol terkelola

Halaman ini menjelaskan cara mengaktifkan fitur opsional di Cloud Service Mesh terkelola. Untuk informasi tentang panel kontrol dalam cluster, lihat Mengaktifkan fitur opsional di panel kontrol dalam cluster.

Saat Anda menyediakan Cloud Service Mesh terkelola, fitur yang didukung akan berbeda berdasarkan penerapan bidang kontrol, dan fitur tertentu hanya tersedia melalui daftar yang diizinkan. Lihat fitur yang didukung untuk mengetahui detailnya. Jika saat ini Anda menggunakan konfigurasi berbasis IstioOperator, alat Migrate from IstioOperator dapat membantu mengonversi ke konfigurasi yang didukung oleh platform kontrol terkelola.

Gambar proxy distroless

  • Jika Anda langsung melakukan aktivasi ke Cloud Service Mesh dengan implementasi platform kontrol TRAFFIC_DIRECTOR terkelola, hanya jenis image distroless yang didukung. Anda tidak dapat mengubahnya.

  • Jika awalnya fleet Anda menggunakan penerapan bidang kontrol ISTIOD dan dimigrasikan ke penerapan TRAFFIC_DIRECTOR, jenis image Anda tidak akan diubah selama migrasi, dan Anda dapat mengubah jenis image menjadi distroless sendiri.

Sebagai praktik terbaik, Anda harus membatasi konten runtime penampung hanya ke paket yang diperlukan. Pendekatan ini meningkatkan keamanan dan rasio sinyal-derau pemindai Common Vulnerabilities and Exposures (CVE). Istio menyediakan image proxy berdasarkan image dasar distroless.

Image proxy tanpa distro tidak berisi biner selain proxy. Oleh karena itu, Anda tidak dapat exec shell atau menggunakan curl, ping, atau utilitas debug lainnya di dalam penampung. Namun, Anda dapat menggunakan penampung sementara untuk dilampirkan ke Pod workload yang sedang berjalan agar dapat memeriksanya dan menjalankan perintah kustom. Misalnya, lihat Mengumpulkan log Cloud Service Mesh.

Konfigurasi berikut memungkinkan image distroless untuk seluruh Cloud Service Mesh. Perubahan jenis image mengharuskan setiap pod dimulai ulang dan dimasukkan kembali agar dapat diterapkan.

     apiVersion: v1
     kind: ConfigMap
     metadata:
       name: istio-release-channel
       namespace: istio-system
     data:
       mesh: |-
         defaultConfig:
           image:
             imageType: distroless

Anda dapat mengganti imageType menggunakan anotasi pod berikut.

sidecar.istio.io/proxyImageType: debug

Setelah mengubah jenis gambar deployment menggunakan anotasi, deployment harus dimulai ulang.

kubectl rollout restart deployment -n NAMESPACE DEPLOYMENT_NAME

Karena tidak memerlukan image dasar debug, sebagian besar jenis proses debug proxy harus menggunakan gcloud beta container fleet mesh debug proxy-status / proxy-config (detail).

Kebijakan Traffic Keluar

Secara default, outboundTrafficPolicy disetel ke ALLOW_ANY. Dalam mode ini, semua traffic ke layanan eksternal apa pun diizinkan. Untuk mengontrol dan membatasi traffic hanya ke layanan eksternal yang entri layanan-nya ditentukan, Anda dapat mengubah perilaku default ALLOW_ANY menjadi REGISTRY_ONLY.

  1. Konfigurasi berikut mengonfigurasi outboundTrafficPolicy ke REGISTRY_ONLY:

      apiVersion: v1
      kind: ConfigMap
      metadata:
        name: istio-release-channel
        namespace: istio-system
      data:
        mesh: |-
          outboundTrafficPolicy:
           mode: REGISTRY_ONLY
    

    dengan release-channel adalah saluran rilis (asm-managed, asm-managed-stable, atau asm-managed-rapid).

  2. Anda dapat membuat perubahan konfigurasi yang diperlukan sebelumnya di configmap menggunakan perintah berikut:

    kubectl edit configmap istio-release-channel -n istio-system -o yaml
    
  3. Jalankan perintah berikut untuk melihat configmap:

    kubectl get configmap istio-release-channel -n istio-system -o yaml
    
  4. Untuk memverifikasi bahwa outboundTrafficPolicy diaktifkan dengan REGISTRY_ONLY, pastikan baris berikut muncul di bagian mesh:.

    ...
    apiVersion: v1
    data:
      mesh: |
        outboundTrafficPolicy:
         mode: REGISTRY_ONLY
    ...
    

Autentikasi pengguna akhir

Anda dapat mengonfigurasi autentikasi pengguna Cloud Service Mesh terkelola untuk autentikasi pengguna akhir berbasis browser dan kontrol akses ke beban kerja yang di-deploy. Untuk mengetahui informasi selengkapnya, lihat Mengonfigurasi autentikasi pengguna Cloud Service Mesh.

Mengonfigurasi versi TLS minimum untuk beban kerja Anda

Jika Anda langsung melakukan aktivasi ke Cloud Service Mesh dengan implementasi bidang kontrol TRAFFIC_DIRECTOR terkelola, Anda tidak dapat mengubah setelan ini.

Anda dapat menggunakan kolom minProtocolVersion untuk menentukan versi TLS minimum untuk koneksi TLS di antara workload Anda. Untuk informasi selengkapnya tentang cara menetapkan versi TLS minimum dan memeriksa konfigurasi TLS workload Anda, lihat Konfigurasi Versi TLS Minimum Workload Istio.

Contoh berikut menunjukkan ConfigMap yang menetapkan versi TLS minimum untuk beban kerja ke 1.3:

apiVersion: v1
kind: ConfigMap
metadata:
  name: istio-release-channel
  namespace: istio-system
data:
  mesh: |-
    meshMTLS:
      minProtocolVersion: TLSV1_3