Skip to content

NimTechnology

Trình bày các công nghệ CLOUD một cách dễ hiểu.

  • Kubernetes & Container
    • Docker
    • Kubernetes
      • Ingress
      • Pod
    • Helm Chart
    • OAuth2 Proxy
    • Isito-EnvoyFilter
    • Apache Kafka
      • Kafka
      • Kafka Connect
      • Lenses
    • Vault
    • Longhorn – Storage
    • VictoriaMetrics
    • MetalLB
    • Kong Gateway
  • CI/CD
    • ArgoCD
    • ArgoWorkflows
    • Argo Events
    • Spinnaker
    • Jenkins
    • Harbor
    • TeamCity
    • Git
      • Bitbucket
  • Coding
    • DevSecOps
    • Terraform
      • GCP – Google Cloud
      • AWS – Amazon Web Service
      • Azure Cloud
    • Golang
    • Laravel
    • Python
    • Jquery & JavaScript
    • Selenium
  • Log, Monitor & Tracing
    • DataDog
    • Prometheus
    • Grafana
    • ELK
      • Kibana
      • Logstash
  • BareMetal
    • NextCloud
  • Toggle search form

[Istio] Security authentication và authorization with ISTIO

Posted on October 14, 2021December 4, 2021 By nim No Comments on [Istio] Security authentication và authorization with ISTIO

Như ở 1 bài viết mình đã có nhắc đến authentication và authorization cũng với test một vài feature istio trong bài viết bên dưới:

[Istio/Recheck] Hướng dẫn kiểm tra các feature của cụm istio mới cài lên đã work ngon lành chưa?

Nếu bạn đang tò mò security của istio có j, thì chúng ta sẽ đi chi tiết.

Contents

Toggle
  • Security
    • 1) Authorization Policy
      • 1.1) It sets the action to “ALLOW” to create an allow policy. The default action is “ALLOW” but it is useful to be explicit in the policy.
        • 1.1.1) Action ALLOW
        • 1.1.2) Action DENY
        • 1.1.3) Action AUDIT
        • 1.1.4) Action CUSTOM
      • 1.2) Authorization Policy follow nimtechnology ways
        • 1.2.1) Normal
        • 1.2.2) Per Path
        • 1.2.3) a JWT access a few hosts
        • 1.2.4) HTTP header Attribute Bạn thực hiện thêm và check các header trong phần AuthorizationPolicy
        • 1.2.5) Source IP

Security

links: https://istio.io/latest/docs/reference/config/security/

1) Authorization Policy

Configuration for access control on workloads.

The evaluation is determined by the following rules:

  1. If there are any CUSTOM policies that match the request, evaluate and deny the request if the evaluation result is deny.
  2. If there are any DENY policies that match the request, deny the request.
  3. If there are no ALLOW policies for the workload, allow the request.
  4. If any of the ALLOW policies match the request, allow the request.
  5. Deny the request.


Giờ chúng ta sẽ kiểm tra bằng các run chạy sem ntn he:

Đầu tiên bạn cần tạo ra 1 namespace và enable auto inject sidecar trên ns đó:

kubectl label namespace default istio-injection=enabled

Ở đó mình chọn là inject ns default.

Trên rancher hiển thị luôn

Mình ví dụ bạn có 2 workload A và B:
và bạn muốn cấu hình những access controls trên workload B với các ví dụ sau đây:

1.1) It sets the action to “ALLOW” to create an allow policy. The default action is “ALLOW” but it is useful to be explicit in the policy.

Giờ chúng ta deploy app “fleetman-webapp” trong links dưới cung cấp yaml:
https://github.com/mrnim94/recheck-instio/tree/main/authen-author-istio/httpin

Đã inject proxy rồi nhé.

Ở bài viết này mình sẽ viết tắt:
vs: VirtualService
gw: Gateway
dr: DestinationRule
tại các bạn thấy mình viết tắt lại đéo hiểu thằng này nó đang nói đến Kind nào hí hí.

1.1.1) Action ALLOW

