Anda sedang melihat dokumentasi Service Mesh v1.21 lama.

Versi yang tersedia

Cloud Service Mesh
Arsip 1.21
arsip 1.20
Arsip 1.19
arsip 1.18

Halaman ini diterjemahkan oleh Cloud Translation API.

Ringkasan kebijakan otorisasi

Tidak seperti aplikasi monolitik yang mungkin berjalan di satu tempat, aplikasi microservice yang didistribusikan secara global akan melakukan panggilan melintasi batas jaringan. Artinya, lebih banyak titik masuk ke aplikasi Anda, dan lebih banyak peluang terjadinya serangan berbahaya. Karena pod Kubernetes memiliki IP sementara, aturan firewall berbasis IP tradisional tidak memadai untuk mengamankan akses antar-workload. Dalam arsitektur microservice, diperlukan pendekatan baru terkait keamanan. Dibangun dengan fitur keamanan seperti akun layanan Kubernetes dan kebijakan keamanan Istio, Cloud Service Mesh menyediakan lebih banyak kemampuan untuk membantu Anda mengamankan aplikasi.

Halaman ini memberikan ringkasan tentang resource kustom (CR) AuthorizationPolicy kepada operator aplikasi. Kebijakan otorisasi memungkinkan Anda mengaktifkan kontrol akses pada beban kerja di lapisan aplikasi (L7) dan transportasi (L3/4). Anda mengonfigurasi kebijakan otorisasi untuk menentukan izin—apa yang boleh dilakukan oleh layanan atau pengguna ini?

Kebijakan otorisasi

Permintaan antara layanan di mesh Anda (serta antara pengguna akhir dan layanan) diizinkan secara default. Anda menggunakan CR AuthorizationPolicy untuk menentukan kebijakan terperinci untuk workload Anda. Setelah Anda menerapkan kebijakan otorisasi, Cloud Service Mesh akan mendistribusikannya ke proxy file bantuan. Saat permintaan masuk ke beban kerja, proxy file bantuan memeriksa kebijakan otorisasi untuk menentukan apakah permintaan diizinkan atau ditolak.

Cakupan kebijakan

Anda dapat menerapkan kebijakan ke seluruh mesh layanan, ke namespace, atau setiap workload.

Untuk menerapkan kebijakan seluruh mesh, tentukan namespace root, istio-system, di kolom metadata:namespace:

apiVersion: "security.istio.io/v1beta1"
kind: "AuthorizationPolicy"
metadata:
  name: "mesh-wide"
  namespace: istio-system
spec:
...

Untuk menerapkan kebijakan ke namespace, tentukan namespace di kolom metadata:namespace:

apiVersion: "security.istio.io/v1beta1"
kind: "AuthorizationPolicy"
metadata:
  name: "currencyservice"
  namespace: currencyservice
spec:
...

Untuk membatasi kebijakan ke workload tertentu, sertakan kolom selector.

apiVersion: "security.istio.io/v1beta1"
kind: "AuthorizationPolicy"
metadata:
  name: "frontend"
  namespace: demo
spec:
  selector:
    matchLabels:
      app: frontend
   ...

Struktur dasar

Kebijakan otorisasi mencakup cakupan kebijakan, action, dan daftar rules:

Seperti yang dijelaskan di bagian sebelumnya, cakupan kebijakan dapat berupa seluruh mesh, namespace, atau workload tertentu. Jika Anda menyertakannya, kolom selector akan menentukan target kebijakan.
Kolom action menentukan apakah akan ALLOW atau DENY permintaan. Jika Anda tidak menentukan suatu tindakan, secara default, tindakan tersebut akan ditetapkan ke ALLOW. Agar jelas, sebaiknya selalu tentukan tindakan. (Kebijakan otorisasi juga mendukung tindakan AUDIT dan CUSTOM.)
rules menentukan kapan tindakan memicu tindakan.
- Kolom from dalam rules menentukan sumber permintaan.
- Kolom to dalam rules menentukan operations permintaan.
- Kolom when menentukan conditions tambahan yang diperlukan untuk menerapkan aturan.

Dalam contoh berikut:

Kebijakan ini diterapkan pada permintaan ke layanan frontend di namespace demo.
Permintaan diizinkan jika "hello:world" berada dalam header permintaan; jika tidak, permintaan akan ditolak.

apiVersion: "security.istio.io/v1beta1"
kind: "AuthorizationPolicy"
metadata:
  name: "hello-world"
  namespace: demo
spec:
  selector:
    matchLabels:
      app: frontend
  action: ALLOW
  rules:
  - when:
    - key: request.headers[hello]
      values: ["world"]

Kontrol akses pada operasi permintaan

Anda dapat mengontrol akses ke operations permintaan tertentu, seperti metode HTTP atau port TCP dengan menambahkan bagian to di bagian rules. Pada contoh berikut, hanya metode HTTP GET dan POST yang diizinkan ke currencyservice di namespace demo.

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
 name: currencyservice
 namespace: demo
spec:
 selector:
   matchLabels:
     app: currencyservice
 action: ALLOW
 rules:
 - to:
   - operation:
       methods: ["GET", "POST"]

Kontrol akses pada identitas terautentikasi

Pada contoh sebelumnya, kebijakan mengizinkan permintaan dari beban kerja yang tidak diautentikasi. Jika mengaktifkan STRICT TLS bersama (mTLS), Anda dapat membatasi akses berdasarkan identitas workload atau namespace tempat permintaan tersebut berasal di bagian source.

Gunakan kolom principals atau notPrincipal untuk mengontrol akses di tingkat beban kerja.
Gunakan kolom namespaces atau notNamespaces untuk mengontrol akses di tingkat namespace.

Semua kolom di atas mengharuskan Anda mengaktifkan STRICT mTLS. Jika Anda tidak dapat menetapkan mTLS STRICT, lihat Menolak permintaan teks biasa untuk solusi alternatif.

Beban kerja yang diidentifikasi

Dalam contoh berikut, permintaan ke currencyservice hanya diizinkan dari layanan frontend. Permintaan ke currencyservice dari beban kerja lain ditolak.

apiVersion: "security.istio.io/v1beta1"
kind: "AuthorizationPolicy"
metadata:
  name: "currencyservice"
  namespace: demo
spec:
  selector:
    matchLabels:
      app: currencyservice
  action: ALLOW
  rules:
  - from:
    - source:
        principals: ["example-project-1234.svc.id.goog/ns/demo/sa/frontend-sa"]

Untuk menentukan akun layanan, principals untuk certificate authority Cloud Service Mesh (Mesh CA) dan Certificate Authority Service (CA Service) harus dalam format berikut:

principals: ["PROJECT_ID.svc.id.goog/ns/NAMESPACE/sa/SERVICE_ACCOUNT_NAME"]

PROJECT_ID.svc.id.goog adalah domain kepercayaan untuk Mesh CA. Jika Anda menggunakan Istio CA (sebelumnya dikenal sebagai Citadel), domain kepercayaan default-nya adalah cluster.local.

Namespace yang diidentifikasi

Contoh berikut menunjukkan kebijakan yang menolak permintaan jika sumbernya bukan namespace foo:

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
 name: httpbin-deny
 namespace: foo
spec:
 selector:
   matchLabels:
     app: httpbin
     version: v1
 action: DENY
 rules:
 - from:
   - source:
       notNamespaces: ["foo"]

Pencocokan nilai

Sebagian besar kolom dalam kebijakan otorisasi mendukung semua skema yang cocok berikut:

Pencocokan persis: pencocokan string persis.
Pencocokan karakter pengganti menggunakan karakter pengganti "*":
- Awalan cocok: string dengan akhiran "*". Misalnya, "test.example.*" cocok dengan "test.example.com" atau "test.example.com.cn".
- Pencocokan akhiran: string dengan awalan "*". Misalnya, "*.example.com" cocok dengan "eng.example.com" atau "test.eng.example.com".
Pencocokan kehadiran: Untuk menentukan bahwa kolom harus ada dan tidak kosong, gunakan format fieldname: ["*"]. Ini berbeda dengan membiarkan kolom tidak ditentukan, yang berarti mencocokkan apa pun, termasuk kosong.

Ada beberapa pengecualian. Misalnya, kolom berikut hanya mendukung pencocokan persis:

Kolom key di bagian when
ipBlocks di bawah bagian source
Kolom ports di bagian to

Contoh kebijakan berikut mengizinkan akses di jalur dengan awalan /test/* atau akhiran */info:

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: tester
  namespace: default
spec:
  selector:
    matchLabels:
      app: products
  action: ALLOW
  rules:
  - to:
    - operation:
        paths: ["/test/*", "*/info"]

Pencocokan pengecualian

Untuk mencocokkan kondisi negatif seperti notValues di kolom when, notIpBlocks di kolom source, notPorts di kolom to, Cloud Service Mesh mendukung pencocokan pengecualian. Contoh berikut memerlukan principals permintaan yang valid, yang berasal dari autentikasi JWT, jika jalur permintaannya bukan /healthz. Dengan demikian, kebijakan ini akan mengecualikan permintaan ke jalur /healthz dari autentikasi JWT:

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: disable-jwt-for-healthz
  namespace: default
spec:
  selector:
    matchLabels:
      app: products
  action: ALLOW
  rules:
  - to:
    - operation:
        notPaths: ["/healthz"]
    from:
    - source:
        requestPrincipals: ["*"]

Menolak permintaan teks biasa

