Istio Authorization Policy: Pengertian, Cara Kerja, Arsitektur, Komponen, Fungsi, Manfaat, Kelebihan, Kekurangan, dan Implementasinya | Dewa234

Istio Authorization Policy: Pengertian, Cara Kerja, Arsitektur, Komponen, Fungsi, Manfaat, Kelebihan, Kekurangan, dan Implementasinya

Ilustrasi Istio Authorization Policy untuk mengatur akses antar microservices

Istio Authorization Policy merupakan salah satu fitur keamanan penting dalam Istio Service Mesh yang digunakan untuk mengatur hak akses terhadap workload dan komunikasi antar-service. Dengan Authorization Policy, administrator dapat menentukan request mana yang diperbolehkan, request mana yang ditolak, serta kondisi apa saja yang harus dipenuhi sebelum sebuah service dapat mengakses service lainnya.

Pada arsitektur microservices, aplikasi biasanya tidak lagi berjalan sebagai satu kesatuan aplikasi monolitik. Sebuah aplikasi dapat terdiri dari puluhan bahkan ratusan service yang saling berkomunikasi melalui jaringan. Kondisi tersebut memberikan fleksibilitas dalam pengembangan aplikasi Dewa234, tetapi sekaligus meningkatkan kebutuhan terhadap kontrol akses dan keamanan komunikasi.

Tidak semua service seharusnya dapat mengakses service lainnya. Service frontend mungkin hanya perlu mengakses API tertentu, sedangkan service pembayaran mungkin hanya boleh diakses oleh service order. Jika seluruh service dapat berkomunikasi tanpa pembatasan, risiko akses yang tidak diperlukan akan semakin besar.

Istio Authorization Policy menyediakan mekanisme policy-based access control untuk mengatasi kebutuhan tersebut. Kebijakan dapat diterapkan pada tingkat mesh, namespace, maupun workload sehingga pengaturan akses dapat dibuat lebih terstruktur dan konsisten. Istio menjalankan enforcement authorization pada proxy di sisi server, sehingga keputusan akses dapat dibuat sebelum request diteruskan ke aplikasi. :contentReference[oaicite:1]{index=1}

Apa Itu Istio Authorization Policy?

Istio Authorization Policy adalah mekanisme kontrol akses yang digunakan oleh Istio untuk menentukan apakah sebuah request menuju workload diperbolehkan atau ditolak berdasarkan policy yang telah dikonfigurasi.

Authorization berfokus pada hak akses. Dengan kata sederhana, authentication menjawab pertanyaan "siapa kamu?", sedangkan authorization menjawab pertanyaan "apa yang boleh kamu lakukan?".

Client
   |
   v
Authentication
   |
   v
Authorization Policy
   |
   +---- ALLOW
   |
   +---- DENY
   |
   v
Target Service

Authorization Policy dapat menggunakan berbagai atribut request untuk membuat keputusan, termasuk sumber request, tujuan operasi, method HTTP, path, port, identitas workload, namespace, request principal, dan kondisi lainnya.

Dalam Istio, Authorization Policy direpresentasikan sebagai custom resource Kubernetes dengan jenis AuthorizationPolicy. Policy tersebut kemudian digunakan oleh komponen data plane untuk melakukan enforcement terhadap traffic yang masuk ke workload.

Mengapa Istio Authorization Policy Dibutuhkan?

Dalam lingkungan microservices, komunikasi antar-service biasanya sangat kompleks. Satu service dapat bergantung pada beberapa service lainnya, sementara setiap service memiliki kebutuhan akses yang berbeda.

Frontend
   |
   v
API Gateway
   |
   +---- User Service
   |
   +---- Order Service
   |
   +---- Payment Service
   |
   +---- Inventory Service

Sebagai contoh, Order Service mungkin membutuhkan akses ke Payment Service, tetapi Inventory Service tidak membutuhkan akses langsung ke Payment Service.

Tanpa kontrol akses, semua jalur komunikasi yang tersedia dapat menjadi potensi risiko. Authorization Policy membantu membatasi jalur tersebut berdasarkan kebutuhan aplikasi.

Pendekatan ini juga mendukung prinsip least privilege, yaitu setiap workload hanya mendapatkan akses yang memang diperlukan untuk menjalankan fungsinya.

Perbedaan Authentication dan Authorization

