NetworkPolicy cho ứng dụng dùng proxy giới hạn egress

NetworkPolicy cho ứng dụng dùng proxy giúp giới hạn kết nối ra của Pod ở lớp mạng khi CNI hỗ trợ thực thi. Anh em cần tách chính sách cho phép tới gateway khỏi cấu hình proxy trong ứng dụng, đồng thời kiểm cả DNS và đường đi trực tiếp. ProxyVN hướng dẫn anh em kiểm đúng lớp gây lỗi và giữ bằng chứng trước khi thay cấu hình.

NetworkPolicy cho ứng dụng dùng proxy và hai lớp cấu hình

NetworkPolicy quyết định các kết nối mạng được phép theo khả năng của CNI, còn ứng dụng quyết định có sử dụng proxy hay không. Cho phép TCP tới địa chỉ gateway không tự đặt HTTP_PROXY cho tiến trình. Ngược lại, đặt biến môi trường không ngăn thư viện đi trực tiếp nếu nó không đọc biến đó. Một thiết kế giới hạn egress cần cả hai lớp: cấu hình client đúng và kiểm soát mạng đúng với tác vụ được triển khai.

Tài liệu Network Policies của Kubernetes là nguồn nền cho đối tượng NetworkPolicy. Chính sách chỉ có tác dụng khi mạng của cụm có cơ chế thực thi tương ứng. Việc API server nhận manifest không chứng minh gói tin đã bị chặn. Vì vậy, bước nghiệm thu quan trọng là một kết nối trực tiếp trước đó hoạt động phải bị chặn theo thiết kế, trong khi kết nối qua gateway được phép vẫn hoàn thành tác vụ thử.

Ranh giới với cấu hình runtime tải image

Image của container thường được node và runtime tải trước khi tiến trình ứng dụng chạy trong Pod. Chính sách egress áp cho Pod không nên được xem là cấu hình proxy cho containerd, CRI hay kubelet. Một Pod khởi động được chỉ chứng minh image đã sẵn có hoặc được tải qua cơ chế của node. Nó chưa xác nhận request HTTP của ứng dụng đi qua gateway. Hai tuyến cần bảng kiểm và chủ sở hữu cấu hình riêng.

Tương tự, một image pull thất bại không nên làm nhóm sửa NetworkPolicy của ứng dụng ngay. Hãy kiểm sự kiện Pod, trạng thái image và cấu hình node trước. Nếu container đã chạy nhưng gọi API không được, mới đi vào ca egress của tiến trình. Việc phân giai đoạn giúp tránh thay một policy đang đúng để chữa lỗi xảy ra trước khi policy đó có cơ hội ảnh hưởng tới tác vụ.

NetworkPolicy chuẩn không phải bộ lọc URL

API chuẩn mô tả peer và cổng theo các trường được hỗ trợ; không tự cung cấp cơ chế cho phép một hostname tùy ý rồi theo mọi IP mà hostname đó phân giải. Nó cũng không kiểm đường dẫn URL hay nội dung HTTP theo cách một gateway ứng dụng có thể làm. Nếu cần giới hạn origin được truy cập qua proxy, phải có chính sách phù hợp tại proxy hoặc một cơ chế được thiết kế cho lớp đó. Đừng gán khả năng lọc URL cho một rule TCP.

Một số CNI có mở rộng riêng về tên miền hoặc lớp ứng dụng, nhưng đó là API và cơ chế của sản phẩm, không phải khả năng chung của NetworkPolicy chuẩn. Khi dùng mở rộng, cần tài liệu đúng phiên bản, manifest đúng loại tài nguyên và ca kiểm riêng. Bài này giữ phạm vi API networking.k8s.io/v1 để người đọc không nhầm một cấu hình đặc thù thành cấu hình có thể mang sang mọi cụm.

NetworkPolicy cho ứng dụng dùng proxy và điều kiện lab

Chuẩn bị một namespace thử riêng, một Pod client có công cụ HTTP đã biết và một gateway lab có địa chỉ cùng cổng ổn định. Endpoint đích phải thuộc quyền kiểm hoặc được phép thử. Ghi phiên bản Kubernetes, CNI và cách DNS được triển khai, vì chúng ảnh hưởng việc chọn peer cũng như đường đi. Không áp manifest minh họa vào namespace đang phục vụ chỉ để xem hệ thống có ngừng truy cập Internet hay không.

Xác nhận mốc trước khi tạo policy

Trước policy, kiểm DNS, kết nối trực tiếp tới origin và kết nối qua gateway bằng cùng một payload nhỏ. Nếu mốc trực tiếp đã thất bại từ đầu, nó không chứng minh deny egress có hiệu lực sau đó. Nếu mốc proxy chưa hoạt động, policy không phải lớp đầu cần sửa. Lưu status và một giá trị nhận diện response của origin để tránh coi trang lỗi trung gian là đầu ra thành công.

Một Pod kiểm cần được gắn label riêng mà policy chọn đúng. Không dùng selector rỗng trên toàn namespace chỉ vì tiện nếu mục tiêu là một client thử. Đồng thời, kiểm các policy khác đang chọn Pod; các quyền cho phép có thể cộng lại. Một policy cho phép rộng còn tồn tại có thể làm ca trực tiếp vẫn thành công dù manifest mới nhìn có vẻ rất hạn chế. Phải đánh giá tập chính sách hiệu lực, không chỉ tệp vừa apply.

IP của proxy cần có cách quản lý

Với gateway bên ngoài cụm, ipBlock có thể minh họa một địa chỉ được phép, nhưng địa chỉ phải được thay bằng IP lab thực và có quản lý thay đổi. Tên DNS trả nhiều IP hoặc thay đổi theo thời gian không tự cập nhật rule /32. Nếu nhà cung cấp thay endpoint, quy trình cần xác nhận danh sách hợp lệ và cập nhật có kiểm soát. Không nới thành toàn Internet chỉ để tránh quản lý địa chỉ.

Với proxy là Pod trong cụm, có thể dùng namespaceSelector và podSelector phù hợp thay vì IP động của Pod. Hai selector trong cùng một phần tử có quan hệ kết hợp; tách thành các phần tử có thể làm phạm vi khác đi. Hãy kiểm YAML sau render để hiểu chính xác tập peer được chọn. Một lỗi thụt lề có thể làm policy vẫn hợp lệ về cấu trúc nhưng rộng hơn mục tiêu của người viết.

Policy mạng và cấu hình client

NetworkPolicy cho ứng dụng dùng proxy trong manifest minh họa

Mẫu dưới chỉ chọn Pod có label app: proxy-client trong namespace proxy-lab. Egress được giới hạn tới DNS Pod theo label của cụm và một IP proxy minh họa ở TCP 3128. Địa chỉ 198.51.100.10 là dữ liệu tài liệu, phải thay bằng IP lab được phép trước khi chạy. Không có tuyên bố địa chỉ đó là gateway đang hoạt động hoặc thuộc ProxyVN.

DNS selector trong ví dụ cần đối chiếu với label và kiến trúc thực. Nếu dùng NodeLocal DNSCache hoặc một dịch vụ DNS có đường đi khác, rule trên có thể không chọn đúng nơi nhận gói tin. Không chữa bằng cách mở UDP toàn bộ địa chỉ mà chưa xác định nguyên nhân. Hãy xem cấu hình resolver của Pod và tài liệu CNI để hiểu điểm áp policy, sau đó viết peer hẹp phù hợp với cụm lab.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: client-egress-via-proxy
  namespace: proxy-lab
spec:
  podSelector:
    matchLabels:
      app: proxy-client
  policyTypes:
    - Egress
  egress:
    - to:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: kube-system
          podSelector:
            matchLabels:
              k8s-app: kube-dns
      ports:
        - protocol: UDP
          port: 53
        - protocol: TCP
          port: 53
    - to:
        - ipBlock:
            cidr: 198.51.100.10/32
      ports:
        - protocol: TCP
          port: 3128

Áp dụng trong namespace thử

kubectl get networkpolicy -n proxy-lab -o yaml
kubectl get pod -n proxy-lab --show-labels
kubectl apply --dry-run=server -f client-egress.yaml
kubectl apply -f client-egress.yaml
kubectl describe networkpolicy client-egress-via-proxy -n proxy-lab

Dry run phía server kiểm việc API chấp nhận đối tượng theo khả năng của cụm, không kiểm gói tin bị chặn. Describe giúp đọc selector và rule đã lưu, cũng chưa thay ca mạng. Hướng dẫn khai báo NetworkPolicy cung cấp quy trình nền để làm việc với đối tượng. Anh em vẫn cần chạy client thực trong Pod mục tiêu và kiểm đầu ra tại origin hoặc gateway lab sau khi policy đã được hệ thống thực thi.

Những phần mẫu chưa triển khai

Mẫu không tạo namespace, Pod client, DNS hay proxy; các tài nguyên đó là đầu vào cần chuẩn bị. Nó chỉ giới hạn egress của Pod được chọn, không đặt chính sách ingress cho proxy trong cụm. Nếu proxy nội bộ cũng bị ingress isolation, phải có rule cho phép từ client theo thiết kế. Không thêm rule ingress rộng vào namespace khác chỉ để làm ca dương chạy được; xác định bên sở hữu và phạm vi cần mở.

Mẫu cũng không cấu hình auth, TLS CA hay bộ lọc origin ở gateway. Các phần đó cần được cấp theo cơ chế bí mật và hợp đồng của ứng dụng. Khi một ca lỗi trả 407, nghĩa là cần kiểm xác thực ở proxy, không nên mở thêm cổng egress để sửa. Khi lỗi certificate xuất hiện sau khi nối tới gateway, giữ kiểm chứng chỉ và xử lý trust ở đúng tiến trình thay vì tắt xác minh cho toàn bộ Pod.

NetworkPolicy cho ứng dụng dùng proxy và bộ test allow deny

Bộ kiểm cần ít nhất một ca đi trực tiếp, một ca qua proxy đúng và một ca tới địa chỉ hoặc cổng ngoài phạm vi. Các ca dùng kết nối mới với thời hạn kết thúc để tránh treo. Không chỉ ping, vì policy cho TCP ứng dụng không thể được nghiệm thu bằng một giao thức khác. Phép đo nên gắn với thao tác HTTP mà workload thật cần thực hiện và có đầu ra nhận diện từ origin thử.

Gọi từ đúng Pod và đúng container

# Replace pod name, origin and proxy URL with approved lab values.
kubectl exec -n proxy-lab proxy-client -- curl --noproxy '*' --max-time 5 https://origin.lab.test/probe
kubectl exec -n proxy-lab proxy-client -- curl --proxy http://PROXY_IP:3128 --noproxy '' --max-time 5 https://origin.lab.test/probe

Hai lệnh là mẫu Bash cho một client curl trong container, không phải kết quả đã chạy trên mọi cụm. Cần thay PROXY_IP và origin bằng địa chỉ lab hợp lệ, cùng CA phù hợp nếu dùng chứng chỉ thử. Nếu Pod có nhiều container, chỉ định container cần kiểm theo lệnh kubectl. Một sidecar hoặc container debug có cấu hình khác có thể không đại diện tiến trình ứng dụng, nên phải ghi nơi thực thi trong biên bản.

Kết quả cần có trước khi triển khai thật

Manifest cùng bảng trên là thiết kế kiểm thử minh họa, chưa có kết quả thực thi trên cụm Kubernetes và CNI đi kèm. Vì vậy, chúng chưa phải bằng chứng policy đã chặn được kết nối. Phần kiểm thực thi cần được hoàn thành trên cluster lab trước khi dùng làm cấu hình vận hành. Việc không có kết quả runtime ở đây phải được giữ rõ; không điền thành công chỉ từ YAML hợp lệ hoặc nội dung tài liệu chính thức.

Nếu ca trực tiếp vẫn chạy, kiểm Pod có đúng label, namespace và tập policy nào đang chọn nó. Tiếp theo xác nhận CNI thực hỗ trợ NetworkPolicy egress. Chỉ sau đó mới xem những nhánh đặc thù như hostNetwork hoặc tuyến qua node theo tài liệu sản phẩm. Không nới ca dương để che ca âm thất bại; cả hai cùng cần đạt mới chứng minh được ranh giới mạng mà thiết kế đặt ra.

Manifest egress tới gateway

NetworkPolicy cho ứng dụng dùng proxy và DNS

DNS là một kết nối mạng riêng, nhưng không phải mọi mô hình proxy đều cần client phân giải origin theo cùng cách. Một HTTP forward proxy có thể nhận hostname đích rồi phân giải tại nơi nó chạy; client vẫn cần tìm địa chỉ proxy nếu dùng tên cho gateway. Hãy xác định hostname nào được phân giải ở đâu để không mở quyền DNS rộng hơn nhu cầu hoặc chẩn đoán nhầm lỗi phân giải ở gateway thành lỗi resolver trong Pod.

Resolver của Pod là dữ kiện đầu vào

Kiểm cấu hình resolver trong Pod và đường đi tới dịch vụ DNS của cụm theo tài liệu DNS cho Services và Pods. Không giả định mọi cụm dùng cùng địa chỉ hoặc label. Trong mạng có cache trên node, gói tin có thể đi qua một cơ chế khác với sơ đồ Service thông thường. Cần tài liệu CNI và cấu hình cụ thể để chọn rule đúng, nhất là khi policy xử lý trước hoặc sau các bước chuyển đổi địa chỉ.

Cho phép DNS cũng không đồng nghĩa cho phép mọi origin mà DNS trả về. Với API chuẩn, rule IP tới proxy vẫn là tập mạng riêng. Nếu ứng dụng cố đi trực tiếp tới IP origin vừa phân giải, ca âm phải cho thấy nó bị chặn theo thiết kế. Sự tách biệt này là lý do cần kiểm cả kết nối trực tiếp lẫn qua gateway, thay vì chỉ xác nhận nslookup thành công rồi coi toàn bộ egress đã đúng.

DNS là ngoại lệ cần được mô tả

Một thiết kế nói chỉ cho Pod tới proxy nhưng vẫn cần DNS phải nêu ngoại lệ đó. Không nên viết rằng chỉ có duy nhất một IP được phép nếu manifest còn cho DNS ở một tập peer khác. Mô tả chính xác giúp nhóm bảo mật và vận hành đọc cùng một ranh giới. Nếu ứng dụng không cần DNS cho một ca dùng IP proxy cố định, vẫn cần cân nhắc các chức năng khác của workload trước khi bỏ quyền phân giải.

Khi DNS lỗi, dùng một ca kiểm DNS riêng để tránh lẫn với HTTP. Nếu tên proxy không phân giải, client có thể chưa mở kết nối tới IP nào, nên log gateway rỗng là điều dự kiến. Nếu proxy phân giải origin lỗi, client có thể nhận một response từ proxy. Hai trường hợp cần thông tin khác nhau; việc ghi hostname cần phân giải và điểm thực hiện giúp đội hỗ trợ xác định đúng lớp cần kiểm.

NetworkPolicy cho ứng dụng dùng proxy và các giới hạn vận hành

Policy có thể được tạo hoặc thay đổi trong khi kết nối cũ còn tồn tại. Hành vi với kết nối đang mở cần kiểm theo triển khai, nên ca nghiệm thu ranh giới mới nên dùng kết nối mới. Một request thành công trên kết nối đã có trước khi áp không đủ để kết luận policy không có hiệu lực. Ngược lại, chỉ một request thất bại cũng chưa chứng minh deny đúng nếu gateway lab lúc đó đang ngừng phục vụ.

NAT và địa chỉ tại điểm áp policy

Khi có Service, NAT hoặc định tuyến qua node, địa chỉ mà một rule quan sát có thể chịu ảnh hưởng của triển khai mạng. Không suy ra từ ClusterIP hiển thị rằng ipBlock luôn khớp đúng theo cách anh em mong muốn. Đọc tài liệu CNI, kiểm endpoint thực và dùng log mạng được hệ thống cung cấp. Nếu cần debug dịch vụ, hướng dẫn Kubernetes về Services giúp tổ chức các bước kiểm thay vì sửa policy ngẫu nhiên.

Với proxy nội bộ, selector theo Pod và namespace thường mô tả ý định rõ hơn việc ghim IP Pod thay đổi, nhưng vẫn phải xem ingress của bên nhận. Đối với proxy ngoài cụm, cần quản lý IP và cổng được cấp. Không trộn hai mô hình trong cùng một kết luận hỗ trợ. Bảng kiến trúc nên nêu peer nằm trong cluster hay bên ngoài và ai chịu trách nhiệm cập nhật khi địa chỉ thay đổi.

Chính sách cộng thêm và quyền thay label

Các policy cho phép có thể cộng lại, nên một rule rộng từ tệp khác có thể mở quyền mà tệp hiện tại không nêu. Khi bàn giao, xuất tập policy liên quan và kiểm selector của chúng. Không chỉ giữ bản manifest mới trong repository rồi bỏ qua trạng thái thực của namespace. Một quy trình quản lý cấu hình cần phát hiện khác biệt giữa ý định và đối tượng đã lưu, nhất là khi nhiều nhóm cùng triển khai workload vào một không gian dùng chung.

Label là một phần của mô hình chọn đối tượng, nên quyền thay label và quyền tạo tài nguyên cũng cần được quản lý trong kiến trúc chung. NetworkPolicy không thay RBAC hoặc cơ chế quản lý workload. Một người có quyền tạo Pod ngoài selector có thể không bị cùng rule chọn theo thiết kế hiện tại. Bài kiểm phải giới hạn kết luận ở workload mục tiêu và được xem cùng các lớp quản trị khác, không gọi một policy là giải pháp bảo vệ toàn cụm.

Bảng kiểm allow deny

NetworkPolicy cho ứng dụng dùng proxy và quản lý bí mật

Manifest mạng không cần chứa user và password của gateway. Cấu hình ứng dụng có thể tham chiếu Secret hoặc cơ chế cấp bí mật được tổ chức dùng, nhưng phải kiểm thư viện thực đọc giá trị đó. Không coi việc Pod có biến HTTP_PROXY là bằng chứng client đã dùng nó. Một số runtime cần tùy chọn riêng hoặc không áp biến cho mọi giao thức, nên ca dương phải là request thực của đúng tiến trình.

Tách auth proxy và auth origin

Credential gateway phục vụ việc nối qua proxy, còn token API phục vụ quyền tại origin. Không đặt bearer token của API vào URL proxy hoặc thêm Proxy-Authorization vào request nghiệp vụ bằng cách thủ công không kiểm phạm vi. Khi client báo 407, kiểm nguồn cấp auth gateway; khi API báo thiếu quyền, kiểm danh tính ở origin. Mở thêm egress không giải quyết hai cơ chế auth này và có thể làm ranh giới mạng rộng ngoài mục tiêu.

Nếu cần mua proxy cho workload được phép, anh em nên xác nhận giao thức, endpoint và cơ chế xác thực có thể dùng từ môi trường cluster. Các hướng dẫn định dạng proxy và no_proxy giúp chuẩn bị cấu hình client. Chúng không chứng minh CNI đã chặn đường trực tiếp hoặc gateway có chính sách origin phù hợp; các phần đó cần phép kiểm riêng.

Hoàn nguyên trong đúng namespace lab

Trước khi thay, lưu tên policy và giá trị cấu hình client ban đầu của môi trường thử. Khi dọn, chỉ xóa tài nguyên lab đã tạo và kiểm không còn worker thử chạy nền. Không dùng lệnh xóa mọi NetworkPolicy của namespace dùng chung để quay về mốc. Nếu policy thuộc một hệ quản lý cấu hình, hoàn nguyên qua nguồn quản lý phù hợp để tránh nó tự được tạo lại hoặc trạng thái thực lệch với repository.

Sau hoàn nguyên, chạy lại mốc kết nối đã xác định theo mục tiêu lab. Ghi ca nào đã được kiểm thực thi, ca nào chỉ kiểm cấu trúc và thông tin CNI còn thiếu. Hồ sơ nên có manifest, label, peer thực, cổng, kết quả allow/deny và log đã che bí mật. Khi chưa có phép thử cluster, giữ trạng thái chờ kiểm thay vì chuyển thiết kế thành lời cam kết vận hành đã được xác minh.

NetworkPolicy cho ứng dụng dùng proxy và thay đổi endpoint

Một gateway có IP ổn định giúp rule dễ kiểm, nhưng vận hành vẫn cần dự tính thay đổi. Khi đổi endpoint, chuẩn bị một ca dương với địa chỉ mới trong namespace lab, kiểm auth và đầu ra rồi mới cập nhật workload theo quy trình. Không xóa địa chỉ cũ trước khi biết những Pod nào còn dùng nó nếu hệ thống cần chuyển dần. Đồng thời, thời gian hai địa chỉ cùng được phép phải được xác định để ngoại lệ chuyển đổi không trở thành quyền tồn tại lâu hơn nhu cầu.

Phối hợp rollout ứng dụng và policy

Policy và Deployment có thể được áp bởi hai quy trình khác nhau. Nếu ứng dụng nhận endpoint mới trước khi policy cho phép, nó sẽ lỗi dù từng tệp riêng đều đúng. Nếu policy mở thêm địa chỉ trước nhưng ứng dụng chưa dùng, ca kiểm vẫn cần xác nhận địa chỉ cũ hoạt động trong giai đoạn chuyển. Kế hoạch rollout nên mô tả thứ tự, điều kiện dừng và thời điểm gỡ quyền cũ, thay vì chỉ gom hai tệp vào một thay đổi rồi hy vọng chúng có hiệu lực đồng thời.