Di Cloud Service Mesh 1.5 dan yang lebih baru, mTLS otomatis diaktifkan secara default. Dengan mTLS otomatis, proxy file bantuan klien akan otomatis mendeteksi apakah server memiliki file bantuan. File bantuan klien mengirimkan mTLS ke workload dengan file bantuan dan mengirimkan teks biasa ke workload tanpa file bantuan. Untuk keamanan terbaik, sebaiknya aktifkan STRICT mTLS.

Jika tidak dapat mengaktifkan mTLS dengan mode STRICT untuk workload atau namespace, Anda dapat:

buat kebijakan otorisasi untuk secara eksplisit mengizinkan traffic dengan namespaces yang tidak kosong atau principals yang tidak kosong, atau
tolak traffic dengan namespaces atau principals kosong.

Karena namespaces dan principals hanya dapat diekstrak dengan permintaan mTLS, kebijakan ini secara efektif menolak traffic teks biasa.

Kebijakan berikut menolak permintaan jika akun utama dalam permintaan kosong (yang berlaku untuk permintaan teks biasa). Kebijakan ini mengizinkan permintaan jika akun utama tidak kosong. ["*"] berarti pencocokan yang tidak kosong, dan menggunakan notPrincipals berarti mencocokkan pada akun utama yang kosong.

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: require-mtls
  namespace: NAMESPACE
spec:
  action: DENY
  rules:
  - from:
    - source:
        notPrincipals: ["*"]

Prioritas kebijakan otorisasi

Anda dapat mengonfigurasi kebijakan otorisasi ALLOW dan DENY yang terpisah, tetapi Anda harus memahami prioritas kebijakan dan perilaku default untuk memastikan bahwa kebijakan tersebut berfungsi sesuai keinginan Anda. Diagram berikut menjelaskan prioritas kebijakan.

prioritas kebijakan otorisasi

Contoh kebijakan di bagian berikut menggambarkan beberapa perilaku default dan situasi yang mungkin berguna bagi Anda.

Jangan izinkan apa pun

Contoh berikut menunjukkan kebijakan ALLOW yang tidak cocok dengan apa pun. Secara default, jika tidak ada kebijakan ALLOW lain, permintaan akan selalu ditolak.

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: allow-nothing
spec:
  action: ALLOW

Praktik keamanan yang baik adalah memulai dengan kebijakan yang mengizinkan apa pun dan secara bertahap menambahkan lebih banyak kebijakan ALLOW untuk membuka lebih banyak akses ke workload.

Tolak semua akses

Contoh berikut menunjukkan kebijakan DENY yang cocok dengan semuanya. Karena kebijakan DENY dievaluasi sebelum kebijakan ALLOW, semua permintaan akan ditolak meskipun ada kebijakan ALLOW yang cocok dengan permintaan tersebut.

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: deny-all
spec:
  action: DENY
  rules:
  - {}

Kebijakan tolak semua berguna jika Anda ingin menonaktifkan sementara semua akses ke beban kerja.

Izinkan semua akses

Contoh berikut menunjukkan kebijakan ALLOW yang cocok dengan semuanya, dan memungkinkan akses penuh ke workload. Kebijakan allow-all membuat kebijakan ALLOW lainnya tidak berguna karena selalu mengizinkan permintaan.

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: allow-all
spec:
  action: ALLOW
  rules:
  - {}

Kebijakan allow-all berguna jika Anda ingin mengekspos akses penuh ke beban kerja untuk sementara. Jika ada kebijakan DENY, permintaan tetap dapat ditolak karena kebijakan DENY dievaluasi sebelum kebijakan ALLOW.

Praktik terbaik

Membuat akun layanan Kubernetes untuk setiap layanan, dan menentukan akun layanan tersebut di Deployment. Contoh:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: frontend-sa
  namespace: demo
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: frontend
  namespace:demo
spec:
  selector:
    matchLabels:
      app: frontend
  template:
    metadata:
      labels:
        app: frontend
    spec:
      serviceAccountName: frontend-sa
    ...

Mulai dengan kebijakan yang tidak mengizinkan dan secara bertahap tambahkan lebih banyak kebijakan ALLOW untuk membuka lebih banyak akses ke workload.
Jika Anda menggunakan JWT untuk layanan Anda:
1. Buat kebijakan DENY untuk memblokir permintaan yang tidak diautentikasi, misalnya:
```
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: requireJWT
  namespace: admin
spec:
  action: DENY
  rules:
  -  from:
    - source:
        notRequestPrincipals: ["*"]
```
2. Terapkan kebijakan yang tidak diizinkan.
3. Tentukan ALLOW kebijakan untuk setiap workload. Untuk contoh, lihat Token JWT.

Langkah selanjutnya

Pelajari fitur keamanan Cloud Service Mesh lebih lanjut:

Pelajari lebih lanjut kebijakan otorisasi dari dokumentasi Istio: