Ringkasan kebijakan otorisasi

Tidak seperti aplikasi monolitik yang mungkin berjalan di satu tempat, aplikasi microservice yang didistribusikan secara global melakukan panggilan di seluruh batas jaringan. Artinya, ada lebih banyak titik entri ke aplikasi Anda, dan lebih banyak peluang untuk serangan berbahaya. Selain itu, karena pod Kubernetes memiliki IP sementara, aturan firewall berbasis IP konvensional tidak memadai untuk mengamankan akses antar-workload. Dalam arsitektur microservice, diperlukan pendekatan baru untuk keamanan. Dengan memanfaatkan fitur keamanan seperti akun layanan Kubernetes dan kebijakan keamanan Istio, Cloud Service Mesh memberikan lebih banyak kemampuan untuk membantu Anda mengamankan aplikasi.

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

Kebijakan otorisasi

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

Lihat Fitur yang didukung untuk mengetahui detail kolom dari AuthorizationPolicy CR yang didukung oleh platform.

Cakupan kebijakan

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

  • Untuk menerapkan kebijakan di 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 a selector kolom.

    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 tindakan, tindakan akan ditetapkan ke ALLOW secara default. Untuk kejelasan, sebaiknya Anda selalu menentukan tindakan. (Kebijakan otorisasi juga mendukung AUDIT dan CUSTOM tindakan. Tindakan AUDIT hanya didukung di beberapa platform. Lihat Fitur yang didukung untuk mengetahui detailnya.)

  • The rules menentukan kapan tindakan akan dipicu.

    • Kolom from di rules menentukan sumber permintaan.

    • Kolom to di rules menentukan operasi permintaan.

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

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 di bagian rules. Dalam contoh berikut, hanya metode HTTP GET dan POST yang diizinkan untuk 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 yang diautentikasi

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

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

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

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

Workload yang diidentifikasi

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

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

Jika Anda menggunakan Cloud Service Mesh dalam cluster dengan CA Citadel, cluster.local adalah domain tepercaya. Dalam semua kasus lainnya, PROJECT_ID.svc.id.goog adalah domain tepercaya untuk mesh.

Domain tepercaya sesuai dengan root of trust sistem dan merupakan bagian dari Workload Identity. Cloud Service Mesh menggunakan domain tepercaya untuk membuat semua identitas dalam mesh. Misalnya, dalam ID SPIFFE spiffe://mytrustdomain.com/ns/default/sa/myname, substring mytrustdomain.com menentukan bahwa workload berasal dari domain tepercaya yang disebut mytrustdomain.com.

Saat menggunakan otoritas sertifikat Cloud Service Mesh, domain tepercaya akan otomatis dibuat oleh Cloud Service Mesh. Domain tepercaya didasarkan pada kumpulan workload cluster.

Anda dapat memiliki satu atau beberapa domain tepercaya dalam mesh multi-cluster, selama cluster berbagi root kepercayaan yang sama.

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 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 awalan "*". Misalnya, "*.example.com" cocok dengan "eng.example.com" atau "test.eng.example.com".
  • Pencocokan keberadaan: Untuk menentukan bahwa kolom harus ada dan tidak boleh kosong, gunakan format fieldname: ["*"]. Hal ini berbeda dengan membiarkan kolom tidak ditentukan, yang berarti cocok dengan 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, Cloud Service Mesh mendukung pencocokan pengecualian. Contoh berikut memerlukan principals permintaan yang valid, yang berasal dari autentikasi JWT, jika jalur permintaan 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, mTLS otomatis diaktifkan secara default. Dengan mTLS otomatis, proxy sidecar klien akan otomatis mendeteksi apakah server memiliki sidecar. Sidecar klien mengirimkan mTLS ke workload dengan sidecar dan mengirimkan teks biasa ke workload tanpa sidecar. Untuk keamanan terbaik, sebaiknya aktifkan mTLS STRICT.

Jika Anda tidak dapat mengaktifkan mTLS dengan mode STRICT untuk workload 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.

Kebijakan berikut menolak permintaan jika akun utama dalam permintaan kosong (yang merupakan kasus untuk permintaan teks biasa). Kebijakan ini mengizinkan permintaan jika akun utama tidak kosong. ["*"] berarti pencocokan yang tidak kosong, dan menggunakan dengan notPrincipals berarti pencocokan pada 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 terpisah, tetapi Anda harus memahami prioritas kebijakan dan perilaku default untuk memastikan bahwa kebijakan tersebut melakukan apa yang Anda inginkan. Diagram berikut menjelaskan prioritas kebijakan.

prioritas kebijakan otorisasi

Contoh kebijakan di bagian berikut mengilustrasikan beberapa perilaku default dan situasi saat Anda mungkin merasa berguna.

Tidak mengizinkan 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

Sebaiknya mulai dengan kebijakan tidak mengizinkan apa pun dan secara bertahap menambahkan lebih banyak kebijakan ALLOW untuk membuka lebih banyak akses ke workload.

Menolak 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 semua akses ke workload untuk sementara.

Mengizinkan semua akses

Contoh berikut menunjukkan kebijakan ALLOW yang cocok dengan semuanya, dan mengizinkan akses penuh ke workload. 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 ke workload untuk sementara. Jika ada kebijakan DENY, permintaan masih dapat ditolak karena kebijakan DENY dievaluasi sebelum kebijakan ALLOW.

Praktik terbaik

  1. Buat akun layanan Kubernetes untuk setiap layanan, dan tentukan akun layanan dalam 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 tidak mengizinkan apa pun dan secara bertahap tambahkan lebih banyak kebijakan ALLOW 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 tidak mengizinkan apa pun.

    3. Tentukan kebijakan ALLOW untuk setiap workload. Untuk contoh, lihat Token JWT.

Langkah berikutnya

Pelajari lebih lanjut fitur keamanan Cloud Service Mesh:

Pelajari lebih lanjut kebijakan otorisasi dari dokumentasi Istio: