Anthos Service Mesh dan Traffic Director kini bergabung menjadi Cloud Service Mesh. Untuk mengetahui informasi selengkapnya, lihat ringkasan Cloud Service Mesh.

Anthos Service Mesh melalui contoh: mTLS

Pada Anthos Service Mesh 1.5 dan yang lebih baru, mutual TLS otomatis (auto mTLS) diaktifkan secara default. Dengan mTLS otomatis, proxy sidecar klien secara otomatis mendeteksi apakah server memiliki file bantuan. Sidecar klien mengirimkan mTLS ke workload dengan sidecar dan mengirim teks biasa ke workload tanpa sidecar. Namun, perlu diperhatikan bahwa layanan menerima traffic teks biasa dan mTLS. Saat memasukkan proxy file bantuan ke Pod Anda, sebaiknya konfigurasi juga layanan Anda agar hanya menerima traffic mTLS.

Dengan Anthos Service Mesh, Anda dapat menerapkan mTLS di luar kode aplikasi dengan menerapkan satu file YAML. Anthos Service Mesh memberi Anda fleksibilitas untuk menerapkan kebijakan autentikasi ke seluruh mesh layanan, ke namespace, atau setiap workload.

mTLS bersama

Biaya

Dalam dokumen ini, Anda akan 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 biaya berkelanjutan dengan menghapus resource yang Anda buat. Untuk informasi selengkapnya, lihat Pembersihan.

Sebelum memulai

Tutorial ini menggunakan aplikasi contoh Online Boutique untuk mendemonstrasikan konfigurasi mTLS di cluster GKE dengan Anthos Service Mesh terinstal.

Jika Anda perlu menyiapkan cluster GKE untuk tutorial ini, baca panduan memulai Anthos Service Mesh, yang memandu Anda dalam menyiapkan cluster, menginstal Anthos Service Mesh, dan men-deploy contoh Butik Online ke namespace demo.
Jika Anda telah menginstal cluster GKE dengan Anthos Service Mesh, tetapi memerlukan sampelnya, lihat Boutique Online, yang akan memandu Anda dalam men-deploy sampel ke namespace demo.

Akses Butik Online

Setel konteks saat ini untuk kubectl ke cluster tempat Anda men-deploy Online Boutique:

gcloud container clusters get-credentials CLUSTER_NAME  \
    --project=PROJECT_ID \
    --zone=CLUSTER_LOCATION

Dapatkan daftar layanan Butik Online:
```
kubectl get services -n demo
```
Perhatikan bahwa frontend-external adalah LoadBalancer, dan memiliki alamat IP eksternal. Aplikasi contoh menyertakan layanan yang merupakan load balancer, sehingga dapat di-deploy di GKE tanpa Anthos Service Mesh.
Buka aplikasi di browser menggunakan alamat IP eksternal layanan frontend-external:
```
http://FRONTEND_EXTERNAL_IP/
```
Anthos Service Mesh menyediakan gateway masuk default yang disebut istio-ingressgateway. Anda juga dapat mengakses Online Boutique menggunakan alamat IP eksternal istio-ingressgateway. Dapatkan IP eksternal istio-ingressgateway:
```
kubectl get service istio-ingressgateway -n istio-system
```
Buka tab lain di browser Anda, lalu buka aplikasi tersebut menggunakan alamat IP eksternal istio-ingressgateway:
```
http://INGRESS_GATEWAY_EXTERNAL_IP/
```
Jalankan perintah berikut untuk melakukan curl layanan frontend dengan HTTP biasa dari Pod lain dalam namespace demo.
```
kubectl exec \
  $(kubectl get pod -l app=productcatalogservice -n demo -o jsonpath={.items..metadata.name}) \
  -c istio-proxy -n demo -- \
  curl http://frontend:80/ -o /dev/null -s -w '%{http_code}\n'
```
Permintaan Anda berhasil dengan status 200, karena secara default, traffic TLS dan teks biasa diterima.

Mengaktifkan TLS bersama per namespace

Anda menerapkan mTLS dengan menerapkan kebijakan PeerAuthentication dengan kubectl.

Terapkan kebijakan autentikasi berikut untuk mengonfigurasi semua layanan di namespace demo agar hanya menerima mTLS:
```
kubectl apply -f - <<EOF
apiVersion: "security.istio.io/v1beta1"
kind: "PeerAuthentication"
metadata:
  name: "namespace-policy"
  namespace: "demo"
spec:
  mtls:
    mode: STRICT
EOF
```
Output yang diharapkan:
```
peerauthentication.security.istio.io/namespace-policy created
```
Baris mode: STRICT dalam YAML mengonfigurasi layanan agar hanya menerima mTLS. Secara default, mode adalah PERMISSIVE, yang mengonfigurasi layanan untuk menerima teks biasa dan mTLS.
Buka tab di browser Anda yang mengakses Butik Online menggunakan alamat IP eksternal layanan frontend-external, lalu muat ulang halaman. Browser menampilkan error berikut:

Memuat ulang halaman akan menyebabkan teks biasa dikirim ke layanan frontend. Karena kebijakan autentikasi STRICT, proxy file bantuan memblokir permintaan ke layanan.
Buka tab di browser Anda yang mengakses Butik Online menggunakan alamat IP eksternal istio-ingressgateway, lalu muat ulang halaman, yang berhasil ditampilkan. Saat Anda mengakses Online Boutique menggunakan istio-ingressgateway, permintaan ini akan melalui jalur berikut:

Alur autentikasi mTLS:
1. Browser mengirimkan permintaan HTTP teks biasa ke server.
2. Penampung proxy istio-ingressgateway mencegat permintaan.
3. Proxy istio-ingressgateway melakukan handshake TLS dengan proxy sisi server (layanan frontend dalam contoh ini). Handshake ini mencakup pertukaran sertifikat. Sertifikat ini sebelumnya dimuat ke dalam container proxy oleh Anthos Service Mesh.
4. Proxy istio-ingressgateway melakukan pemeriksaan penamaan aman pada sertifikat server, yang memverifikasi bahwa identitas resmi sedang menjalankan server.
5. istio-ingressgateway dan proxy server membuat koneksi TLS bersamaan, dan proxy server meneruskan permintaan ke penampung aplikasi server (layanan frontend).
Jalankan perintah berikut untuk melakukan curl layanan frontend dengan HTTP biasa dari Pod lain dalam namespace demo.
```
kubectl exec \
  $(kubectl get pod -l app=productcatalogservice -n demo -o jsonpath={.items..metadata.name}) \
  -c istio-proxy -n demo -- \
  curl http://frontend:80/ -o /dev/null -s -w '%{http_code}\n'
```
Permintaan Anda gagal karena semua layanan dalam namespace demo ditetapkan ke STRICT mTLS, dan proxy file bantuan memblokir permintaan ke layanan.

Output yang diharapkan:
```
000
command terminated with exit code 56
```

Melihat status mTLS

Anda dapat melihat status fitur keamanan Anthos, termasuk kebijakan autentikasi, di Konsol Google Cloud.

Di konsol Google Cloud, buka halaman GKE Enterprise Security.

Buka GKE Enterprise Security
Pilih project Google Cloud dari menu drop-down di panel menu.

Ringkasan Kebijakan menampilkan status keamanan aplikasi, termasuk mTLS.
Klik Audit Kebijakan untuk melihat status kebijakan beban kerja untuk setiap cluster dan namespace. Kartu Status mTLS memberikan ringkasan. Daftar Workloads menampilkan status mTLS setiap beban kerja.

Menemukan dan menghapus kebijakan autentikasi

Untuk daftar semua kebijakan PeerAuthentication dalam mesh layanan:
```
kubectl get peerauthentication --all-namespaces
```

Hapus kebijakan autentikasi:

kubectl delete peerauthentication -n demo namespace-policy

Output yang diharapkan:

peerauthentication.security.istio.io "namespace-policy" deleted

Akses Butik Online menggunakan alamat IP eksternal layanan frontend-external, lalu muat ulang halaman. Halaman ditampilkan seperti yang diharapkan.
Jalankan perintah berikut untuk melakukan curl layanan frontend dengan HTTP biasa dari Pod lain dalam namespace demo.
```
kubectl exec \
  $(kubectl get pod -l app=productcatalogservice -n demo -o jsonpath={.items..metadata.name}) \
  -c istio-proxy -n demo -- \
  curl http://frontend:80/ -o /dev/null -s -w '%{http_code}\n'
```
Permintaan Anda berhasil dengan status 200, karena secara default, traffic TLS dan teks biasa diterima.

Jika Anda memuat ulang halaman di Google Cloud Console yang menampilkan daftar Workloads, status mTLS akan ditampilkan sebagai Permissive.

Mengaktifkan TLS bersama per workload

Agar dapat menetapkan kebijakan PeerAuthentication untuk beban kerja tertentu, Anda harus mengonfigurasi bagian selector dan menentukan label yang cocok dengan beban kerja yang diinginkan. Namun, Anthos Service Mesh tidak dapat menggabungkan kebijakan tingkat workload untuk traffic mTLS keluar ke layanan. Anda perlu mengonfigurasi aturan tujuan untuk mengelola perilaku tersebut.