Aspek	Authentication	Authorization
Fokus	Identitas	Hak akses
Pertanyaan	Siapa yang melakukan request?	Apa yang boleh dilakukan?
Contoh	Validasi JWT atau identitas workload	Mengizinkan GET ke endpoint tertentu
Istio	RequestAuthentication dan PeerAuthentication	AuthorizationPolicy

Kedua mekanisme tersebut dapat digunakan secara bersamaan. Authentication dapat memberikan informasi mengenai identitas request, kemudian Authorization Policy menggunakan informasi tersebut untuk menentukan hak akses.

Cara Kerja Istio Authorization Policy

Istio Authorization Policy bekerja pada jalur traffic yang masuk ke workload. Pada arsitektur sidecar, Envoy Proxy yang berada di depan aplikasi menjalankan authorization engine untuk mengevaluasi request berdasarkan policy yang berlaku. :contentReference[oaicite:2]{index=2}

Client
   |
   v
Envoy Proxy
   |
   v
Authorization Engine
   |
   +---- Evaluate Policy
   |
   +---- ALLOW
   |
   +---- DENY
   |
   v
Application

Ketika request datang, proxy memeriksa konteks request kemudian mencocokkannya dengan policy. Jika request memenuhi aturan yang mengizinkan akses, request dapat diteruskan ke aplikasi. Jika request ditolak oleh policy, request tidak diteruskan ke workload.

Pendekatan tersebut memungkinkan enforcement dilakukan pada lapisan service mesh sehingga business logic aplikasi tidak harus menangani seluruh aturan komunikasi antar-service.

Arsitektur Istio Authorization Policy

Secara sederhana, arsitektur Authorization Policy dapat dibagi menjadi control plane dan data plane.

                 Istio Control Plane
                         |
                         v
                Policy Configuration
                         |
                         v
                 Istio Data Plane
                         |
                +--------+--------+
                |                 |
                v                 v
          Envoy Proxy       Envoy Proxy
                |                 |
                v                 v
           Service A          Service B

Control plane menangani konfigurasi dan distribusi policy. Sementara itu, proxy pada data plane menjalankan enforcement terhadap traffic yang masuk.

Dalam arsitektur sidecar, setiap workload yang menggunakan proxy dapat memperoleh enforcement authorization pada traffic inbound. Istio juga memiliki arsitektur data plane lain seperti ambient mode, sehingga penerapan policy perlu disesuaikan dengan mode data plane dan target policy yang digunakan.

Komponen Istio Authorization Policy

Sebuah AuthorizationPolicy memiliki beberapa bagian penting yang menentukan target dan aturan akses.

Komponen	Fungsi
selector	Menentukan workload yang menjadi target policy.
targetRefs	Menentukan resource tertentu yang menjadi target policy pada skenario yang didukung.
action	Menentukan tindakan policy seperti ALLOW, DENY, AUDIT, atau CUSTOM.
rules	Menentukan kondisi yang memicu policy.
from	Menentukan sumber request.
to	Menentukan operation atau tujuan request.
when	Menentukan kondisi tambahan berdasarkan atribut tertentu.

Istio mendokumentasikan AuthorizationPolicy sebagai resource untuk access control pada workload. `selector` digunakan untuk menentukan target workload, sedangkan `rules` dapat berisi `from`, `to`, dan `when`. Pada konfigurasi tertentu, `targetRefs` dapat digunakan sebagai mekanisme target resource. :contentReference[oaicite:3]{index=3}

Selector pada Istio Authorization Policy

Selector digunakan untuk memilih workload yang akan menerima sebuah policy.

Contohnya, sebuah workload memiliki label:

app: payment

Policy dapat menggunakan selector tersebut untuk menargetkan Payment Service.

spec:
  selector:
    matchLabels:
      app: payment

Selector pada AuthorizationPolicy akan mencocokkan workload dalam namespace yang sesuai. Jika policy berada pada root namespace, cakupannya dapat mencakup workload di namespace lain sesuai aturan Istio. :contentReference[oaicite:4]{index=4}

TargetRefs pada Authorization Policy

Selain selector, versi Istio modern juga menyediakan mekanisme targetRefs untuk menargetkan resource tertentu dalam skenario yang didukung.

Pendekatan tersebut terutama relevan ketika policy digunakan bersama resource Gateway API dan arsitektur ambient tertentu.

AuthorizationPolicy
        |
        v
    targetRefs
        |
        +---- Gateway
        |
        +---- GatewayClass
        |
        v
Target Resource

Selector dan targetRefs tidak digunakan secara bersamaan dalam satu policy. Dokumentasi referensi Istio menjelaskan bahwa paling banyak salah satu dari keduanya digunakan pada sebuah policy. :contentReference[oaicite:5]{index=5}

Action pada Istio Authorization Policy

Authorization Policy menyediakan beberapa action untuk menentukan bagaimana request diperlakukan.

1. ALLOW

ALLOW digunakan untuk mengizinkan request yang memenuhi rules. Action ini merupakan salah satu mekanisme utama untuk membuat daftar akses yang diperbolehkan.

2. DENY

DENY digunakan untuk menolak request yang memenuhi rules tertentu. DENY memiliki prioritas lebih tinggi daripada ALLOW ketika keduanya berlaku pada workload yang sama. :contentReference[oaicite:6]{index=6}

3. AUDIT

AUDIT digunakan untuk menandai request yang cocok dengan policy untuk kebutuhan audit. AUDIT tidak secara langsung menentukan apakah request diizinkan atau ditolak; keputusan enforcement tetap bergantung pada action authorization lainnya. :contentReference[oaicite:7]{index=7}

4. CUSTOM

CUSTOM digunakan untuk mendelegasikan keputusan authorization tertentu kepada extension provider eksternal yang dikonfigurasi dalam Istio. Action ini dapat digunakan untuk mengintegrasikan mekanisme external authorization. :contentReference[oaicite:8]{index=8}

Urutan Evaluasi Authorization Policy

Ketika beberapa jenis action digunakan pada workload yang sama, Istio mengevaluasi policy dengan urutan tertentu.

CUSTOM
   |
   v
DENY
   |
   v
ALLOW
   |
   v
Authorization Result

Secara umum, policy CUSTOM dievaluasi terlebih dahulu, kemudian DENY, dan setelah itu ALLOW. Jika ada policy DENY yang cocok dengan request, request akan ditolak. Jika tidak terdapat policy ALLOW pada workload, request dapat diizinkan setelah melewati pemeriksaan yang relevan. Jika terdapat policy ALLOW, request harus cocok dengan setidaknya salah satu policy ALLOW yang berlaku. :contentReference[oaicite:9]{index=9}

Pemahaman mengenai precedence ini sangat penting karena beberapa AuthorizationPolicy dapat diterapkan secara bersamaan dan hasil akhirnya bergantung pada kombinasi policy yang aktif.

Rules pada Istio Authorization Policy

Bagian rules menentukan kondisi kapan sebuah action diterapkan.

rules
 |
 +---- from
 |
 +---- to
 |
 +---- when

Rule dapat digunakan untuk membatasi sumber request, operation tujuan, maupun kondisi tambahan.

Dengan menggabungkan beberapa bagian tersebut, administrator dapat membuat policy yang lebih spesifik daripada sekadar mengizinkan atau menolak seluruh traffic.

From pada Authorization Policy

Bagian from digunakan untuk menentukan sumber request.

Sumber dapat berkaitan dengan identitas workload, namespace, service account, IP, atau informasi sumber lainnya yang didukung oleh Istio.

Service A
    |
    | Request
    v
Service B
    |
    v
Authorization Policy
    |
    +---- Source Match

Sebagai contoh, administrator dapat membuat aturan yang hanya memperbolehkan Service Account tertentu mengakses service tujuan.

To pada Authorization Policy

Bagian to digunakan untuk menentukan operation yang menjadi target policy.

Untuk traffic HTTP, administrator dapat menggunakan method, path, host, dan atribut operation lainnya yang didukung.

Request
   |
   +---- GET
   |
   +---- /api/users
   |
   +---- Port 8080
   |
   v
Authorization Rule

Dengan cara tersebut, akses dapat dibuat lebih granular. Misalnya, service tertentu boleh melakukan GET terhadap endpoint tertentu tetapi tidak boleh melakukan DELETE.

When pada Authorization Policy

Bagian when digunakan untuk menambahkan kondisi berdasarkan atribut request atau metadata tertentu.

Request
   |
   +---- Source
   |
   +---- Operation
   |
   +---- Attribute
   |
   v
WHEN Condition
   |
   v
Authorization Decision

Kondisi tambahan dapat digunakan untuk membuat aturan yang lebih spesifik tanpa harus membuat policy yang terlalu luas.

Contoh Istio Authorization Policy Sederhana

Berikut contoh AuthorizationPolicy yang mengizinkan request GET menuju workload dengan label app: product.

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: product-read
  namespace: default
spec:
  selector:
    matchLabels:
      app: product
  action: ALLOW
  rules:
  - to:
    - operation:
        methods:
        - GET

Policy tersebut menargetkan workload dengan label app: product dan membuat aturan ALLOW untuk method GET.

Contoh ini merupakan pola dasar. Pada deployment nyata, rule sebaiknya disesuaikan dengan source, path, namespace, service account, dan kebutuhan keamanan aplikasi.

Contoh Authorization Policy Berdasarkan Source

Salah satu kebutuhan umum adalah membatasi service mana yang boleh mengakses service lainnya.

Frontend
   |
   | ALLOW
   v
API Service
   ^
   |
   X
Unknown Service

Secara konsep, policy dapat membatasi source berdasarkan namespace atau service account.

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: allow-frontend
  namespace: default
spec:
  selector:
    matchLabels:
      app: api
  action: ALLOW
  rules:
  - from:
    - source:
        namespaces:
        - frontend

Dengan pola tersebut, hanya source dari namespace yang ditentukan yang dapat memenuhi rule ALLOW tersebut.

Contoh Authorization Policy Berdasarkan HTTP Method

Authorization Policy juga dapat digunakan untuk membatasi method HTTP.

GET      ---> ALLOW
POST     ---> ALLOW
PUT      ---> RESTRICTED
DELETE   ---> RESTRICTED

Contohnya, service tertentu mungkin hanya membutuhkan akses baca sehingga hanya method GET yang diberikan.

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: read-only-api
spec:
  selector:
    matchLabels:
      app: api
  action: ALLOW
  rules:
  - to:
    - operation:
        methods:
        - GET

Dengan model seperti ini, operasi yang tidak termasuk dalam policy ALLOW tidak otomatis mendapatkan akses ketika workload telah memiliki policy ALLOW yang membatasi akses.

Istio Authorization Policy dan JWT

Authorization Policy dapat digunakan bersama validasi JWT. RequestAuthentication dapat digunakan untuk memvalidasi token, kemudian informasi identitas dari token tersebut dapat digunakan oleh AuthorizationPolicy.

Client
   |
   v
JWT Token
   |
   v
RequestAuthentication
   |
   v
Authenticated Identity
   |
   v
AuthorizationPolicy
   |
   v
ALLOW / DENY

Istio mendukung penggunaan request principals dalam Authorization Policy untuk membuat kontrol akses berbasis identitas JWT yang telah tervalidasi. :contentReference[oaicite:10]{index=10}

Istio Authorization Policy dan mTLS

Authorization Policy juga dapat digunakan bersama PeerAuthentication dan mutual TLS.

Service A
   |
   | mTLS
   v
Service B
   |
   v
Authorization Policy
   |
   v
Access Decision

mTLS membantu menyediakan authentication pada komunikasi workload, sedangkan authorization menentukan apakah workload tersebut memiliki hak untuk melakukan akses tertentu.

Karena mTLS dan authorization menyelesaikan masalah yang berbeda, penggunaan mTLS saja tidak berarti semua akses sudah terotorisasi. Dokumentasi best practice Istio juga menekankan bahwa mTLS menyediakan authentication, sementara authorization diperlukan untuk kontrol akses yang lebih granular. :contentReference[oaicite:11]{index=11}

Istio Authorization Policy untuk Zero Trust

Authorization Policy dapat menjadi salah satu bagian dari pendekatan Zero Trust. Dalam konsep tersebut, akses tidak semata-mata dipercaya hanya karena request berasal dari jaringan internal.

Request
   |
   v
Identity
   |
   v
Policy Evaluation
   |
   +---- Allowed
   |
   +---- Denied
   |
   v
Resource

Setiap komunikasi dapat dievaluasi berdasarkan identitas dan atribut yang relevan sehingga akses diberikan berdasarkan kebutuhan, bukan hanya berdasarkan lokasi jaringan.

Default Deny pada Istio Authorization Policy

Salah satu pola keamanan yang direkomendasikan adalah default-deny. Dalam pola ini, akses tidak diberikan secara luas terlebih dahulu. Administrator kemudian membuat policy ALLOW secara eksplisit untuk traffic yang memang dibutuhkan.