Khi có nhiều replica, kiểm cấu hình trên các phiên bản Pod đang tồn tại. Một request từ Pod mới không đại diện Pod cũ còn chạy, và một Pod debug mới tạo có thể chưa mang đúng label hoặc cấu hình. Dùng danh sách Pod mục tiêu cùng revision để chọn ca kiểm. Nếu hệ thống có connection pooling, thêm ca kết nối mới sau rollout nhằm tránh nhầm một kết nối đã mở từ trước với việc endpoint mới đã được phép đúng cách.

IPv4 IPv6 cần được đưa vào phạm vi

Một rule IP phiên bản bốn không tự mô tả peer phiên bản sáu. Nếu cluster hoặc gateway có dual stack, cần kiểm các địa chỉ thực được client chọn và chính sách tương ứng. Không kết luận đường trực tiếp bị chặn chỉ từ một lần gọi chọn IPv4 khi ứng dụng có thể mở kết nối theo họ địa chỉ khác. Tài liệu CNI và kiến trúc cluster phải chỉ ra phạm vi cần kiểm; nếu môi trường chỉ có một họ địa chỉ, ghi đúng phạm vi đó trong biên bản.

Tương tự, một hostname trả nhiều địa chỉ có thể làm các lượt chọn peer khác nhau. Ghi đích thực của ca nếu công cụ hỗ trợ, rồi đối chiếu với tập được phép. Nếu không quan sát được địa chỉ lựa chọn, dùng một peer lab cố định cho mốc đầu trước khi kiểm tên có nhiều bản ghi. Không thêm cả dải lớn vào ipBlock chỉ vì chưa biết địa chỉ nào được chọn; cần làm rõ dữ kiện trước khi nới quyền.

Kiểm thêm cổng không được phép

Ca âm nên thay cổng trên cùng một IP được kiểm soát và có listener đối chứng phù hợp. Nếu không có dịch vụ ở cổng đó, kết nối thất bại không chứng minh policy đã chặn; nó có thể đơn giản là không ai lắng nghe. Trước policy, xác nhận ca âm từng tới được listener lab, sau đó kiểm nó bị chặn theo thiết kế. Bằng chứng này làm rõ ý nghĩa của thất bại và tránh việc dùng một địa chỉ không tồn tại làm kết quả deny.

Giữ cả ca dương sau ca âm để xác nhận proxy lab vẫn hoạt động. Một firewall khác hoặc sự cố node có thể làm mọi kết nối đều lỗi, khiến bảng nhìn như policy rất chặt trong khi tác vụ cần thiết cũng không chạy. Điều kiện đạt cần có cả đúng phần bị chặn và đúng phần được cho phép. Nếu một trong hai thiếu bằng chứng, giữ trạng thái cần điều tra thay vì đánh dấu chính sách sẵn sàng cho workload thật.

Theo dõi ngoại lệ sau bàn giao

Một ngoại lệ tạm cho DNS khác, gateway dự phòng hoặc cổng kiểm nên có chủ sở hữu và lý do. Khi hết phép thử, rà các quyền đó trong tập policy hiệu lực, không chỉ trong tệp chính. Nếu dùng công cụ quản lý cấu hình, kiểm nguồn của đối tượng để thay đổi được giữ hoặc gỡ đúng quy trình. Danh sách ngoại lệ rõ giúp nhóm vận hành tiếp nhận thiết kế mà không phải đoán một rule rộng có còn cần cho ứng dụng hay chỉ là phần sót từ buổi debug.

Một policy chỉ được nghiệm thu bằng ranh giới kết nối thực, không chỉ bằng việc API chấp nhận YAML.

DNS và các ngoại lệ

Anh em nên giữ request mẫu, kết quả đối chứng và cấu hình đã che thông tin nhạy cảm để kiểm lại sau thay đổi. Theo dõi Proxy.vn - Nhà cung cấp dịch vụ proxy chất lượng hàng đầu Việt Nam để tham khảo nội dung liên quan. Khi triển khai, đánh giá đúng phạm vi của NetworkPolicy cho ứng dụng dùng proxy.