Validating Admission Webhook là gì? Cơ chế và ứng dụng thực tế trong Kubernetes

Hãy tưởng tượng một cụm Kubernetes cho phép bất kỳ ai tạo tài nguyên tùy ý mà không có bước rà soát nào. Hậu quả là các cấu hình sai lệch, rủi ro bảo mật hay vi phạm quy định nội bộ dễ dàng lọt vào hệ thống. Để ngăn chặn điều này, Validating Admission Webhook ra đời như một "trạm kiểm soát" nghiêm ngặt, kiểm tra mọi request trước khi cho phép thực thi. 

Bài viết dưới đây, Viettel IDC sẽ giải thích chi tiết khái niệm này, cách phân biệt với Mutating Webhook và những ứng dụng thực tế nhất.

Validating Admission Webhook là gì?

Validating Admission Webhook là một loại admission controller trong Kubernetes, có nhiệm vụ kiểm tra một yêu cầu tạo, sửa, hoặc xóa tài nguyên ngay sau khi request đó đã vượt qua vòng xác thực quyền truy cập, nhưng trước khi được lưu chính thức vào cơ sở dữ liệu của hệ thống (etcd).

Điểm cốt lõi tạo nên bản chất của Validating Admission Webhook là nó chỉ có quyền chấp nhận (allow) hoặc từ chối (reject) request. Nó tuyệt đối không được phép chỉnh sửa, thêm bớt hay thay đổi nội dung của request đó.

Phân biệt Validating Admission Webhook và Mutating Admission Webhook

Cả hai đều là những Webhook được Kubernetes gọi đến trong quá trình xử lý request, nhưng chúng có vai trò và thời điểm hoạt động hoàn toàn khác nhau:

Vì sao thứ tự "Mutating trước, Validating sau" lại quan trọng?

Thiết kế này không phải là ngẫu nhiên. Việc Mutating Webhook chạy trước đảm bảo rằng mọi giá trị mặc định, các label tự động, hay các container bổ sung đều đã được "bơm" đầy đủ vào cấu hình của đối tượng. Khi đó, Validating Webhook sẽ chạy ở bước cuối cùng để kiểm duyệt phiên bản hoàn chỉnh nhất của đối tượng. Nếu Validating chạy trước, nó có thể bỏ sót những rủi ro bảo mật do Mutating Webhook vô tình chèn vào sau đó.

Cơ chế hoạt động Request đi qua Webhook như thế nào?

Luồng xử lý đầy đủ của một Request

Khi một kỹ sư gửi một lệnh (ví dụ: kubectl apply -f deployment.yaml), một chuỗi các sự kiện diễn ra bên trong Kubernetes API Server theo thứ tự cực kỳ nghiêm ngặt:

1. Xác thực và Cấp quyền (AuthN/AuthZ): Hệ thống kiểm tra chứng chỉ của kỹ sư, xem họ là ai và RBAC có cho phép họ tạo Deployment trong Namespace này không.

2. Mutating Admission: Các webhook can thiệp để tự động hóa (ví dụ: tự động tiêm thêm cấu hình thu thập Log).

3. Object Schema Validation: Kubernetes rà soát file YAML xem có viết sai lỗi chính tả, sai kiểu dữ liệu (String thay vì Integer) hay không.

4. Validating Admission: Webhook do tổ chức của bạn định nghĩa nhảy vào can thiệp để kiểm tra logic nghiệp vụ nội bộ.

5. Lưu vào etcd: Nếu tất cả các trạm đều giơ biển xanh "Pass", tài nguyên được khởi tạo thành công và lưu vào cơ sở dữ liệu.

Cách Webhook nhận và phản hồi

Bản chất của Webhook chỉ là một máy chủ API (HTTP/HTTPS Server) thông thường có thể viết bằng Go, Python, Node.js, chạy bên ngoài hoặc bên trong cụm dưới dạng một Pod. Khi có request cần kiểm tra, Kubernetes API Server sẽ đóng gói toàn bộ thông tin đối tượng thành một tệp JSON (gọi là đối tượng AdmissionReview) và gửi một POST request qua giao thức HTTPS bảo mật đến địa chỉ của dịch vụ Webhook.