Default
   |
   v
DENY
   |
   +---- Service A ---> ALLOW
   |
   +---- Service B ---> ALLOW
   |
   +---- Unknown ----> DENY

Pendekatan default-deny membantu mengurangi risiko akses yang tidak sengaja terbuka. Dokumentasi security best practices Istio merekomendasikan pola default-deny karena kesalahan konfigurasi cenderung menghasilkan penolakan yang terlihat daripada akses yang tidak sengaja terbuka. :contentReference[oaicite:12]{index=12}

Contoh policy sederhana untuk membuat kondisi deny secara eksplisit:

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: allow-nothing
spec: {}

Policy tersebut dapat digunakan sebagai bagian dari strategi default-deny, kemudian policy ALLOW yang lebih spesifik dapat ditambahkan sesuai kebutuhan.

Positive Matching pada Authorization Policy

Istio juga merekomendasikan pola ALLOW-with-positive-matching ketika memungkinkan. Artinya, policy ALLOW sebaiknya secara eksplisit menyebutkan kondisi yang memang diizinkan.

ALLOW
 |
 +---- /public
 |
 +---- GET
 |
 v
Allowed

Pendekatan ini lebih mudah dipahami dan dapat mengurangi risiko akibat interpretasi kondisi negatif yang tidak sesuai harapan. :contentReference[oaicite:13]{index=13}

Istio Authorization Policy dan Path Normalization

Ketika Authorization Policy digunakan untuk membatasi path HTTP, administrator perlu memahami bagaimana path diproses oleh proxy dan aplikasi.

Perbedaan interpretasi path antara proxy dan aplikasi dapat menimbulkan policy mismatch. Dalam kondisi tertentu, mismatch dapat menyebabkan request yang seharusnya ditolak menjadi diterima atau sebaliknya.

Karena itu, konfigurasi path normalization perlu diperhatikan ketika policy menggunakan path sebagai salah satu dasar keputusan authorization. Istio menyediakan dokumentasi khusus mengenai normalisasi path dan merekomendasikan konfigurasi yang disesuaikan dengan kebutuhan sistem. :contentReference[oaicite:14]{index=14}

Istio Authorization Policy pada Kubernetes

Istio Authorization Policy sangat relevan untuk Kubernetes karena policy dapat didefinisikan sebagai resource Kubernetes.

Kubernetes Cluster
       |
       v
Istio Service Mesh
       |
   +---+---+
   |       |
   v       v
Service A Service B
   |       |
 Proxy    Proxy
   |       |
   +---+---+
       |
       v
AuthorizationPolicy

Policy dapat dikelola menggunakan workflow Kubernetes seperti manifest YAML, GitOps, atau sistem deployment lainnya.

Pendekatan tersebut membuat konfigurasi keamanan dapat diperlakukan sebagai bagian dari konfigurasi infrastructure dan application delivery.

Fungsi Istio Authorization Policy

Mengatur akses terhadap workload.
Membatasi komunikasi antar-service.
Mengizinkan request berdasarkan kondisi tertentu.
Menolak request yang tidak memenuhi policy.
Membatasi akses berdasarkan source.
Membatasi operation HTTP.
Membatasi akses berdasarkan path atau host.
Mendukung kontrol berbasis identitas.
Mendukung prinsip least privilege.
Mendukung implementasi Zero Trust.
Membantu memusatkan kontrol authorization pada service mesh.

Manfaat Istio Authorization Policy

Meningkatkan keamanan komunikasi antar-service.
Mengurangi akses yang tidak diperlukan.
Membantu membatasi lateral movement.
Mendukung least privilege.
Menyediakan kontrol akses yang konsisten.
Membantu mengurangi kebutuhan authorization pada setiap aplikasi.
Mendukung microservices berskala besar.
Membantu proses audit dan pengelolaan keamanan.
Dapat dikombinasikan dengan authentication dan mTLS.
Mendukung kontrol akses yang lebih granular.

Kelebihan Istio Authorization Policy

