🛡️ Istio Security - Chi tiết

📑 Mục Lục

1. Tổng quan bảo mật Istio
2. Nhận dạng & Quản lý chứng chỉ
3. Xác thực (Authentication)
4. Ủy quyền (Authorization)
5. Các mô hình chính sách và ví dụ thực tế
6. Thực hành tốt và cảnh báo
7. Tài nguyên học thêm

🔍 Tổng quan bảo mật Istio

Istio hỗ trợ bảo mật toàn diện:

• Identity mạnh mẽ: sử dụng SPIFFE ID
• Mutual TLS: mã hóa và xác thực 2 chiều
• JWT Authentication: xác thực người dùng cuối
• Authorization Policies: kiểm soát truy cập đến từng dịch vụ
• Audit: theo dõi hoạt động truy cập

Mục tiêu:

• Zero Trust: không tin mặc định bất kỳ kết nối nào
• Defense in depth: bảo vệ nhiều lớp
• Không thay đổi mã ứng dụng: áp dụng bảo mật qua proxy

🆔 Nhận dạng & Quản lý chứng chỉ

• Mỗi workload được cấp một chứng chỉ X.509 có SPIFFE ID như:

  spiffe://cluster.local/ns/default/sa/reviews
  

• Quá trình cấp chứng chỉ:
  • Istio Agent → gửi CSR đến istiod
  • istiod → cấp cert và key
  • Envoy proxy → lấy cert/key từ SDS

🔐 Xác thực (Authentication)

Peer Authentication (mTLS)

• Tự động giữa các proxy Envoy
• Bật mTLS ở cấp độ namespace/workload
• Hỗ trợ chế độ PERMISSIVE, STRICT, DISABLE

Request Authentication (JWT)

• Xác thực người dùng cuối bằng JWT
• Hỗ trợ nhiều provider như:
  • Google Auth, Firebase, Keycloak, Auth0
• JWT có thể đến từ header hoặc query param

Ví dụ cấu hình:

apiVersion: security.istio.io/v1
kind: RequestAuthentication
metadata:
  name: jwt-auth
spec:
  jwtRules:
  - issuer: "https://accounts.google.com"
    jwksUri: "https://www.googleapis.com/oauth2/v3/certs"

✅ Ủy quyền (Authorization)

• Định nghĩa trong AuthorizationPolicy
• Hành động: ALLOW, DENY, CUSTOM
• Áp dụng ở các lớp: mesh-wide, namespace, workload

Cơ chế:

• Envoy proxy đánh giá yêu cầu theo rule
• Chính sách được lưu trong CRDs

Ví dụ:

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: allow-get
spec:
  selector:
    matchLabels:
      app: myapp
  action: ALLOW
  rules:
  - to:
    - operation:
        methods: ["GET"]

📋 Các mô hình chính sách và ví dụ thực tế

• Deny All: từ chối toàn bộ yêu cầu
• Allow Nothing: không định nghĩa rule (mặc định từ chối)
• Allow All: cho phép mọi yêu cầu
• Path-based: chỉ cho phép /api/*
• Principal-based: chỉ người dùng có JWT iss=google.com

Ví dụ cấm /admin nếu không có JWT:

action: DENY
rules:
- to:
  - operation:
      paths: ["/admin"]
  from:
  - source:
      notRequestPrincipals: ["*"]

🛠️ Thực hành tốt và cảnh báo

• Luôn bật STRICT mTLS cho dịch vụ nội bộ
• Kiểm tra xác thực bằng PERMISSIVE trước khi STRICT
• Luôn áp dụng deny first, rồi allow
• Tránh để trống AuthorizationPolicy, điều này sẽ allow all
• Tránh áp dụng rule HTTP cho TCP (MongoDB...)

📚 Tài nguyên học thêm

• Istio Authentication Tasks
• Istio Authorization Policy Reference
• Mutual TLS Migration Guide