Dịch vụ Webhook sẽ tiếp nhận file JSON, phân tích logic bên trong (ví dụ: quét xem có trường hostNetwork: true hay không), và trả lời API Server bằng một thông điệp phản hồi gồm hai thông tin cốt lõi:

- Allowed: true (Quyết định: Cho phép)

- Allowed: false (Quyết định: Từ chối). Đi kèm với đó là một thuộc tính Message chứa đoạn text giải thích nguyên nhân cặn kẽ để hiển thị thẳng lên màn hình terminal của người dùng.

Cấu trúc cơ bản của một Validating Admission Webhook

Để triển khai cơ chế này, có mã nguồn Webhook thôi là chưa đủ. Quản trị viên (Admin) phải khai báo cho Kubernetes API Server biết cách tìm và giao tiếp với Webhook đó thông qua một đối tượng đặc thù mang tên ValidatingWebhookConfiguration.

Một file cấu hình khai báo chuẩn thường bao gồm 3 thành phần cốt lõi:

1. Rules (Quy tắc đánh chặn): Xác định chính xác "vùng phủ sóng" của Webhook. Bạn chỉ định loại tài nguyên nào (Pod, Service, Ingress...), loại thao tác nào (chỉ khi CREATE, UPDATE hay cả DELETE) sẽ bị tóm lại để kiểm tra.

2. ClientConfig (Cấu hình kết nối): Cung cấp địa chỉ URL hoặc tên Service nội bộ để API Server biết cần gửi dữ liệu đến đâu. Phần này bắt buộc phải bao gồm caBundle (chứng chỉ bảo mật) vì Kubernetes yêu cầu mọi giao tiếp với Webhook phải được mã hóa qua TLS.

3. Failure Policy (Chính sách xử lý lỗi): Định nghĩa hành vi của toàn bộ hệ thống khi bản thân dịch vụ Webhook bị sập hoặc quá tải.

Tham số failurePolicy là lằn ranh mỏng manh giữa bảo mật và tính sẵn sàng. Nó quyết định mức độ cực đoan của cụm khi dịch vụ Webhook không thể phản hồi. Có 2 tùy chọn:

- Ignore (Bỏ qua): Nếu Webhook bị lỗi kết nối hoặc timeout, Kubernetes sẽ nhắm mắt cho qua và cho phép request tiếp tục đi vào hệ thống. Cách này đảm bảo ứng dụng luôn được deploy thông suốt (High Availability), nhưng rủi ro bảo mật có thể dễ dàng lọt lưới trong thời gian Webhook bảo trì.

- Fail (Chặn đứng): Nếu Webhook bị lỗi, request của người dùng sẽ bị từ chối hoàn toàn. Tính bảo mật được đảm bảo tuyệt đối 100%. Tuy nhiên, nếu Webhook cấu hình sai, bạn có thể vô tình đóng băng mọi hoạt động tạo tài nguyên trong cụm.

Ứng dụng thực tế của Validating Admission Webhook

Validating Webhook là công cụ mạnh mẽ nhất để "vá" những lỗ hổng quản trị mà bản thân Kubernetes nguyên bản không cung cấp sẵn.

Thực thi chính sách bảo mật

Theo cấu hình mặc định, Kubernetes cho phép các nhà phát triển tự do tùy biến. Validating Webhook giúp bộ phận Bảo mật (SecOps) thiết lập các ranh giới không thể vượt qua:

- Từ chối tạo các Pod chạy dưới quyền privileged (toàn quyền root trên Node).

- Cấm mount các thư mục nhạy cảm từ máy chủ host (như /etc hay /var/run/docker.sock) vào container.

- Chỉ cho phép kéo (pull) image từ các registry bảo mật nội bộ đã được phê duyệt của công ty, chặn đứng các image trôi nổi từ public Docker Hub.

Đảm bảo quy chuẩn nội bộ và chống lãng phí tài nguyên