Terintegrasi langsung dengan Istio Service Mesh.
Mendukung kontrol akses pada workload.
Mendukung ALLOW dan DENY.
Mendukung AUDIT dan CUSTOM untuk skenario tertentu.
Dapat menggunakan source dan operation sebagai kondisi.
Dapat dikombinasikan dengan JWT.
Dapat dikombinasikan dengan mTLS.
Mendukung pendekatan least privilege.
Dapat dikelola sebagai konfigurasi deklaratif.
Cocok untuk arsitektur microservices.

Kekurangan Istio Authorization Policy

Menambah kompleksitas pengelolaan service mesh.
Membutuhkan pemahaman mengenai policy precedence.
Kesalahan konfigurasi dapat menyebabkan request ditolak.
Policy yang terlalu kompleks dapat sulit dipelihara.
Debugging membutuhkan pemahaman mengenai alur traffic.
Perubahan policy dapat memengaruhi banyak workload.
Administrasi Istio sendiri membutuhkan kompetensi teknis.

Istio Authorization Policy dan Service-to-Service Security

Salah satu penggunaan utama Authorization Policy adalah mengamankan komunikasi antar-service.

Frontend
   |
   v
Order Service
   |
   v
Payment Service
   |
   v
Payment Database

Administrator dapat menentukan bahwa Order Service boleh mengakses Payment Service, sedangkan service lain tidak diberikan izin kecuali memang diperlukan.

Dengan demikian, komunikasi dalam mesh tidak harus bersifat terbuka. Setiap jalur komunikasi dapat diberikan izin sesuai kebutuhan.

Istio Authorization Policy untuk API

API merupakan salah satu area yang paling sering membutuhkan authorization.

Client
   |
   v
API Gateway
   |
   v
API Service
   |
   +---- GET /users
   |
   +---- POST /users
   |
   +---- DELETE /users

Authorization Policy dapat digunakan untuk membedakan akses terhadap operation tersebut.

Misalnya, service tertentu hanya membutuhkan akses membaca data sehingga hanya endpoint GET yang diperbolehkan.

Istio Authorization Policy untuk Namespace Isolation

Namespace dapat digunakan sebagai salah satu cara untuk mengorganisasi workload. Authorization Policy kemudian dapat membantu membatasi komunikasi antar-namespace.

Namespace A
   |
   +---- Service A
   |
   +---- Service B

Namespace B
   |
   +---- Service C
   |
   +---- Service D

Dengan policy yang sesuai, administrator dapat menentukan namespace mana yang dapat mengakses workload tertentu. Istio juga menyediakan contoh namespace isolation sebagai salah satu pola security policy. :contentReference[oaicite:15]{index=15}

Istio Authorization Policy untuk Ingress Gateway

Authorization Policy juga dapat diterapkan pada ingress gateway untuk membatasi traffic yang masuk dari luar ke service dalam mesh.

Internet
   |
   v
Ingress Gateway
   |
   v
Authorization Policy
   |
   +---- Allowed
   |
   +---- Denied
   |
   v
Internal Service

Contohnya, administrator dapat mengharuskan request tertentu memiliki JWT valid sebelum mengakses endpoint tertentu. Istio menyediakan contoh penggunaan Authorization Policy untuk kontrol akses pada ingress gateway. :contentReference[oaicite:16]{index=16}

Istio Authorization Policy dan External Authorization

Dalam beberapa lingkungan, keputusan authorization mungkin perlu melibatkan sistem eksternal. Action CUSTOM dapat digunakan untuk mengintegrasikan extension provider yang telah dikonfigurasi.

Request
   |
   v
Istio Proxy
   |
   v
External Authorization
   |
   v
Authorization Result
   |
   v
ALLOW / DENY

Pendekatan ini dapat digunakan ketika organisasi memiliki sistem authorization terpusat atau mekanisme kebijakan eksternal yang perlu diintegrasikan dengan Istio. :contentReference[oaicite:17]{index=17}

Best Practice Istio Authorization Policy

Gunakan prinsip least privilege.
Pertimbangkan pola default-deny untuk workload yang membutuhkan keamanan ketat.
Buat policy ALLOW dengan kondisi yang eksplisit.
Hindari policy yang terlalu luas.
Dokumentasikan tujuan setiap policy.
Gunakan nama policy yang mudah dipahami.
Uji policy sebelum diterapkan pada production.
Perhatikan precedence antara CUSTOM, DENY, dan ALLOW.
Evaluasi path normalization jika policy menggunakan HTTP path.
Monitor perubahan traffic setelah policy diterapkan.
Gunakan AUDIT atau mekanisme pengujian yang sesuai sebelum melakukan perubahan enforcement besar.
Evaluasi policy secara berkala.

Istio sendiri merekomendasikan pola default-deny dan positive matching sebagai bagian dari security best practices karena kesalahan policy lebih cenderung menghasilkan penolakan yang terlihat daripada akses yang tidak disengaja. :contentReference[oaicite:18]{index=18}

Troubleshooting Istio Authorization Policy

Request Mendapatkan HTTP 403

Response 403 Forbidden dapat menjadi indikasi bahwa request ditolak oleh authorization policy. Periksa policy yang berlaku, selector, source, operation, dan kondisi request.

Service Tidak Dapat Berkomunikasi

Periksa apakah terdapat DENY policy yang cocok atau apakah workload memiliki ALLOW policy yang terlalu ketat.

Policy Tidak Berlaku pada Workload

Periksa label workload, namespace, selector, serta targetRefs apabila digunakan.

Policy Terlalu Ketat

Jika request yang seharusnya diperbolehkan ditolak, periksa kembali rules dan kondisi yang digunakan.

DENY Tetap Mengalahkan ALLOW

Hal ini dapat terjadi karena DENY memiliki precedence lebih tinggi daripada ALLOW. Periksa policy DENY yang berlaku sebelum mengubah policy ALLOW. :contentReference[oaicite:19]{index=19}

JWT Sudah Valid tetapi Tetap Ditolak

Authentication dan authorization merupakan dua tahap berbeda. Token yang valid tidak otomatis berarti request memiliki izin. Periksa Authorization Policy yang menggunakan request principal atau atribut JWT lainnya.

Path Tidak Sesuai Ekspektasi

Jika policy menggunakan path, periksa konfigurasi dan perilaku path normalization agar proxy dan aplikasi tidak memiliki interpretasi berbeda terhadap request path. :contentReference[oaicite:20]{index=20}

Contoh Alur Authorization dalam Microservices

Client
   |
   v
Ingress Gateway
   |
   v
Authentication
   |
   v
Authorization
   |
   v
Frontend
   |
   v
API Service
   |
   v
Authorization
   |
   v
Payment Service

Dalam alur tersebut, authentication dapat digunakan untuk mengetahui identitas request, sedangkan authorization memastikan request tersebut memang memiliki hak akses terhadap resource yang dituju.

Istio Authorization Policy dalam Arsitektur Zero Trust

Jika dikombinasikan dengan mTLS, authentication, telemetry, dan kontrol akses lainnya, Authorization Policy dapat menjadi salah satu lapisan penting dalam arsitektur keamanan Zero Trust.

Identity
   |
   v
Authentication
   |
   v
mTLS
   |
   v
Authorization Policy
   |
   v
Telemetry
   |
   v
Monitoring & Audit

Setiap lapisan memiliki fungsi berbeda. Authentication membantu memastikan identitas, mTLS mengamankan komunikasi dan menyediakan workload identity, Authorization Policy menentukan hak akses, sedangkan telemetry membantu memberikan visibility terhadap aktivitas sistem.

FAQ Istio Authorization Policy

Apa itu Istio Authorization Policy?

Istio Authorization Policy adalah mekanisme kontrol akses dalam Istio yang digunakan untuk menentukan apakah request menuju workload diperbolehkan atau ditolak berdasarkan policy.

Apa fungsi Istio Authorization Policy?

Fungsinya adalah mengatur hak akses terhadap workload dan membatasi komunikasi antar-service berdasarkan kondisi tertentu.

Apa perbedaan authentication dan authorization?

Authentication berfokus pada identitas, sedangkan authorization berfokus pada hak akses dan tindakan yang diperbolehkan.

Apa itu action ALLOW?

ALLOW digunakan untuk mengizinkan request yang memenuhi rules policy.

Apa itu action DENY?

DENY digunakan untuk menolak request yang memenuhi kondisi policy dan memiliki precedence lebih tinggi daripada ALLOW.

Apa itu AUDIT?

AUDIT digunakan untuk menandai request yang cocok dengan policy untuk kebutuhan audit. Action ini tidak secara langsung mengubah keputusan allow atau deny. :contentReference[oaicite:21]{index=21}

Apa itu CUSTOM?

CUSTOM digunakan untuk mengintegrasikan authorization dengan extension provider eksternal yang dikonfigurasi dalam Istio. :contentReference[oaicite:22]{index=22}