Terapkan kebijakan autentikasi ke beban kerja tertentu di namespace demo. Perhatikan bagaimana kebijakan berikut menggunakan label dan pemilih untuk menargetkan deployment frontend tertentu.

cat <<EOF | kubectl apply -n demo -f -
apiVersion: "security.istio.io/v1beta1"
kind: "PeerAuthentication"
metadata:
  name: "frontend"
  namespace: "demo"
spec:
  selector:
    matchLabels:
      app: frontend
  mtls:
    mode: STRICT
EOF

Output yang diharapkan:

peerauthentication.security.istio.io/frontend created

Konfigurasikan aturan tujuan yang cocok.

cat <<EOF | kubectl apply -n demo -f -
apiVersion: "networking.istio.io/v1alpha3"
kind: "DestinationRule"
metadata:
  name: "frontend"
spec:
  host: "frontend.demo.svc.cluster.local"
  trafficPolicy:
    tls:
      mode: ISTIO_MUTUAL
EOF

Output yang diharapkan:

destinationrule.networking.istio.io/frontend created

Akses Butik Online menggunakan alamat IP eksternal layanan frontend-external, lalu muat ulang halaman. Halaman tidak ditampilkan karena frontend service disetel ke mTLS STRICT, dan proxy file bantuan memblokir permintaan.
Jalankan perintah berikut untuk melakukan curl layanan frontend dengan HTTP biasa dari Pod lain dalam namespace demo.
```
kubectl exec \
  $(kubectl get pod -l app=productcatalogservice -n demo -o jsonpath={.items..metadata.name}) \
  -c istio-proxy -n demo -- \
  curl http://frontend:80/ -o /dev/null -s -w '%{http_code}\n'
```
Permintaan Anda gagal dengan kode status 56.

Jika Anda memuat ulang halaman di Google Cloud Console yang menampilkan daftar Workloads, sekarang status mTLS untuk layanan frontend adalah Strict dan semua layanan lainnya ditetapkan ke Permissive.

Hapus kebijakan autentikasi dan aturan tujuan:

kubectl delete peerauthentication -n demo frontend
kubectl delete destinationrule -n demo frontend

Menerapkan mTLS di seluruh mesh

Untuk mencegah semua layanan Anda di mesh menerima traffic teks biasa, tetapkan kebijakan PeerAuthentication di seluruh mesh dengan mode mTLS ditetapkan ke STRICT. Kebijakan PeerAuthentication seluruh mesh tidak boleh memiliki pemilih dan harus diterapkan di namespace root, istio-system. Saat Anda men-deploy kebijakan, bidang kontrol akan otomatis menyediakan sertifikat TLS sehingga beban kerja dapat saling melakukan autentikasi.

Terapkan mTLS di seluruh mesh:

kubectl apply -f - <<EOF
apiVersion: "security.istio.io/v1beta1"
kind: "PeerAuthentication"
metadata:
  name: "mesh-wide"
  namespace: "istio-system"
spec:
  mtls:
    mode: STRICT
EOF

Output yang diharapkan:

peerauthentication.security.istio.io/mesh-wide created

Akses Butik Online menggunakan alamat IP eksternal layanan frontend-external, lalu muat ulang halaman. Halaman tidak ditampilkan.

Jalankan perintah berikut untuk melakukan curl layanan frontend dengan HTTP biasa dari Pod lain dalam namespace demo.

kubectl exec \
  $(kubectl get pod -l app=productcatalogservice -n demo -o jsonpath={.items..metadata.name}) \
  -c istio-proxy -n demo -- \
  curl http://frontend:80/ -o /dev/null -s -w '%{http_code}\n'

Permintaan Anda gagal dengan kode status 56.

Hapus kebijakan mesh-wide:

kubectl delete peerauthentication -n istio-system mesh-wide

Jika memuat ulang halaman di Google Cloud Console, Anda akan melihat bahwa detail mTLS untuk semua layanan sekarang menampilkan Permissive.

Pembersihan

Agar tidak perlu membayar biaya pada akun Google Cloud Anda untuk resource yang digunakan dalam tutorial ini, hapus project yang berisi resource tersebut, atau simpan project dan hapus setiap resource.

Jika Anda ingin mencegah biaya tambahan, hapus cluster:

gcloud container clusters delete  CLUSTER_NAME  \
    --project=PROJECT_ID \
    --zone=CLUSTER_LOCATION

Jika Anda ingin mempertahankan cluster dan menghapus contoh Butik Online:
```
kubectl delete namespaces demo
```

Langkah selanjutnya

Untuk panduan umum tentang cara mengonfigurasi kebijakan PeerAuthentication, lihat Mengonfigurasi keamanan transport.