Mengaktifkan fitur opsional di bidang kontrol terkelola
Halaman ini menjelaskan cara mengaktifkan fitur opsional di Cloud Service Mesh terkelola. Untuk mengetahui informasi tentang bidang kontrol dalam cluster, lihat Mengaktifkan fitur opsional pada bidang kontrol dalam cluster.
Saat Anda menyediakan Cloud Service Mesh terkelola, fitur yang didukung berbeda-beda 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 Migrasi dari IstioOperator dapat membantu mengonversi ke konfigurasi yang didukung oleh bidang kontrol terkelola.
Gambar proxy tanpa distro
Jika Anda langsung melakukan aktivasi ke Cloud Service Mesh dengan implementasi bidang kontrol
TRAFFIC_DIRECTOR
terkelola, hanya jenis image tanpa distro yang didukung. Anda tidak dapat mengubahnya.Jika perangkat Anda awalnya menggunakan implementasi bidang kontrol
ISTIOD
dan dimigrasikan ke implementasiTRAFFIC_DIRECTOR
, jenis gambar tidak akan berubah selama migrasi, dan Anda dapat mengubah jenis gambar menjadi distroless.
Sebagai praktik terbaik, Anda harus membatasi konten runtime container hanya ke paket yang diperlukan. Pendekatan ini meningkatkan keamanan dan rasio sinyal terhadap gangguan dari pemindai Kerentanan dan Eksposur Umum (CVE). Istio menyediakan image proxy berdasarkan image dasar tanpa gangguan.
Image distroless proxy tidak berisi biner selain proxy.
Oleh karena itu, Anda tidak dapat exec
shell atau menggunakan curl
, ping
, atau utilitas debug
lainnya di dalam container. Namun, Anda dapat menggunakan container ephemeral untuk ditambahkan ke Pod workload yang sedang berjalan agar dapat memeriksanya dan menjalankan perintah kustom. Misalnya, lihat bagian 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 ulang 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 image 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 mana pun diizinkan. Untuk mengontrol dan membatasi traffic
hanya untuk layanan eksternal yang telah
ditentukan dengan entri layanan, Anda dapat mengubah perilaku default ALLOW_ANY
menjadi
REGISTRY_ONLY
.
Konfigurasi berikut mengonfigurasi
outboundTrafficPolicy
keREGISTRY_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 Anda (
asm-managed
,asm-managed-stable
, atauasm-managed-rapid
).Anda dapat membuat perubahan konfigurasi yang diperlukan sebelumnya di configmap menggunakan perintah berikut:
kubectl edit configmap istio-release-channel -n istio-system -o yaml
Jalankan perintah berikut untuk melihat configmap:
kubectl get configmap istio-release-channel -n istio-system -o yaml
Untuk memverifikasi bahwa
outboundTrafficPolicy
diaktifkan denganREGISTRY_ONLY
, pastikan baris berikut muncul di bagianmesh:
.... 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 workload yang di-deploy. Untuk mengetahui informasi selengkapnya, lihat Mengonfigurasi autentikasi pengguna Cloud Service Mesh.
Mengonfigurasi versi TLS minimum untuk workload 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 mengetahui 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