Apakah Authorization Policy dapat menggunakan JWT?

Ya. Authorization Policy dapat menggunakan informasi identitas dari JWT yang telah divalidasi untuk membuat kontrol akses yang lebih spesifik. :contentReference[oaicite:23]{index=23}

Apakah Authorization Policy dapat digunakan bersama mTLS?

Ya. mTLS dan authorization memiliki fungsi berbeda dan dapat digunakan bersama untuk memperkuat keamanan komunikasi antar-workload.

Apakah Authorization Policy hanya digunakan untuk HTTP?

Tidak. Istio mendukung authorization untuk HTTP dan protokol lain yang didukung oleh proxy, termasuk gRPC, HTTP/2, HTTPS, dan plain TCP sesuai kemampuan Istio. :contentReference[oaicite:24]{index=24}

Apakah Authorization Policy dapat membatasi namespace?

Ya. Namespace dapat digunakan sebagai salah satu atribut source untuk membatasi workload yang diperbolehkan mengakses service tertentu.

Mengapa request mendapatkan 403 setelah Authorization Policy diterapkan?

Kemungkinan penyebabnya adalah request tidak memenuhi rule ALLOW atau cocok dengan rule DENY. Selector, source, operation, path, identitas, dan kondisi policy perlu diperiksa.

Apakah default-deny direkomendasikan?

Istio merekomendasikan default-deny sebagai salah satu pola yang lebih aman untuk authorization karena akses kemudian diberikan secara eksplisit berdasarkan kebutuhan. :contentReference[oaicite:25]{index=25}

Artikel Selanjutnya

Setelah memahami Istio Authorization Policy, pembahasan berikutnya akan masuk ke Istio RequestAuthentication (JWT).

Istio RequestAuthentication akan membahas mekanisme authentication berbasis request, khususnya penggunaan JSON Web Token atau JWT untuk membantu memverifikasi identitas request sebelum authorization diterapkan.

Service Mesh
      |
      v
Distributed Tracing
      |
      v
Istio Telemetry
      |
      v
Istio Authorization Policy
      |
      v
Istio RequestAuthentication (JWT)
      |
      v
Istio PeerAuthentication (mTLS)
      |
      v
Mutual TLS (mTLS)

Kesimpulan

Istio Authorization Policy merupakan komponen penting dalam Istio Service Mesh yang digunakan untuk mengatur kontrol akses terhadap workload dan komunikasi antar-service. Dengan menggunakan policy, administrator dapat menentukan request mana yang diperbolehkan dan request mana yang harus ditolak.

Authorization berbeda dengan authentication. Authentication berfokus pada identitas, sedangkan authorization berfokus pada hak akses. Dalam lingkungan Istio, keduanya dapat digunakan bersama untuk membangun sistem keamanan yang lebih lengkap.

Authorization Policy menyediakan berbagai komponen seperti selector, targetRefs, action, rules, from, to, dan when. Komponen tersebut memungkinkan administrator membuat aturan yang lebih granular berdasarkan workload, source, operation, HTTP method, path, identitas, namespace, dan atribut lainnya.

Istio juga menyediakan beberapa action penting seperti ALLOW, DENY, AUDIT, dan CUSTOM. Policy tersebut memiliki mekanisme evaluasi tertentu sehingga administrator perlu memahami precedence antara CUSTOM, DENY, dan ALLOW sebelum menerapkan policy pada production. :contentReference[oaicite:26]{index=26}

Dalam praktik keamanan, pendekatan default-deny dan positive matching dapat membantu mengurangi risiko akses yang tidak disengaja. Administrator sebaiknya memberikan izin secara eksplisit hanya kepada service atau workload yang memang membutuhkannya.

Authorization Policy juga dapat dikombinasikan dengan JWT, PeerAuthentication, mutual TLS, telemetry, dan komponen keamanan lainnya. Kombinasi tersebut memungkinkan Istio digunakan sebagai salah satu fondasi keamanan dalam arsitektur microservices dan cloud-native.

Dengan memahami Istio Authorization Policy, kita telah menyelesaikan bagian penting mengenai kontrol akses dalam service mesh. Pembahasan selanjutnya adalah Istio RequestAuthentication (JWT), yang akan membawa pembahasan keamanan Istio ke sisi authentication dan validasi identitas request.