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

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

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

Ilustrasi Authorization Policy Istio yang mengatur izin akses antar layanan dan pengguna dalam Kubernetes Service Mesh.

Setelah memahami RequestAuthentication Istio, pembahasan keamanan berikutnya adalah Authorization Policy Istio. Jika RequestAuthentication digunakan untuk memvalidasi identitas request, terutama melalui JWT, maka AuthorizationPolicy digunakan untuk menentukan apakah request tersebut diperbolehkan mengakses workload atau resource tertentu.

AuthorizationPolicy menjadi salah satu komponen penting dalam penerapan access control pada Service Mesh. Dengan resource ini, administrator dapat mengatur akses berdasarkan identitas workload, namespace, service account, JWT, HTTP method, URL path, port, IP address, maupun kondisi tertentu.

Istio menjalankan authorization pada Envoy Proxy di sisi server. Dengan demikian, kebijakan akses dapat diterapkan secara konsisten tanpa harus menambahkan logika authorization secara terpisah pada setiap aplikasi Dewa234. :contentReference[oaicite:1]{index=1}

Apa Itu Authorization Policy Istio?

AuthorizationPolicy adalah Custom Resource Definition (CRD) Istio yang digunakan untuk mengontrol akses terhadap workload di dalam Service Mesh. Resource ini menentukan request mana yang boleh diterima dan request mana yang harus ditolak berdasarkan aturan yang telah ditentukan.

AuthorizationPolicy dapat diterapkan pada cakupan mesh, namespace, maupun workload tertentu. Target workload dapat ditentukan menggunakan selector, sehingga kebijakan dapat dibuat secara spesifik sesuai kebutuhan aplikasi. :contentReference[oaicite:2]{index=2}

Mengapa Authorization Policy Penting?

  • Mengontrol akses antar workload.
  • Membatasi akses berdasarkan namespace.
  • Mengatur akses berdasarkan service account.
  • Mengatur akses berdasarkan JWT identity.
  • Membatasi HTTP method tertentu.
  • Membatasi URL path tertentu.
  • Menerapkan prinsip least privilege.
  • Mendukung Zero Trust Architecture.
  • Meningkatkan keamanan microservices.

Bagaimana Cara Kerja Authorization Policy?

  1. Client mengirim request menuju sebuah workload.
  2. Request diterima oleh Envoy Proxy.
  3. Envoy membaca konteks request.
  4. Authorization engine mengevaluasi policy yang berlaku.
  5. Istio mencocokkan source, operation, dan condition.
  6. Jika aturan mengizinkan request, trafik diteruskan ke aplikasi.
  7. Jika aturan menolak request, trafik dihentikan oleh Envoy.

Ilustrasi Cara Kerja Authorization Policy


Client
  │
  ▼
Envoy Proxy
  │
  ▼
Authorization Engine
  │
  ├── CUSTOM
  │
  ├── DENY
  │
  └── ALLOW
  │
  ▼
Application

Authorization dilakukan pada inbound traffic di Envoy Proxy. Envoy menjalankan authorization engine yang mengevaluasi konteks request terhadap policy yang sedang berlaku. :contentReference[oaicite:3]{index=3}

Arsitektur Authorization Policy


                 Istiod
                   │
                   │ Policy
                   ▼
          +------------------+
          |   Envoy Proxy    |
          | Authorization    |
          |     Engine       |
          +------------------+
                   │
             Access Decision
              │           │
            ALLOW        DENY
              │           │
              ▼           X
        +-----------+
        | Workload  |
        +-----------+

Komponen Utama AuthorizationPolicy

Komponen Fungsi
selector Menentukan workload yang menjadi target policy.
action Menentukan tindakan seperti ALLOW, DENY, AUDIT, atau CUSTOM.
rules Berisi aturan yang menentukan kondisi request.
from Menentukan sumber request.
to Menentukan operasi atau tujuan request.
when Menentukan kondisi tambahan.
provider Menentukan extension provider untuk action CUSTOM.

Struktur AuthorizationPolicy secara umum terdiri dari target, action, dan rules. Dalam rules terdapat bagian from untuk source, to untuk operation, serta when untuk kondisi tambahan. :contentReference[oaicite:4]{index=4}

Action pada Authorization Policy

Action Fungsi
ALLOW Mengizinkan request yang sesuai dengan rule.
DENY Menolak request yang sesuai dengan rule.
AUDIT Menandai request untuk proses audit tanpa mengubah keputusan allow atau deny.
CUSTOM Meneruskan keputusan authorization tertentu kepada extension provider eksternal.

Istio menggunakan urutan evaluasi CUSTOM → DENY → ALLOW. Sementara itu, AUDIT tidak menentukan keputusan akses dan memerlukan plugin pendukung agar proses audit benar-benar dilakukan. :contentReference[oaicite:5]{index=5}

Authorization Policy ALLOW

Action ALLOW digunakan untuk membuat aturan yang hanya mengizinkan request yang memenuhi kondisi tertentu. Ketika sebuah workload sudah memiliki ALLOW policy, request yang tidak cocok dengan policy ALLOW akan ditolak secara default.

Pola ini sangat berguna untuk menerapkan prinsip least privilege, yaitu memberikan akses seminimal mungkin sesuai kebutuhan. :contentReference[oaicite:6]{index=6}

Contoh ALLOW Policy

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: allow-api
  namespace: default
spec:
  selector:
    matchLabels:
      app: my-api
  action: ALLOW
  rules:
  - from:
    - source:
        namespaces:
        - frontend
    to:
    - operation:
        methods:
        - GET
        paths:
        - "/api/*"

Policy tersebut memberikan akses kepada request yang berasal dari namespace frontend untuk menggunakan method GET menuju path yang diawali /api/.

Authorization Policy DENY

Action DENY digunakan untuk menolak request yang memenuhi kondisi tertentu. DENY memiliki prioritas lebih tinggi daripada ALLOW sehingga request yang cocok dengan DENY akan tetap ditolak meskipun terdapat ALLOW policy yang juga cocok. :contentReference[oaicite:7]{index=7}

Contoh DENY Policy

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: deny-admin
  namespace: default
spec:
  selector:
    matchLabels:
      app: my-api
  action: DENY
  rules:
  - to:
    - operation:
        paths:
        - "/admin/*"

Contoh tersebut menolak request menuju path /admin/ pada workload yang dipilih.

Authorization Policy AUDIT

Action AUDIT digunakan ketika administrator ingin menandai request tertentu untuk proses audit tanpa mengubah keputusan apakah request tersebut boleh atau tidak.

AUDIT tidak sama dengan DENY. Request yang cocok dengan AUDIT tetap dapat diteruskan apabila tidak ada policy lain yang menolaknya. Agar keputusan audit benar-benar menghasilkan log atau tindakan audit, diperlukan plugin pendukung yang sesuai. :contentReference[oaicite:8]{index=8}

Authorization Policy CUSTOM

Action CUSTOM digunakan untuk mendelegasikan keputusan authorization kepada extension provider eksternal yang telah dikonfigurasi dalam MeshConfig.

Fitur ini berguna apabila organisasi memiliki sistem authorization eksternal dan ingin mengintegrasikannya dengan Istio. CUSTOM dievaluasi sebelum DENY dan ALLOW. :contentReference[oaicite:9]{index=9}

Source pada Authorization Policy

Bagian from digunakan untuk menentukan sumber request. Administrator dapat membatasi akses berdasarkan identitas workload, namespace, service account, principal, request principal, IP, maupun atribut source lainnya yang didukung.

Source Contoh Fungsi
principals Membatasi berdasarkan identitas workload.
namespaces Membatasi berdasarkan namespace sumber.
serviceAccounts Membatasi berdasarkan service account.
requestPrincipals Membatasi berdasarkan identitas JWT yang telah tervalidasi.
ipBlocks Membatasi berdasarkan IP sumber.

Operation pada Authorization Policy

Bagian to digunakan untuk menentukan operasi yang boleh atau tidak boleh dilakukan oleh request.

Beberapa atribut yang dapat digunakan antara lain:

  • HTTP method.
  • URL path.
  • Port.
  • Host.
  • HTTP headers.

Contoh Pembatasan HTTP Method

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

Dengan konfigurasi tersebut, workload hanya akan mengizinkan request yang sesuai dengan rule ALLOW tersebut. Request yang tidak cocok dengan ALLOW policy dapat ditolak secara default. :contentReference[oaicite:10]{index=10}

Condition pada Authorization Policy

Bagian when digunakan untuk memberikan kondisi tambahan. Contohnya adalah mencocokkan JWT claims, source IP, destination port, request header, atau atribut lain yang tersedia.

Istio menyediakan berbagai key untuk bagian when, termasuk request.headers, source.ip, remote.ip, source.namespace, request.auth.claims, dan destination.port. :contentReference[oaicite:11]{index=11}

Contoh Authorization Policy Berdasarkan JWT

Karena artikel sebelumnya membahas RequestAuthentication, kita dapat menyambungkan keduanya. RequestAuthentication melakukan validasi JWT, kemudian AuthorizationPolicy menggunakan identitas hasil validasi tersebut untuk menentukan izin akses. 

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: require-jwt
  namespace: default
spec:
  selector:
    matchLabels:
      app: my-api
  action: ALLOW
  rules:
  - from:
    - source:
        requestPrincipals:
        - "*"

Policy tersebut hanya mengizinkan request yang memiliki request principal hasil autentikasi JWT yang valid. Istio membentuk request principal dari informasi issuer dan subject JWT. :contentReference[oaicite:12]{index=12}

RequestAuthentication + AuthorizationPolicy

Kombinasi keduanya dapat digambarkan sebagai berikut: 


Client
   │
   │ JWT
   ▼
RequestAuthentication
   │
   │ Validate JWT
   ▼
Authenticated Identity
   │
   ▼
AuthorizationPolicy
   │
   ├── ALLOW
   │
   └── DENY
   │
   ▼
Application

Dengan pola tersebut, pembagian tanggung jawab menjadi jelas. RequestAuthentication menjawab siapa identitas request, sedangkan AuthorizationPolicy menentukan apakah identitas tersebut memiliki izin untuk mengakses workload.

Default Behavior Authorization Policy

Istio tidak memerlukan pengaktifan authorization secara terpisah. Fitur authorization tersedia setelah Istio terpasang. Untuk workload yang belum memiliki AuthorizationPolicy, request pada dasarnya diizinkan. Ketika sebuah workload memiliki policy ALLOW, mekanisme allow-by-default berubah sehingga request yang tidak cocok dengan ALLOW policy akan ditolak. :contentReference[oaicite:13]{index=13}

Allow Nothing Policy

Salah satu pola keamanan yang direkomendasikan adalah memulai dengan policy yang tidak mengizinkan request apa pun, kemudian menambahkan akses secara bertahap. 

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: allow-nothing
  namespace: default
spec:
  selector:
    matchLabels:
      app: my-api
  action: ALLOW

Karena policy ALLOW tersebut tidak memiliki rule yang cocok, request ke workload yang ditargetkan tidak akan diizinkan sampai policy ALLOW lain ditambahkan. Pendekatan ini membantu menerapkan prinsip least privilege. :contentReference[oaicite:14]{index=14}

Deny All Policy

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: deny-all
  namespace: default
spec:
  selector:
    matchLabels:
      app: my-api
  action: DENY
  rules:
  - {}

Rule kosong pada DENY policy akan cocok dengan seluruh request yang masuk ke workload yang ditargetkan. DENY juga memiliki prioritas lebih tinggi daripada ALLOW. :contentReference[oaicite:15]{index=15}

Allow All Policy

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: allow-all
  namespace: default
spec:
  selector:
    matchLabels:
      app: my-api
  action: ALLOW
  rules:
  - {}

Policy tersebut mengizinkan semua request yang ditujukan kepada workload yang dipilih, selama request tidak ditolak oleh policy CUSTOM atau DENY. Karena itu, konfigurasi seperti ini harus digunakan dengan sangat hati-hati pada lingkungan produksi. :contentReference[oaicite:16]{index=16}

Authorization Policy dan mTLS

AuthorizationPolicy dapat menggunakan identitas workload seperti principal dan namespace. Atribut tersebut berkaitan dengan identitas workload yang disediakan melalui mekanisme keamanan Istio, termasuk mTLS.

