Versi 1.20

Versi yang tersedia

1.20 (terbaru)
1.19
1.18
1.17
1.16
1.15
1.14
1.13
1.12
1.12

219}

Ringkasan kebijakan otorisasi

Tidak seperti aplikasi monolitik yang mungkin berjalan di satu tempat, aplikasi microservice yang didistribusikan secara global melakukan panggilan melintasi batas jaringan. Artinya, lebih banyak titik masuk ke aplikasi Anda, dan lebih banyak peluang untuk serangan berbahaya. Dan karena pod Kubernetes memiliki IP sementara, aturan firewall berbasis IP tradisional tidak memadai untuk mengamankan akses antara beban kerja. Dalam arsitektur microservice, pendekatan keamanan baru diperlukan. Dengan memanfaatkan fitur keamanan seperti akun layanan Kubernetes dan kebijakan keamanan Istio, Anthos Service Mesh memberikan kemampuan lebih banyak untuk membantu Anda mengamankan aplikasi Anda.

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

Kebijakan otorisasi

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

Cakupan kebijakan

Anda dapat menerapkan kebijakan ke seluruh mesh layanan, ke namespace, atau beban kerja individual.

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 pada beban kerja 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 beban kerja tertentu. Jika Anda menyertakannya, kolom selector akan menentukan target kebijakan.
Kolom action menentukan apakah permintaan akan ALLOW atau DENY. Jika Anda tidak menentukan tindakan, tindakan akan ditetapkan ke ALLOW secara default. Agar lebih jelas, sebaiknya selalu tentukan tindakan. (Kebijakan otorisasi juga mendukung tindakan AUDIT dan CUSTOM.)
rules menetapkan waktu untuk memicu tindakan.
- Kolom from di rules menentukan sumber permintaan.
- Kolom to di rules menentukan operations permintaan.
- Kolom when menentukan conditions tambahan yang diperlukan untuk menerapkan aturan.

Dalam contoh berikut:

Kebijakan ini diterapkan untuk permintaan ke layanan frontend dalam namespace demo.
Permintaan diizinkan jika "hello:world" ada di 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 pada rules. Pada contoh berikut, hanya metode HTTP GET dan POST yang diizinkan ke currencyservice dalam 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 tersebut mengizinkan permintaan dari beban kerja yang tidak diautentikasi. Jika mengaktifkan STRICT TLS bersama (mTLS), Anda dapat membatasi akses berdasarkan identitas beban kerja atau namespace tempat permintaan 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 mewajibkan Anda mengaktifkan STRICT mTLS. Jika Anda tidak dapat menetapkan mTLS STRICT, lihat Menolak permintaan teks biasa untuk solusi alternatif.

Beban kerja yang teridentifikasi

Pada 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 Anthos 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 adalah cluster.local.

Namespace teridentifikasi

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 pencocokan berikut:

Pencocokan persis: pencocokan string persis.
Pencocokan karakter pengganti menggunakan karakter pengganti "*":
- Pencocokan awalan: string dengan akhiran "*". Misalnya, "test.example.*" cocok dengan "test.example.com" atau "test.example.com.cn".
- Pencocokan akhiran: string dengan "*" awal. 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: ["*"]. Hal 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 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, Anthos Service Mesh mendukung pencocokan pengecualian. Contoh berikut memerlukan permintaan principals yang valid, yang berasal dari autentikasi JWT, jika jalur permintaan 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 Anthos Service Mesh 1.5 dan yang lebih baru, mTLS otomatis diaktifkan secara default. Dengan auto mTLS, proxy file bantuan klien otomatis mendeteksi apakah server memiliki file bantuan. Sidecar klien mengirimkan mTLS ke workload dengan sidecar dan mengirim teks biasa ke workload tanpa sidecar. Untuk keamanan terbaik, sebaiknya Anda mengaktifkan STRICT mTLS.

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

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

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

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 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 perlu memahami prioritas kebijakan dan perilaku default untuk memastikan kebijakan tersebut melakukan hal yang Anda inginkan. Diagram berikut menjelaskan prioritas kebijakan.

prioritas kebijakan otorisasi

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

Jangan izinkan

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 izinkan tidak ada dan menambahkan lebih banyak kebijakan ALLOW secara bertahap untuk membuka lebih banyak akses ke beban kerja.

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 beban kerja. Kebijakan izinkan semua 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 izinkan semua berguna jika Anda ingin mengekspos akses penuh untuk sementara ke beban kerja. Jika ada kebijakan DENY, permintaan tetap dapat ditolak karena kebijakan DENY dievaluasi sebelum kebijakan ALLOW.

Praktik terbaik

Buat akun layanan Kubernetes untuk setiap layanan, dan tentukan akun layanan 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 izinkan tidak ada dan tambahkan lebih banyak kebijakan ALLOW secara bertahap 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 izinkan tidak ada.
3. Tentukan kebijakan ALLOW untuk setiap beban kerja. Untuk mengetahui contohnya, lihat Token JWT.

Langkah selanjutnya

Pelajari fitur keamanan Anthos Service Mesh lebih lanjut:

Pelajari lebih lanjut kebijakan otorisasi dari dokumentasi Istio: