arrow_backQuay lại ghi chép lĩnh vực
DEVOPS Đã đăng 7 Jul 2026

Applied Kubernetes Hardening: A Practical Playbook

Một hướng dẫn thực tiễn để tăng cường bảo mật các cluster Kubernetes, bao gồm RBAC, bảo mật pod, chính sách mạng, và kiểm soát chuỗi cung ứng.

Kubernetes được vận chuyển với tính linh hoạt, không phải bảo mật, làm tư thế mặc định của nó. Mọi cổng mở, vai trò RBAC cho phép, và pod không bị hạn chế đều là một lời mời gọi. Tăng cường bảo mật một cluster có nghĩa là đóng cửa một cách có hệ thống những khoảng trống đó mà không làm hỏng các workload phụ thuộc vào chúng. Đây không phải là bài tập kiểm tra—đó là một kỷ luật liên tục ảnh hưởng đến các lớp danh tính, mạng, workload, và chuỗi cung ứng.

Khóa Control Plane Trước Tiên

Máy chủ API là mục tiêu có giá trị nhất duy nhất trong bất kỳ cluster nào. Bắt đầu bằng cách tắt xác thực ẩn danh và thực thi các phương pháp xác thực mạnh—tích hợp OIDC với nhà cung cấp danh tính của bạn là tốt hơn các token tĩnh hoặc chứng chỉ máy khách không bao giờ hết hạn. Hạn chế quyền truy cập vào kho dữ liệu etcd, vì nó chứa mọi bí mật và đối tượng cấu hình dưới dạng văn bản thuần túy trừ khi mã hóa khi lưu trữ được kích hoạt. Bật mã hóa cho các bí mật bằng cách sử dụng nhà cung cấp KMS thay vì dựa vào mã hóa base64, điều này không cung cấp bảo vệ thực sự. Ghi nhật ký kiểm toán phải được bật từ ngày đầu tiên; không có nó, bạn không có dấu vết pháp y khi có sự cố.

RBAC: Đặc quyền Tối thiểu, Không Phải Tiện lợi

Sự cấu hình sai phổ biến nhất trong các cluster production là liên kết RBAC quá rộng—cluster-admin được cấp cho các tài khoản dịch vụ chỉ cần đọc pod trong một namespace. Xây dựng các vai trò xung quanh các chức năng công việc thực tế và giới hạn chúng ở các namespace bất cứ khi nào có thể. Tránh các động từ ký tự đại diện và tài nguyên trong các định nghĩa Role và ClusterRole. Thường xuyên kiểm toán các liên kết bằng các công cụ như kubectl auth can-i --list hoặc rbac-lookup để bắt lỗi leo quyền. Các tài khoản dịch vụ xứng đáng được xem xét kỹ lưỡng như người dùng con người—tắt tự động gắn kết các token tài khoản dịch vụ cho các pod không cần quyền truy cập API.

Bảo mật Pod: Giả định Thỏa hiệp

Pod Security Admission (đã thay thế PodSecurityPolicy không dùng nữa) cho phép bạn thực thi các hồ sơ cơ bản hoặc hạn chế ở cấp namespace. Ít nhất, cấm các container có đặc quyền, chia sẻ namespace của máy chủ, và leo quyền. Đặt runAsNonRoot: true và bỏ tất cả khả năng Linux theo mặc định, chỉ thêm lại những gì được yêu cầu rõ ràng. Các hệ thống tệp gốc chỉ đọc ngăn chặn những kẻ tấn công viết các nhị phân độc hại vào một container đang chạy. Các kiểm soát này quan trọng vì một container escape hoặc lỗ hổng ứng dụng được khai thác không nên dịch thành sự thỏa hiệp đầy đủ trên node.

Network Policies Không Phải Là Tùy chọn

Mặc định, mọi pod trong một cluster Kubernetes có thể nói chuyện với mọi pod khác. Mô hình mạng phẳng đó là giấc mơ di chuyển ngang cho những kẻ tấn công. Triển khai các tài nguyên NetworkPolicy để thực thi từ chối mặc định cho ingress và egress, sau đó cho phép rõ ràng chỉ các luồng lưu lượng mà ứng dụng của bạn yêu cầu. Điều này yêu cầu một plugin CNI thực sự hỗ trợ thực thi NetworkPolicy—Calico, Cilium, và những plugin khác điền vào vai trò này vì mô hình mạng Kubernetes cơ bản không thực thi bất cứ điều gì. Phân đoạn các namespace theo ranh giới tin tưởng và xếp các chính sách lên trên cung cấp cho bạn bảo vệ thực sự theo chiều sâu.

Tính toàn vẹn Hình ảnh và Chuỗi Cung ứng

Tăng cường bảo mật không dừng lại ở cấu hình runtime—nó bắt đầu với những gì bạn triển khai. Quét các hình ảnh container để tìm các lỗ hổng đã biết trước khi chúng đến được registry của bạn, và thực thi rằng chỉ các hình ảnh được ký và xác minh mới có thể chạy trong cluster của bạn bằng cách sử dụng các bộ điều khiển nhập như Kyverno hoặc OPA Gatekeeper. Ghim các thẻ hình ảnh vào bản tóm tắt thay vì các thẻ có thể thay đổi như latest, những cái có thể thay đổi âm thầm dưới bạn. Hạn chế các registry nào pod được phép kéo từ, đóng một đường dẫn phổ biến cho các cuộc tấn công chuỗi cung ứng nơi các hình ảnh bị xâm phạm hoặc typosquatted trượt vào production.

Quản lý Bí mật Vượt ra ngoài Mặc định Kubernetes

Native Kubernetes Secrets tốt hơn không có gì, nhưng chúng không phải là một giải pháp quản lý bí mật thực sự. Hãy xem xét tích hợp một trình quản lý bí mật bên ngoài—Vault, AWS Secrets Manager, hoặc tương tự—và đưa bí mật vào lúc runtime thay vì lưu trữ chúng dưới dạng các đối tượng cluster. Nếu bạn phải sử dụng native Secrets, hãy đảm bảo mã hóa etcd được bật và RBAC hạn chế chặt chẽ quyền truy cập đọc, vì bất kỳ pod hoặc người dùng nào có quyền get trên các bí mật trong một namespace có thể rò rỉ thông tin xác thực.

Xác minh Liên tục, Không Phải Thiết lập Một lần

Các cấu hình tăng cường bảo mật trôi dạt theo thời gian khi các workload mới được triển khai và các ưu tiên dịch chuyển sang tốc độ hơn bảo mật. Các công cụ như kube-bench kiểm tra tuân thủ so với CIS Kubernetes Benchmark, trong khi kube-hunter có thể mô phỏng tái khám phá kẻ tấn công chống lại cluster của bạn. Nướng các kiểm tra này vào các đường dẫn CI/CD để các sai cấu hình bị bắt trước khi đến production thay vì trong một cuộc gọi phản ứng sự cố.

Kubernetes hardening ít về một kiểm soát viên đạn bạc duy nhất và nhiều hơn về xếp các phòng thủ trên danh tính, mạng, workload, và chuỗi cung ứng—để một thất bại trong một lớp không dẫn đến sự thỏa hiệp đầy đủ. Để tìm hiểu thêm về các mẫu bảo mật cơ sở hạ tầng đám mây và công cụ phòng thủ, hãy khám phá các phân đoạn liên quan trên nền tảng DEFENSE_GRID của Korra Studio.

Viết với hỗ trợ của AI, được xem xét và đăng bởi Michal Pilch (CISSP), Korra Studio.

Sẵn sàng đi xa hơn?

Đây là một ghi chép từ cơ sở kiến thức Korra Studio — nền tảng kết hợp mỗi chủ đề với phiên hỗ trợ 1-kèm-1.

Bắt đầu miễn phíarrow_forward