Bạn có thể bắt buộc mọi tài nguyên phải có các nhãn hoặc chú thích nhất định để phục vụ thanh toán hoặc truy xuất nguồn gốc.

Ví dụ: Một tổ chức có quy định mọi ứng dụng chạy trong cụm dùng chung phải khai báo rõ giới hạn tài nguyên sử dụng (Khối resources.limits về CPU và RAM), tránh việc một ứng dụng "hàng xóm ồn ào" (Noisy Neighbor) chiếm dụng tài nguyên làm sập hệ thống. Thay vì trông chờ vào sự tự giác của lập trình viên, tổ chức thiết lập một Validating Webhook. Nếu yêu cầu tạo Pod gửi lên mà bỏ trống phần resource, Webhook sẽ lập tức "đá văng" request đó ra ngoài kèm thông báo lỗi chớp nhoáng trên màn hình terminal: "Yêu cầu bị từ chối: Pod của bạn chưa khai báo giới hạn CPU/Memory. Vui lòng bổ sung để tiếp tục triển khai!".

Rủi ro cần lưu ý khi vận hành Validating Admission Webhook

Sở hữu sức mạnh lớn đồng nghĩa với rủi ro cao. Nếu quản lý không khéo, Validating Webhook có thể trở thành "điểm nghẽn" thắt cổ toàn bộ hệ thống.

Cạm bẫy "Con gà và Quả trứng" làm tê liệt hệ thống

Đây là lỗi kinh điển nhất. Giả sử bạn cấu hình một Webhook tóm mọi request tạo Pod trên toàn cụm với chính sách failurePolicy=Fail. Nếu bản thân máy chủ Webhook bị sập, API Server sẽ chặn mọi thao tác tạo Pod mới. Trớ trêu thay, Kubernetes cũng không thể tạo ra Pod mới để hồi sinh chính cái Webhook đó (vì luật cấm tạo Pod đang được kích hoạt). Toàn bộ hệ thống sẽ rơi vào trạng thái tê liệt (deadlock). 

Cách phòng tránh: Luôn sử dụng namespaceSelector để bỏ qua việc kiểm tra đối với các namespace cốt lõi của hệ thống (như kube-system).

Cần giám sát độ trễ (Latency) cực kỳ khắt khe

Kubernetes API Server xử lý hàng nghìn request mỗi giây. Khi Webhook được kích hoạt, API Server phải đứng đợi Webhook xử lý xong mới phản hồi cho người dùng. Nếu Webhook của bạn gọi đến một cơ sở dữ liệu bên ngoài bị chậm, nó sẽ kéo lùi hiệu năng của toàn cụm. Bạn bắt buộc phải cấu hình timeoutSeconds thật ngắn (từ 1 đến 3 giây) và liên tục giám sát bằng Prometheus.

Best Pratice:

- Giới hạn phạm vi: Chỉ chặn đúng những loại tài nguyên và Namespace cần thiết. Dùng namespaceSelector để bỏ qua các namespace hệ thống (như kube-system).

- Tối ưu thời gian chờ (Timeout): Đặt timeoutSeconds ngắn (ví dụ 3 giây) để tránh treo API Server.

- Tính sẵn sàng cao (HA): Luôn chạy dịch vụ Webhook với ít nhất 2 bản sao (replicas) và cấu hình Pod Anti-Affinity.

Validating Admission Policy có thay thế được Webhook không?

Gần đây, Kubernetes đã giới thiệu một tính năng mới mang tính bước ngoặt: ValidatingAdmissionPolicy (sử dụng ngôn ngữ biểu thức chung - CEL). Thay vì phải lập trình, dựng container và vận hành một dịch vụ Webhook riêng biệt, quản trị viên giờ đây có thể viết trực tiếp các quy tắc kiểm tra (logic if/else) ngay bên trong file cấu hình YAML của Kubernetes.

Vậy khi nào nên dùng Webhook, khi nào dùng Policy?

- Nên dùng ValidatingAdmissionPolicy: Khi các quy tắc của bạn mang tính cấu trúc, kiểm tra giá trị (ví dụ: "Tên Pod phải bắt đầu bằng tiền tố X", "Phải có nhãn Y"). Giải pháp này chạy trực tiếp trong API Server nên độ trễ gần như bằng 0 và không lo rủi ro sập Webhook.

- Nên tiếp tục dùng Webhook: Khi quy tắc của bạn phức tạp, cần gọi đến các API bên ngoài (ví dụ: Gọi đến hệ thống IAM của công ty để kiểm tra quyền, hoặc tra cứu dữ liệu từ một cơ sở dữ liệu nội bộ).

Câu hỏi thường gặp về Validating Admission Webhook (FAQs)

Validating Admission Webhook khác gì Mutating Admission Webhook? Mutating Webhook chạy trước và có quyền sửa đổi nội dung của request (ví dụ: tự động gắn thêm nhãn). Validating Webhook chạy sau cùng và chỉ có một quyền duy nhất: Chấp nhận hoặc Từ chối request đó mà không được sửa đổi.

Nếu webhook bị lỗi thì Kubernetes xử lý ra sao? Hệ thống xử lý dựa trên failurePolicy. Nếu đặt là Ignore, request vẫn được đi qua. Nếu đặt là Fail, request sẽ bị từ chối và API Server trả về lỗi cho người dùng.

Có cần viết code riêng để tạo Validating Admission Webhook không? Có. Nếu xây dựng từ đầu, bạn phải viết một dịch vụ HTTP bằng Go, Python, v.v. Tuy nhiên, trong thực tế, các doanh nghiệp thường dùng các công cụ có sẵn như OPA Gatekeeper hoặc Kyverno để viết luật thay vì tự code Webhook từ đầu.

Validating Admission Webhook có làm chậm quá trình tạo tài nguyên không? Có, vì API Server phải đợi phản hồi từ Webhook. Tuy nhiên, nếu dịch vụ Webhook được viết tối ưu và chạy trong cùng cụm, độ trễ thường chỉ tính bằng mili-giây, không đáng kể đối với người dùng.

Kyverno và OPA Gatekeeper có phải là Validating Admission Webhook không? Bản thân chúng là các engine quản lý chính sách (Policy Engine). Nhưng ở dưới tầng cơ sở (under the hood), chúng chính là các phần mềm ứng dụng cơ chế Validating/Mutating Admission Webhook của Kubernetes để tương tác với API Server.

Có nên dùng Validating Admission Webhook cho mọi loại kiểm tra không? Không nên lạm dụng. Chỉ nên dùng cho những chính sách bảo mật/tuân thủ bắt buộc. Việc cấu hình quá nhiều Webhook đan chéo nhau có thể gây khó khăn cho việc gỡ lỗi (debug) và làm tăng độ trễ của cụm.

Kết luận

Validating Admission Webhook đóng vai trò như một trạm kiểm soát an ninh tối hậu, đảm bảo rằng mọi thay đổi diễn ra trong cụm Kubernetes của bạn đều tuân thủ chặt chẽ các chính sách bảo mật và tiêu chuẩn vận hành của tổ chức trước khi được phép tồn tại.

Tuy nhiên, việc thiết lập, duy trì các chính sách Webhook tự chế, kết hợp với việc giám sát độ ổn định của API Server đòi hỏi một nền tảng hạ tầng vững chắc và đội ngũ vận hành giàu kinh nghiệm. Để xây dựng một cụm Kubernetes an toàn, tuân thủ chính sách nội bộ mà không tốn quá nhiều nguồn lực thiết lập, doanh nghiệp có thể tìm đến Viettel Dedicated Kubernetes Service (vDKS). Dịch vụ cung cấp hạ tầng Data Center chuẩn quốc tế Tier III, kiến trúc bảo mật nhiều lớp Security-by-default cùng đội ngũ chuyên gia hỗ trợ kỹ thuật 24/7.

Liên hệ và tham khảo chi tiết dịch vụ tại: https://viettelidc.com.vn/viettel-kubernetes-service