Topik ini menjelaskan cara mengaktifkan klien non-SNI untuk digunakan dengan Apigee Hybrid.
Cara mengonfigurasi klien non-SNI
Bagian ini menjelaskan cara mengaktifkan dukungan untuk klien non-SNI (Server Name Indication) di Apigee Hybrid.
SNI menentukan cara rekan TLS (klien) akan menentukan nama host yang ingin dihubungkannya selama TLS handshake awal. SNI telah menjadi bagian dari TLS sejak tahun 2003. Sebelum SNI, saat peer TLS mengirim HELLO untuk memulai handshake, peer penerima selalu merespons dengan kredensial yang sama. SNI diperkenalkan untuk memungkinkan satu load balancer mendukung beberapa nama host dan set kredensial yang berbeda untuk pengelolaan koneksi TLS. SNI kini digunakan oleh sebagian besar klien TLS.
Ada pengecualian. Sebagai contoh, Load Balancer Google Cloud akan menggunakan handshake non-SNI untuk terhubung ke backend.
Jika Anda ingin mengonfigurasi Apigee Hybrid agar dapat menangani handshake TLS yang tidak menggunakan SNI, baik karena Apigee Hybrid Anda adalah backend ke Cloud Load Balancer Google, atau karena Apigee Hybrid Anda harus mendukung klien non-SNI lainnya, Anda harus mengikuti langkah-langkah yang dijelaskan di bawah. Negosiasi non-SNI akan bertindak sebagai penggantian; Apigee Hybrid akan menggunakannya untuk klien yang tidak menggunakan SNI.
- Buat resource
ApigeeRoute
. PastikanenableNonSniClient
disetel ketrue
:apiVersion: apigee.cloud.google.com/v1alpha1 kind: ApigeeRoute metadata: name: ROUTE_NAME namespace: APIGEE_NAMESPACE spec: hostnames: - "*" ports: - number: 443 protocol: HTTPS tls: credentialName: CREDENTIAL_NAME mode: SIMPLE #optional minProtocolVersion: TLS_AUTO selector: app: apigee-ingressgateway enableNonSniClient: true
Dengan:
- ROUTE_NAME adalah nama yang Anda berikan ke resource kustom (CR).
- CREDENTIAL_NAME adalah nama Secret Kubernetes yang di-deploy ke cluster
yang berisi kredensial TLS untuk virtualhost Anda. Anda dapat menemukan nama kredensial dengan
Perintah
kubectl
berikut:kubectl -n APIGEE_NAMESPACE get ApigeeRoutes -o=yaml | grep credentialName
hostnames
harus ditetapkan ke karakter pengganti "*".
- Buka file penggantian dan lakukan perubahan yang dijelaskan pada langkah berikutnya.
- Untuk setiap grup lingkungan, tambahkan nama ApigeeRoute ke properti
additionalGateways
. Contoh:virtualhosts: - name: default sslCertPath: ./certs/fullchain.pem sslKeyPath: ./certs/privkey.pem additionalGateways: ["ROUTE_NAME"]
- Simpan file CRD. Contoh:
ApigeeRoute.yaml
- Terapkan CRD ke cluster:
kubectl apply -f ApigeeRoute.yaml -n APIGEE_NAMESPACE
- Terapkan perubahan pada
virtualhosts
. Jika telah menetapkan variabel lingkungan $ENV_GROUP di shell, Anda dapat menggunakannya dalam perintah berikut:helm upgrade $ENV_GROUP apigee-virtualhost/ \ --namespace APIGEE_NAMESPACE \ --atomic \ --set envgroup=$ENV_GROUP \ -f OVERRIDES_FILE.yaml
Catatan penggunaan
- Apa yang terjadi jika cluster memiliki lebih dari satu organisasi?
Karena ingress berada di tingkat cluster untuk port tertentu (443), dan hanya boleh ada satu pasangan kunci/sertifikat untuk CRD ApigeeRoute, semua org. harus menggunakan pasangan kunci/sertifikat yang sama.
- Apa yang terjadi jika cluster memiliki lebih dari satu grup lingkungan? Apakah akan berfungsi
jika host virtual menggunakan pasangan kunci/sertifikat yang sama?
Semua nama host di semua grup lingkungan harus menggunakan pasangan kunci/sertifikat yang sama.
- Mengapa kita membuat ApigeeRoute, bukan Gateway?
ApigeeRoutes dapat divalidasi oleh Apigee; namun, Gateway (CRD Istio) tidak dapat divalidasi. Secara teknis, Gateway pun dapat berfungsi, tetapi kita dapat mencegah potensi kesalahan konfigurasi (melalui webhook validasi).
- Bagaimana cara mengonfigurasi klien non-SNI untuk Apigee?
Jika instance Apigee Anda diekspos melalui Google Load Balancer, Load Balancer akan mendukung klien non-SNI seperti yang dijelaskan dalam dokumentasi Load Balancing. Jika tidak, jika Anda telah mengekspos instance Apigee melalui endpoint PSC internal atau VPC, secara default instance Apigee mendukung klien non-SNI.