Với action: ALLOW thì sẽ deny All and chỉ allow cho các đối tượng cụ thể được phép access.

Allows requests from:
– Service account

To access the workload with:
– All methods and All paths
– Specify particular methods(GET/POST/…) – Chỉ định nhưng methods cụ thể
– Specify particular paths(/ip) or prefix(/abc*)

Giờ deploy
– 1 busybox-default – service account cùng ns với workload httpbin
– 1 busybox-sample – service account khác ns với workload httpbin

Giờ cho 2 busybox tấn công con httpbin

Note: để mTLS mode strict có thể hoạt động.

Thì phải configmap của istiod: enableAutoMtls: true hoặc không config enableAutoMtls
Lúc này mTLS mode permissive

Cấu hình mTLS mode strict apply vào ns default

# cấu hình authen

apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  labels:
  name: default
  namespace: default
spec:
  mtls:
    mode: STRICT
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  labels:
    app.kubernetes.io/instance: author-default-httpbin
  name: author-default
  namespace: default
spec:
  action: ALLOW
  rules:
    - from:
        - source:
            principals:
              - cluster.local/ns/default/sa/busybox-sa
      to:
        - operation:
            methods:
              - GET
            paths:
              - /ip
              - /status*

Câu hỏi làm sao để chúng ta kiếm được đúng Source Workload of Service account (SA của workload Nguồn)

Các map SA cho đúng

Tiến hành kiểm tra:

EndUser –> Gw -> Vs -> Svc -> Deployment TOANG

while true; do curl -sS fleetman-webapp.nimtechnology.com/ip; echo; sleep 1; done

EndUser -> port-forward OK

kubectl -n default port-forward deployment.apps/deploy-httpbin 8080:80

while true; do curl -sS localhost:8080/ip; echo; sleep 1; done
Truy cập được nhé.

Workload Service account (Source):
– Cùng ns = default, có SA = busybox-sa —> service: GET – httpbin.default.svc.cluster.local/ip : OK
trường hợp đúng rule AuthorizationPolicy
– Cùng ns = default, có SA = busybox-sa —> service: GET – fleetman-webapp.nimtechnology.com/ip : Toang
ko có rule liên quan đến istio-gateway
– Cùng ns = default, có SA = busybox-sa —> service: GET – httpbin.default.svc.cluster.local/status/200 : OK
trường hợp đúng rule AuthorizationPolicy (prefix /status*)
– Cùng ns = default, có SA = busybox-sa —> service: GET – httpbin.default.svc.cluster.local/ : Toang
ko match rule nào cả
– Khác ns = sample, có SA = busybox-sa —> service: GET – httpbin.default.svc.cluster.local/ip : Toang
ko match rule nào cả

Giờ đổi lại Allow access cho ns sample và SA busybox-sa với file yaml bên dưới:

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  labels:
    app.kubernetes.io/instance: author-default-httpbin
  name: author-default
  namespace: default
spec:
  action: ALLOW
  rules:
    - from:
        - source:
            principals:
              - cluster.local/ns/sample/sa/busybox-sa
      to:
        - operation:
            methods:
              - GET
            paths:
              - /ip
              - /status*

– Cùng ns = sample, có SA = busybox-sa —> service: GET – httpbin.default.svc.cluster.local/ip : OK
Đổi lại cho Đúng là ok thôi
– Các workload ở ns default sẽ toang hết.

Thật ra các workload CI/CD của các công ty đa số phân chia bằng namespace và workload selector

Source

Nhìn source của nó namespace,… nhưng không thấy thông số nói về workload
–> nếu muốn chỉ định workload source thì chỉ có thể dụng Service account

Hình này AND OR đã nhức đầu
mà chữ còn mờ mờ nữa

Giờ sửa lại file AuthorizationPolicy chút

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  labels:
    app.kubernetes.io/instance: author-default-httpbin
  name: author-default
  namespace: default
spec:
  action: ALLOW
  rules:
    - from:
        - source:
            namespaces:
              - default
              - go-demo-8
            principals:
              - cluster.local/ns/default/sa/busybox-sa
        - source:
            namespaces:
              - sample
            principals:
              - cluster.local/ns/sample/sa/busybox-sa
      to:
        - operation:
            methods:
              - GET
            paths:
              - /ip
              - /status*

– Chúng ta cho phép tất cả workload trong namespace khác “sample” allow acess
– Chỉ có 1 vài workload cùng ns “default” allow acess

Chúng ta có 1 app mới là với SA mới nhưng ở ns default.

Namspace và Service account (source):
– Cùng ns = default, có SA = busybox-sa —> service: GET – httpbin.default.svc.cluster.local/ip : OK
trường hợp đúng rule AuthorizationPolicy
– Cùng ns = default, có SA = busybox-sa —> service: GET – fleetman-webapp.nimtechnology.com/ip : Toang
ko có rule liên quan đến istio-gateway
– Cùng ns = default, có SA = busybox-sa —> service: GET – httpbin.default.svc.cluster.local/status/200 : OK
trường hợp đúng rule AuthorizationPolicy (prefix /status*)
– Cùng ns = default, có SA = busybox-sa —> service: GET – httpbin.default.svc.cluster.local/ : Toang
ko match rule nào cả
– Cùng ns = default, có SA = busybox-sa-1 —> service: GET – httpbin.default.svc.cluster.local/ip : Toang
ko match rule nào cả
– Khác ns = sample, có SA = busybox-sa —> service: GET – httpbin.default.svc.cluster.local/ip : OK
– Cùng ns = sample, có SA = busybox-sa —> service: GET – httpbin.default.svc.cluster.local/status/200 : OK
trường hợp đúng rule AuthorizationPolicy (prefix /status*)

Với các config ở trên thì chúng ta mới chỉnh quan tâm đến source (namespace và workload)
Ngoài chúng ta apply author lên toàn namespace thì chúng ta forcus xuống từng workload
với config như dưới “selector->matchLabels”

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: author-default
  namespace: default
spec:
  selector:
   matchLabels:
     app: httpbin
  action: ALLOW
  rules:
  - from:
    - source:
        principals: ["cluster.local/ns/default/sa/busybox-sa"]
        namespaces: ["default","go-demo-8"]
    
    - source:
        principals: ["cluster.local/ns/sample/sa/busybox-sa"]
        namespaces: ["sample"]
    
    to:
    - operation:
        methods: ["GET"]
        paths: ["/ip","/status*"]
Các xác định label của workload

OK giờ mình deploy thêm app mới với domain gw là: http://fleetman-webapp-1.nimtechnology.com/

matchLabels:
– EndUser –> Gw(http://fleetman-webapp.nimtechnology.com) -> Vs -> Svc(httpbin) -> Deployment(app: httpbin) TOANG
ko match rule nào cả
– EndUser –> Gw(http://fleetman-webapp.nimtechnology.com) -> Vs -> Svc(httpbin) -> Deployment(app: httpbin) OK
vì chúng chỉ apply author cho workload app: httpbin
– Cùng ns = default, có SA = busybox-sa —> service(ns: default): GET – httpbin.default.svc.cluster.local/ : Toang
ko match rule nào cả
– Cùng ns = default, có SA = busybox-sa —> service(ns: default): GET – httpbin-1.default.svc.cluster.local/ : OK
chúng chỉ apply author cho workload app: httpbin

action trên Workload: ns = default, có SA = busybox-sa

Có Điều lưu ý là phần ALLOW với ver 1.9.7 thì nếu ko có selector -> matchLabels nó sẽ không allow, kiểu phải chỉ rõ mày muốn allow cho ai và tao sẽ chặn all

Nếu bạn ko chỉ định rõ workload nào được áp allow và chỉ có namespace thì sẽ như bên dưới.

1.1.2) Action DENY

Với action: DENY thì sẽ allow All and chỉ deny chặn một vài workload cụ thể.

Vẫn bài lab ở trên chúng ta sẽ chuyển action thành deny:

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  labels:
    app.kubernetes.io/instance: author-default-httpbin
  name: author-default
  namespace: default
spec:
  action: DENY
  rules:
    - from:
        - source:
            namespaces:
              - default
              - go-demo-8
            principals:
              - cluster.local/ns/default/sa/busybox-sa
        - source:
            namespaces:
              - sample
            principals:
              - cluster.local/ns/sample/sa/busybox-sa
      to:
        - operation:
            methods:
              - GET
            paths:
              - /ip
              - /status*
  selector:
    matchLabels:
      app: httpbin

Namspace và Service account (source):
– EndUser –> Gw(http://fleetman-webapp.nimtechnology.com) -> Vs -> Svc(httpbin) -> Deployment(app: httpbin) OK
– EndUser –> Gw(http://fleetman-webapp.nimtechnology.com) -> Vs -> Svc(httpbin) -> Deployment(app: httpbin) OK
– Cùng ns = default, có SA = busybox-sa —> service: GET – httpbin.default.svc.cluster.local/ip : Toang
– Cùng ns = default, có SA = busybox-sa —> service: GET – fleetman-webapp.nimtechnology.com/ip : OK
– Cùng ns = default, có SA = busybox-sa —> service: GET – httpbin.default.svc.cluster.local/status/200 : Toang
– Cùng ns = default, có SA = busybox-sa —> service: GET – httpbin.default.svc.cluster.local/ : OK
– Cùng ns = default, có SA = busybox-sa-1 —> service: GET – httpbin.default.svc.cluster.local/ip : OK
– Khác ns = sample, có SA = busybox-sa —> service: GET – httpbin.default.svc.cluster.local/ip : Toang
– Cùng ns = sample, có SA = busybox-sa —> service: GET – httpbin.default.svc.cluster.local/status/200 : Toang

– Cùng ns = default, có SA = busybox-sa —> service: GET – httpbin-1.default.svc.cluster.local/ip : OK

1.1.3) Action AUDIT

A request will be internally marked that it should be audited if there is an AUDIT policy on the workload that matches the request. A separate plugin must be configured and enabled to actually fulfill the audit decision and complete the audit behavior. The request will not be audited if there are no such supporting plugins enabled. Currently, the only supported plugin is the Stackdriver plugin.

Mình không có stackdriver nên là ko lab được

1.1.4) Action CUSTOM


Note: The CUSTOM action is currently an experimental feature and is subject to breaking changes in later versions.
Thấy dòng trên là không lab được òi

1.2) Authorization Policy follow nimtechnology ways

1.2.1) Normal

Bạn có thể thấy đa số khi workload A call sang workload B thì dev sẽ call sang domain được cấu hình trên GW istio.
Chúng ta cần sử dụng JWT

Tạo RequestAuthentication apply vào ingressgateway

apiVersion: security.istio.io/v1beta1
kind: RequestAuthentication
metadata:
  name: req-authen-ingressgateway-jwt
  namespace: istio-system
spec:
  selector:
    matchLabels:
      istio: ingressgateway
  jwtRules:
  - issuer: "testing@secure.istio.io"
    jwksUri: "https://raw.githubusercontent.com/istio/istio/release-1.11/security/tools/jwt/samples/jwks.json"

issuer: nó có liên quan đến jwksUri
jwksUri: jwks.json trên github ????

Tạo AuthorizationPolicy

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: author-ingress-gateway-jwt
  namespace: istio-system
spec:
  selector:
    matchLabels:
      istio: ingressgateway
  action: DENY
  rules:
  - from:
    - source:
        notRequestPrincipals: ["*"]

Ý nghĩ của Author Policy là deny tất cả các request mà ko có header Authorization

Giờ chúng ta thực hiện curl để hiểu hơn:

curl -sS fleetman-webapp.nimtechnology.com/get -v
Chặn luôn các bạn ạ. status 403 Forbidden
curl --header "Authorization: Bearer nimtechnology" -sS fleetman-webapp.nimtechnology.com/get -v
header Author với bearer token lấy đại
response 401 – Lỗi authen
TOKEN=$(curl https://raw.githubusercontent.com/istio/istio/release-1.11/security/tools/jwt/samples/demo.jwt -s)

curl --header "Authorization: Bearer $TOKEN" -sS fleetman-webapp.nimtechnology.com/get -v
token đúng nền là response 200 OK

Giờ thử decode jwt sem payload là gì
TOKEN=$(curl https://raw.githubusercontent.com/istio/istio/release-1.11/security/tools/jwt/samples/demo.jwt -s)

1.2.2) Per Path

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: author-ingress-gateway-jwt
  namespace: istio-system
spec:
  selector:
    matchLabels:
      istio: ingressgateway
  action: DENY
  rules:
  - from:
    - source:
        notRequestPrincipals: ["*"]
    to:
    - operation:
        paths: ["/get"]

1.2.3) a JWT access a few hosts

Nhưng các lab ở 2.1 và 2.2 chúng ta thấy là chỉ cần có bearer token JWT thì EndUser có thể truy cập hosts trên Gateway.
Vậy nếu chúng ta muốn là Only User A –> access –> host: fleetman-webapp.nimtechnology.com
Thì chúng ta cần dùng tới khái niệm là: HTTP header Attribute

Khi mà decode bearer token

This image has an empty alt attribute; its file name is image-170.png
>>>trong ví dụ này mình sử dụng:
notRequestPrincipals: ["iss/sub"]
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: author-ingress-gateway-jwt-attribute
  namespace: istio-system
spec:
  selector:
    matchLabels:
      istio: ingressgateway
  action: DENY
  rules:
  - from:
    - source:
        notRequestPrincipals: ["testing@secure.istio.io/testing@secure.istio.io"]
    to:
      - operation:
          paths: ["/get"]
          hosts: ["fleetman-webapp.nimtechnology.com"]

Chúng ra sẽ thấy chỉ có:
iss: testing@secure.istio.io
sub: testing@secure.istio.io
–> access vào http://fleetman-webapp.nimtechnology.com/get

curl --header  -sS fleetman-webapp.nimtechnology.com/get -v
Không có token là 403

TOKEN=$(curl https://raw.githubusercontent.com/istio/istio/release-1.11/security/tools/jwt/samples/demo.jwt -s)

curl --header "Authorization: Bearer $TOKEN" \
--header "x-token: test" \
-sS fleetman-webapp.nimtechnology.com/get -v
Token JWT, iss/sub đúng là sẽ access được
TOKEN=$(curl https://raw.githubusercontent.com/istio/istio/release-1.11/security/tools/jwt/samples/demo.jwt -s)

>>>Đưa token tào lao dô
curl --header "Authorization: Bearer nimtechnology" \
-sS fleetman-webapp.nimtechnology.com/get -v
Lỗi xác thực 404 ngay

Hiện tại mình apply author trên paths /get
Bạn curl fleetman-webapp.nimtechnology.com hay fleetman-webapp.nimtechnology.com/ip đều được nhé
links tham khảo siêu hay mới tìm được:
https://istiobyexample.dev/jwt/

1.2.4) HTTP header Attribute
Bạn thực hiện thêm và check các header trong phần AuthorizationPolicy

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: author-ingress-gateway-attribute
  namespace: istio-system
spec:
  selector:
    matchLabels:
      istio: ingressgateway
  action: DENY
  rules:
  - to:
      - operation:
          paths: ["/get"]
          hosts: ["fleetman-webapp.nimtechnology.com"]
    when:
      - key: request.headers[x-token]
        notValues: ["admin"]
curl --header  -sS fleetman-webapp.nimtechnology.com/get -v
403 luôn vì ko có header
curl --header "x-token: admin" \
-sS fleetman-webapp.nimtechnology.com/get -v
Có header và value đúng là 200OK

Nếu bạn muốn tăng độ khó cho game thì có thể sài mix 2.3 và 2.4

1.2.5) Source IP

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: author-ingress-gateway-jwt-attribute
  namespace: istio-system
spec:
  selector:
    matchLabels:
      istio: ingressgateway
  action: DENY
  rules:
  - from:
    - source:
        ipBlocks: ["$CLIENT_IP"]

Cái này block IP

Links các file yaml
https://github.com/mrnim94/recheck-instio/tree/main/authen-author-istio

Isito-EnvoyFilter

Post navigation

Previous Post: [Udemy] Download khóa học Udemy giá rẻ chỉ với 50k/khóa
Next Post: [Prometheus] Relabelling – Đưa thông tin từ Discovered Label sang target label

More Related Articles

[Isito] FIX status 503 – SSL routines:OPENSSL_internal:CERTIFICATE_VERIFY_FAILED Isito-EnvoyFilter
[VictoriaMetrics/Grafana/Prometheus/Kiali] VictoriaMetrics is a fast, cost-effective and scalable time series database Grafana
[Grafana/Prometheus/Istio] How does prometheus get istio metrics? Isito-EnvoyFilter
[istio] Discover route TCP in Cluster Istio Isito-EnvoyFilter
[Istio/Recheck] Hướng dẫn kiểm tra các feature của cụm istio mới cài lên đã work ngon lành chưa? Isito-EnvoyFilter
[istio] Sử dụng istio-operator và istioctl để cài đặt Istio Isito-EnvoyFilter

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

Tham Gia Group DevOps nhé!
Để Nim có nhiều động lực ra nhiều bài viết.
Để nhận được những thông báo mới nhất.

Recent Posts

  • [Azure] The subscription is not registered to use namespace ‘Microsoft.ContainerService’ May 8, 2025
  • [Azure] Insufficient regional vcpu quota left May 8, 2025
  • [WordPress] How to add a Dynamic watermark on WordPress. May 6, 2025
  • [vnet/Azure] VNet provisioning via Terraform. April 28, 2025
  • [tracetcp] How to perform a tracert command using a specific port. April 3, 2025

Archives

  • May 2025
  • April 2025
  • March 2025
  • February 2025
  • January 2025
  • December 2024
  • November 2024
  • October 2024
  • September 2024
  • August 2024
  • July 2024
  • June 2024
  • May 2024
  • April 2024
  • March 2024
  • February 2024
  • January 2024
  • December 2023
  • November 2023
  • October 2023
  • September 2023
  • August 2023
  • July 2023
  • June 2023
  • May 2023
  • April 2023
  • March 2023
  • February 2023
  • January 2023
  • December 2022
  • November 2022
  • October 2022
  • September 2022
  • August 2022
  • July 2022
  • June 2022
  • May 2022
  • April 2022
  • March 2022
  • February 2022
  • January 2022
  • December 2021
  • November 2021
  • October 2021
  • September 2021
  • August 2021
  • July 2021
  • June 2021

Categories

  • BareMetal
    • NextCloud
  • CI/CD
    • Argo Events
    • ArgoCD
    • ArgoWorkflows
    • Git
      • Bitbucket
    • Harbor
    • Jenkins
    • Spinnaker
    • TeamCity
  • Coding
    • DevSecOps
    • Golang
    • Jquery & JavaScript
    • Laravel
    • NextJS 14 & ReactJS & Type Script
    • Python
    • Selenium
    • Terraform
      • AWS – Amazon Web Service
      • Azure Cloud
      • GCP – Google Cloud
  • Kubernetes & Container
    • Apache Kafka
      • Kafka
      • Kafka Connect
      • Lenses
    • Docker
    • Helm Chart
    • Isito-EnvoyFilter
    • Kong Gateway
    • Kubernetes
      • Ingress
      • Pod
    • Longhorn – Storage
    • MetalLB
    • OAuth2 Proxy
    • Vault
    • VictoriaMetrics
  • Log, Monitor & Tracing
    • DataDog
    • ELK
      • Kibana
      • Logstash
    • Fluent
    • Grafana
    • Prometheus
  • Uncategorized
  • Admin

Copyright © 2025 NimTechnology.