Dengan demikian, pembahasan sebelumnya tentang Mutual TLS dan PeerAuthentication tetap memiliki hubungan langsung dengan AuthorizationPolicy.

Authorization Policy dan Zero Trust

AuthorizationPolicy dapat menjadi salah satu fondasi penerapan Zero Trust Architecture. Alih-alih mempercayai seluruh trafik yang berada di dalam cluster, setiap request dapat diperiksa berdasarkan identitas, sumber, tujuan, method, path, dan kondisi lainnya.

Pendekatan tersebut membuat akses dapat diberikan berdasarkan kebutuhan aktual aplikasi, bukan sekadar berdasarkan lokasi jaringan.

Manfaat Authorization Policy

  • Mengontrol akses antar microservices.
  • Membatasi akses berdasarkan identitas.
  • Menerapkan prinsip least privilege.
  • Mengurangi akses yang tidak diperlukan.
  • Mendukung Zero Trust Security.
  • Mengintegrasikan JWT authentication dengan authorization.
  • Meningkatkan keamanan aplikasi Kubernetes.
  • Memusatkan kebijakan akses pada Service Mesh.

Kelebihan Authorization Policy

  • Terintegrasi dengan Istio dan Envoy.
  • Tidak membutuhkan perubahan kode aplikasi untuk policy dasar.
  • Mendukung HTTP, HTTPS, HTTP/2, gRPC, dan TCP.
  • Mendukung workload-to-workload authorization.
  • Mendukung end-user-to-workload authorization.
  • Mendukung ALLOW, DENY, AUDIT, dan CUSTOM.
  • Dapat diterapkan pada berbagai tingkat scope.

Istio menyatakan bahwa authorization mendukung workload-to-workload dan end-user-to-workload authorization serta berbagai protokol seperti gRPC, HTTP, HTTP/2, HTTPS, dan plain TCP. :contentReference[oaicite:17]{index=17}

Kekurangan Authorization Policy

  • Konfigurasi dapat menjadi kompleks pada Service Mesh besar.
  • Kesalahan policy dapat menyebabkan service tidak dapat diakses.
  • Administrator harus memahami identitas workload dan request.
  • Policy yang terlalu longgar dapat membuka akses yang tidak diperlukan.
  • Policy yang terlalu ketat dapat menyebabkan false rejection.
  • Membutuhkan pengujian sebelum diterapkan ke produksi.

Best Practice Authorization Policy

  • Mulai dengan prinsip least privilege.
  • Gunakan ALLOW dengan positive matching.
  • Gunakan DENY dengan negative matching secara hati-hati.
  • Batasi selector pada workload yang memang membutuhkan policy.
  • Gunakan mTLS untuk identitas workload.
  • Gunakan RequestAuthentication untuk JWT.
  • Gunakan AuthorizationPolicy untuk mengatur hak akses JWT.
  • Uji policy sebelum diterapkan ke produksi.
  • Gunakan dry-run ketika perlu menguji efek policy.
  • Dokumentasikan setiap kebijakan akses.

Istio merekomendasikan pola ALLOW-with-positive-matching dan DENY-with-negative-matching karena kesalahan pencocokan policy cenderung menghasilkan penolakan akses daripada membuka peluang bypass authorization. :contentReference[oaicite:18]{index=18}

Dry Run Authorization Policy

Istio menyediakan mekanisme dry-run yang memungkinkan administrator menguji efek policy tanpa langsung memberlakukannya terhadap trafik produksi. 

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: test-policy
  namespace: default
  annotations:
    "istio.io/dry-run": "true"
spec:
  selector:
    matchLabels:
      app: my-api
  action: DENY
  rules:
  - to:
    - operation:
        paths:
        - "/admin/*"

Pendekatan dry-run dapat membantu memahami dampak policy sebelum enforcement benar-benar dilakukan. :contentReference[oaicite:19]{index=19}

Troubleshooting Authorization Policy

Masalah Kemungkinan Penyebab Solusi
Request mendapatkan 403. Request tidak cocok dengan ALLOW policy atau cocok dengan DENY. Periksa selector, rules, from, to, dan when.
Semua request ditolak. ALLOW policy terlalu ketat. Periksa rule dan tambahkan akses yang diperlukan.
DENY tidak bekerja. Selector atau kondisi tidak cocok. Periksa workload target dan atribut request.
JWT tidak dapat digunakan untuk authorization. RequestAuthentication belum memvalidasi JWT. Pastikan RequestAuthentication dan JWT configuration benar.
Principal tidak tersedia. mTLS belum berjalan atau konfigurasi identitas bermasalah. Periksa PeerAuthentication dan status Envoy.
Policy tidak diterapkan ke workload. Selector atau namespace salah. Periksa label workload dan namespace policy.

Contoh Arsitektur Keamanan Istio


                    Client
                      │
                      ▼
             Istio Ingress Gateway
                      │
                      ▼
             RequestAuthentication
                      │
                  Validate JWT
                      │
                      ▼
             AuthorizationPolicy
                      │
                      ▼
                Service A
                      │
                 mTLS / Envoy
                      │
                      ▼
                Service B
                      │
               AuthorizationPolicy
                      │
                      ▼
                Service C

Arsitektur tersebut menunjukkan hubungan beberapa komponen keamanan yang telah kita bahas. Ingress Gateway menerima trafik, RequestAuthentication memvalidasi identitas JWT, AuthorizationPolicy menentukan hak akses, sementara mTLS dan PeerAuthentication melindungi komunikasi antar workload.

Baca Juga

Artikel Selanjutnya

Setelah memahami AuthorizationPolicy, pembahasan berikutnya akan beralih dari security control menuju observability. Artikel selanjutnya adalah Istio Telemetry, yang membahas bagaimana Istio mengumpulkan dan mengatur telemetry seperti metrics, access logs, dan tracing dari workload dalam Service Mesh.

Pertanyaan yang Sering Diajukan (FAQ)

Apa itu Authorization Policy Istio?

AuthorizationPolicy adalah resource Istio yang digunakan untuk mengatur hak akses terhadap workload berdasarkan source, operation, identitas, JWT, dan kondisi tertentu.

Apa perbedaan RequestAuthentication dan AuthorizationPolicy?

RequestAuthentication digunakan untuk memvalidasi identitas request, terutama JWT. AuthorizationPolicy digunakan untuk menentukan apakah request yang telah teridentifikasi tersebut diperbolehkan mengakses workload.

Apa fungsi action ALLOW?

ALLOW digunakan untuk mengizinkan request yang cocok dengan rule. Jika workload memiliki ALLOW policy, request yang tidak cocok dengan policy ALLOW akan ditolak secara default.

Apa fungsi action DENY?

DENY digunakan untuk menolak request yang cocok dengan rule. DENY memiliki prioritas lebih tinggi daripada ALLOW. :contentReference[oaicite:20]{index=20}

Apa fungsi AUDIT?

AUDIT digunakan untuk menandai request yang cocok untuk proses audit. Action ini tidak menentukan apakah request diizinkan atau ditolak. :contentReference[oaicite:21]{index=21}

Apakah AuthorizationPolicy membutuhkan perubahan kode aplikasi?

Untuk kebijakan akses dasar yang diterapkan pada Envoy Proxy, administrator dapat mengatur AuthorizationPolicy tanpa menambahkan logika authorization langsung ke setiap aplikasi. Hal ini menjadi salah satu manfaat penggunaan Service Mesh.

Apakah AuthorizationPolicy dapat digunakan dengan JWT?

Ya. RequestAuthentication dapat memvalidasi JWT terlebih dahulu, kemudian AuthorizationPolicy dapat menggunakan request principal atau JWT claims sebagai dasar keputusan akses. :contentReference[oaicite:22]{index=22}

Kesimpulan

Authorization Policy Istio merupakan komponen penting untuk mengontrol akses terhadap workload dalam Kubernetes Service Mesh. Dengan AuthorizationPolicy, administrator dapat menentukan siapa yang boleh mengakses service, operasi apa yang diperbolehkan, path mana yang dapat digunakan, serta kondisi apa yang harus dipenuhi oleh sebuah request.

AuthorizationPolicy juga melengkapi komponen keamanan yang telah dibahas sebelumnya. Mutual TLS melindungi komunikasi antar workload, PeerAuthentication mengatur mode mTLS, RequestAuthentication memvalidasi JWT, sedangkan AuthorizationPolicy menentukan hak akses berdasarkan identitas dan atribut request.

Dengan menggabungkan seluruh komponen tersebut, Istio dapat membantu membangun arsitektur keamanan Service Mesh berbasis Zero Trust, least privilege, identity-based access control, dan policy enforcement yang terpusat.

Location: Indonesia

Postingan populer dari blog ini

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

Dipublikasikan:
Gambar
Istio Egress Gateway: Pengertian, Cara Kerja, Arsitektur, Komponen, Fungsi, Manfaat, Kelebihan, Kekurangan, dan Implementasinya | Dewa234 Istio Egress Gateway: Pengertian, Cara Kerja, Arsitektur, Komponen, Fungsi, Manfaat, Kelebihan, Kekurangan, dan Implementasinya Dalam arsitektur microservices modern, komunikasi aplikasi Dewa234 tidak hanya terjadi antar-service yang berada di dalam Kubernetes atau Service Mesh. Banyak aplikasi juga membutuhkan akses menuju layanan eksternal seperti API pihak ketiga, payment gateway, cloud service, database eksternal, sistem legacy, SaaS, dan berbagai layanan yang berada di luar cluster. Traffic yang keluar dari Service Mesh tersebut dikenal sebagai egress traffic . Jika traffic keluar dibiarkan langsung dari masing-masing workload menuju internet atau jaringan eksternal, administrator dapat mengalami kesulitan dalam melakukan monitoring, pengamanan, logging, dan pengendalian akses. Istio menyediakan Egress Gateway untuk membant...
Baca Selengkapnya →

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

Dipublikasikan:
Gambar
Istio VirtualService: Pengertian, Cara Kerja, Arsitektur, Komponen, Fungsi, Manfaat, Kelebihan, Kekurangan, dan Implementasinya | Dewa234 Istio VirtualService: Pengertian, Cara Kerja, Arsitektur, Komponen, Fungsi, Manfaat, Kelebihan, Kekurangan, dan Implementasinya Dalam arsitektur microservices , sebuah aplikasi Dewa234 biasanya terdiri dari banyak service yang saling berkomunikasi. Ketika jumlah service semakin besar, pengelolaan traffic menjadi semakin kompleks. Request tidak selalu harus dikirim secara sederhana ke satu service saja. Dalam kondisi tertentu, traffic perlu diarahkan berdasarkan hostname, URI, header, versi aplikasi, persentase traffic, maupun kondisi tertentu lainnya. Pada Kubernetes biasa, routing traffic umumnya bergantung pada Service, Ingress, load balancer, atau komponen networking lainnya. Namun ketika sebuah organisasi menggunakan Istio Service Mesh , pengelolaan traffic dapat dilakukan dengan aturan yang jauh lebih fleksibel melalui resource ...
Baca Selengkapnya →

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

Dipublikasikan:
Gambar
Istio Ingress Gateway: Pengertian, Cara Kerja, Arsitektur, Komponen, Fungsi, Manfaat, Kelebihan, Kekurangan, dan Implementasinya | Dewa234 Istio Ingress Gateway: Pengertian, Cara Kerja, Arsitektur, Komponen, Fungsi, Manfaat, Kelebihan, Kekurangan, dan Implementasinya Dalam arsitektur microservices , tidak semua traffic berasal dari service lain yang berada di dalam cluster. Banyak request berasal dari luar sistem, seperti browser pengguna, aplikasi mobile, partner API, sistem eksternal, maupun client dari jaringan perusahaan. Traffic yang masuk dari luar menuju service yang berada di dalam Service Mesh disebut sebagai ingress traffic . Traffic tersebut membutuhkan titik masuk yang dapat mengatur port, protocol, hostname, TLS, routing, serta berbagai kebijakan keamanan sebelum request diteruskan menuju service internal. Istio menyediakan Ingress Gateway sebagai salah satu komponen yang digunakan untuk menangani traffic masuk ke service mesh. Ingress Gateway berjalan ...
Baca Selengkapnya →