Ringkasan kebijakan otorisasi

Tidak seperti aplikasi monolitik yang mungkin berjalan di satu tempat, aplikasi microservice yang didistribusikan secara global melakukan panggilan melintasi batas jaringan. Ini berarti lebih banyak titik masuk ke aplikasi Anda, dan lebih banyak peluang terhadap serangan berbahaya. Dan karena pod Kubernetes memiliki IP sementara, aturan {i>firewall<i} berbasis IP tradisional tidak memadai untuk mengamankan akses antara sebagian besar workload standar dan berbasis cloud. Dalam arsitektur microservice, pendekatan baru terhadap keamanan diperlukan. Meningkatkan fitur keamanan seperti Akun layanan Kubernetes dan kebijakan keamanan Istio, Cloud Service Mesh menyediakan lebih banyak kemampuan untuk membantu Anda mengamankan menggunakan berbagai aplikasi obrolan.

Halaman ini memberikan ringkasan AuthorizationPolicy kepada operator aplikasi resource kustom (CR). Kebijakan otorisasi memungkinkan Anda mengaktifkan kontrol akses pada pada lapisan aplikasi (L7) dan transport (L3/4). Anda mengonfigurasi kebijakan otorisasi untuk menentukan perizinan—apa yang dimaksud dengan layanan atau yang diizinkan untuk dilakukan?

Kebijakan otorisasi

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

Cakupan kebijakan

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

  • 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 selector kolom tersebut.

    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 telah dijelaskan di bagian sebelumnya, ruang lingkup kebijakan dapat berupa seluruh mesh, namespace, atau beban kerja tertentu. Jika Anda menyertakannya, Kolom selector 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. Sebagai kejelasan, kami menyarankan agar Anda selalu menentukan tindakan. (Otorisasi kebijakan juga mendukung AUDIT dan CUSTOM actions.)

  • rules menentukan kapan harus memicu tindakan.

    • Kolom from di rules menentukan sumber permintaan.

    • Kolom to di rules menentukan operasi permintaan.

    • Kolom when menentukan kondisi yang diperlukan untuk menerapkan aturan tersebut.

Dalam contoh berikut:

  • Kebijakan ini diterapkan ke permintaan ke layanan frontend di 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 permintaan tertentu operasi 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 mengizinkan permintaan dari sebagian besar workload standar dan berbasis cloud. Jika Anda memiliki STRICT TLS bersama (mTLS) diaktifkan, Anda dapat membatasi akses berdasarkan identitas workload atau namespace yang permintaan berasal dari source bagian.

  • Gunakan kolom principals atau notPrincipal untuk mengontrol akses di pada tingkat workload Anda.

  • Gunakan kolom namespaces atau notNamespaces untuk mengontrol akses di pada level namespace.

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

Beban kerja yang diidentifikasi

Dalam contoh berikut, permintaan ke currencyservice hanya diizinkan dari layanan frontend. Permintaan ke currencyservice dari sumber lain workload 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 (Layanan CA) harus dalam format berikut:

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

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

Namespace yang diidentifikasi

Contoh berikut menunjukkan kebijakan yang menolak permintaan jika sumbernya tidak 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 pencocokan berikut skema:

  • 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 boleh kosong, gunakan format fieldname: ["*"]. Ini berbeda dengan meninggalkan kolom tidak ditentukan, yang berarti mencocokkan apa pun, termasuk yang 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 permintaan yang valid principals, yang berasal dari autentikasi JWT, jika jalur permintaan adalah bukan /healthz. Dengan demikian, kebijakan ini 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 otomatis mendeteksi jika server file bantuan. File bantuan klien mengirimkan mTLS ke workload dengan file bantuan dan mengirim teks biasa ke workload tanpa file bantuan. Untuk keamanan terbaik, sebaiknya bahwa Anda mengaktifkan STRICT mTLS.

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

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

Karena namespaces dan principals hanya dapat diekstrak dengan mTLS permintaan, kebijakan ini secara efektif menolak traffic teks polos 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 kecocokan yang tidak kosong, dan gunakan dengan notPrincipals berarti cocok dengan akun utama 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 {i>default<i} untuk memastikan bahwa kebijakan tersebut melakukan apa yang Anda inginkan. Diagram berikut menjelaskan kebijakan tersebut prioritas tinggi.

prioritas kebijakan otorisasi

Contoh kebijakan di bagian berikut menggambarkan beberapa kebijakan perilaku mereka dan situasi di mana Anda mungkin menganggapnya berguna.

Jangan izinkan apa pun

Contoh berikut menunjukkan kebijakan ALLOW yang tidak cocok dengan apa pun. Menurut 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 dengan memulai dari kebijakan {i>allow-nothing<i} 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 DENY kebijakan dievaluasi sebelum ALLOW kebijakan, semua permintaan 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 sebagian besar workload standar dan berbasis cloud.

Izinkan semua akses

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

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

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

Praktik terbaik

  1. Membuat akun layanan Kubernetes untuk setiap layanan, dan menentukan menggunakan 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
    ...

  2. Mulai dengan kebijakan izinkan apa pun dan secara bertahap menambahkan kebijakan ALLOW lainnya untuk membuka lebih banyak akses ke workload.

  3. 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: