Mở đầu

Trong khi hàng loạt các công cụ thuộc Cloud Native Computing Foundation xuất hiện cung cấp cho chúng ta thêm nhiều các tính năng để tích hợp với cụm Kubernetes thì mình lại có xu hướng ưu tiên những giải pháp native được xây dựng sẵn trong Kubernetes để đáp ứng các bài toán của bản thân. Trong bài viết này mình muốn giới thiệu đến các bạn các tính năng về bảo mật (security) được xây dựng sẵn trong Kubernetes mà đôi khi chúng ta quên mất không sử dụng để rồi phải đi tìm kiếm cùng những tính năng từ các công cụ bên ngoài.

Namespace

Đúng vậy! các bạn không nhìn nhầm đâu. Namepsace đóng vai trò quan trọng trong việc quản lý và bảo mật, đặc biệt khi triển khai các ứng dụng và dịch vụ trên một cụm (cluster) lớn. Namespace giúp tạo ra các không gian độc lập để tách biệt các tài nguyên (như Pod, Service, ConfigMap, Secret) và kiểm soát quyền truy cập. Namespace trong Kubernetes được ứng dụng để cung cấp nền tảng áp dụng các biện pháp bảo mật khác.

Trong thực tế namespace có thể được sử dụng để:

• Tách biệt các môi trường triển khai ứng dụng như dev, staging và production.
• Nền tảng để áp dụng các biện pháp bảo mật như ResourceQuota (Kiểm soát lượng tài nguyên sử dụng), RBAC (Phân quyền theo vai trò), Networkpolicy (Kiểm soát truy cập dựa trên network).
• Dùng để tách biệt cấu hình ứng dụng (Configmaps, Secret) trên các môi trường các nhau.

Hình phía dưới mô tả một trường hợp cơ bản khi sử dụng namespace để tách biệt môi trường triển khai.

Trong trường hợp nếu bạn không sử dụng namespace cô lập các môi trường hoặc ứng dụng nằm trong cụm Kubernetes, mà triển khai hết lên cùng 1 namespace thì việc sau đó áp dụng các biện pháp bảo mật sẽ rất khó khăn.

Network Policy

NetworkPolicy là một công cụ bảo mật trong Kubernetes giúp quản lý và kiểm soát lưu lượng mạng giữa các Pod và với các dịch vụ bên ngoài. Mặc định, Kubernetes cho phép tất cả các Pod trong cùng một cụm (cluster) giao tiếp với nhau mà không có bất kỳ giới hạn nào. Tuy nhiên, NetworkPolicy cho phép tạo ra các luật (rules) để chỉ định cụ thể những kết nối mạng nào được phép và từ chối những kết nối không mong muốn cả 2 đầu lưu lượng đến và đi.

Về cơ bản NetworkPolicy sẽ giúp ta bảo vệ trước các cuộc tấn công trong nội bộ, tăng cường khả năng độc lập giữa các mạng/ứng dụng hoặc bảo vệ dữ liệu/dịch vụ nhạy cảm chạy trong cụm Kubernetes. Trong thực tế NetworkPolicy được sử dụng để:

• Giới hạn lưu lượng mạng chỉ trong nội bộ ứng dụng: Nhiều ứng dụng được triển khai trong K8s chỉ cần giao tiếp trong nội bộ, không cần bất kỳ lưu lượng nào ra bên ngoài thì ta có thể sử dụng NetworkPolicy để giới hạn lưu lượng mạng chỉ đến từ các Pod trong cùng Namespace.
• Chặn lưu lượng từ các Pod bị xâm nhập: Một ứng dụng có thể bị tấn công vào một Pod, và hacker có thể tìm cách di chuyển ngang (lateral movement) để xâm nhập vào các Pod khác. Sử dụng NetworkPolicy giúp ngăn chặn lưu lượng mạng giữa các Pod không cần thiết, hạn chế tấn công lan rộng.
• Hạn chế truy cập từ môi trường staging đến production: Trong một cụm Kubernetes, các môi trường staging và production có thể tồn tại trong các Namespace khác nhau. NetworkPolicy có thể được sử dụng để ngăn các Pod trong staging giao tiếp với các Pod trong production, đảm bảo cách ly môi trường.
• Chỉ cho phép lưu lượng từ các dịch vụ được cho phép: Một cơ sở dữ liệu chỉ nên được truy cập bởi các dịch vụ nhất định (ví dụ: API server), NetworkPolicy có thể được cấu hình để chỉ cho phép lưu lượng mạng từ các Pod cụ thể, giúp bảo vệ dữ liệu nhạy cảm.

Sau đây là ví dụ về một file manifest cho NetworkPolicy cho phép pod có label app=backend kết nối đến pod có label là app=database

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata: name: allow-frontend-access namespace: default
spec: podSelector: matchLabels: app: database policyTypes: - Ingress ingress: - from: - podSelector: matchLabels: app: backend

Role-Based Access Control (RBAC)

Role-Based Access Control (RBAC) trong Kubernetes là một trong những cơ chế quan trọng để quản lý và kiểm soát quyền truy cập vào tài nguyên trong cụm. Nó đóng vai trò bảo mật thiết yếu bằng cách xác định rõ ai có thể thực hiện hành động gì trên tài nguyên nào. RBAC cung cấp khả năng phân quyền chi tiết, từ đó bảo vệ cụm Kubernetes khỏi các hoạt động trái phép hoặc không mong muốn.

Các thành phần chính của RBAC trong Kubernetes

RBAC dựa trên một số thành phần chính giúp xác định quyền truy cập:

• Subjects (Chủ thể): Đây là các đối tượng có thể yêu cầu truy cập vào tài nguyên trong Kubernetes, bao gồm:

  • Người dùng (Users): Những cá nhân hoặc thực thể con người.
  • Tài khoản dịch vụ (Service Accounts): Được sử dụng bởi các ứng dụng hoặc dịch vụ chạy bên trong cụm.
  • Nhóm (Groups): Một tập hợp các người dùng được nhóm lại để áp dụng chính sách chung.

• Roles (Vai trò): Roles xác định tập hợp các quyền (permissions) trên một phạm vi tài nguyên cụ thể.

  • Role: Áp dụng trong phạm vi một Namespace.

  • ClusterRole: Áp dụng trên toàn bộ cụm, không bị giới hạn bởi Namespace.

    Mỗi Role hoặc ClusterRole định nghĩa các hành động (verbs) được phép thực hiện trên tài nguyên (resources), chẳng hạn như get, list, create, update, delete.

• RoleBindings và ClusterRoleBindings: là các đối tượng dùng để liên kết một Role hoặc ClusterRole với một Subject (người dùng, tài khoản dịch vụ, hoặc nhóm).

  • RoleBinding: Liên kết Role với chủ thể trong một Namespace cụ thể.
  • ClusterRoleBinding: Liên kết ClusterRole với chủ thể trên toàn cụm.

Cách thức hoạt động của RBAC

Khi một yêu cầu API được gửi đến Kubernetes (ví dụ như tạo, xóa, hoặc truy cập vào một tài nguyên), hệ thống RBAC sẽ kiểm tra yêu cầu đó để xác định xem người dùng có quyền thực hiện hành động đó trên tài nguyên hay không. Điều này đảm bảo rằng chỉ những người hoặc dịch vụ được cấp quyền mới có thể thực hiện các hành động trên tài nguyên.

Usecases

Trong thực tế RBAC được áp dụng trong nhiều các trường hợp:

• Kiểm soát quyền truy cập: RBAC cho phép quản trị viên xác định quyền truy cập cụ thể cho từng tài nguyên. Điều này giúp ngăn chặn việc cung cấp quá nhiều quyền cho người dùng hoặc dịch vụ, từ đó giảm thiểu rủi ro bảo mật.
• Phân quyền theo nhóm hoặc dự án: Trong một cụm Kubernetes lớn với nhiều nhóm phát triển hoặc dự án khác nhau, RBAC có thể được sử dụng để phân quyền dựa trên nhóm hoặc dự án. Điều này giúp tách biệt các quyền truy cập giữa các nhóm và đảm bảo rằng mỗi nhóm chỉ có quyền truy cập vào tài nguyên của họ.
• Bảo vệ tài nguyên nhạy cảm: Với RBAC, tài nguyên nhạy cảm như Secrets, ConfigMaps, hoặc các tài nguyên hệ thống (ví dụ: Nodes, PersistentVolumes) có thể được bảo vệ khỏi các thao tác trái phép. Chỉ những người có quyền cụ thể mới được phép truy cập hoặc chỉnh sửa các tài nguyên này.
• Áp dụng nguyên tắc "least privilege": RBAC giúp triển khai nguyên tắc bảo mật least privilege, tức là chỉ cung cấp quyền cần thiết nhất cho người dùng hoặc dịch vụ để thực hiện công việc của họ. Việc áp dụng đúng nguyên tắc này giúp giảm thiểu các rủi ro bảo mật liên quan đến việc có quá nhiều quyền không cần thiết.

Pod Security Standard (PSS)

Pod Security Standards (PSS) trong Kubernetes là một tính năng bảo mật giúp xác định và thi hành các tiêu chuẩn bảo mật cho việc triển khai các Pod. PSS kiểm soát việc sử dụng các tính năng nhạy cảm trong container, như quyền root, mạng lưới đặc quyền, và việc mount hệ thống tập tin. Mục tiêu chính của PSS là bảo vệ cụm Kubernetes khỏi các hành vi không an toàn từ các Pod hoặc ứng dụng được triển khai.

PSS cung cấp 3 cấp độ bảo mật khác nhau: Privileged, Baseline, Restricted và được cấu hình theo namespace.

• Privileged: Chế độ này cung cấp mức bảo mật thấp nhất, cho phép Pod có quyền truy cập tối đa vào tài nguyên hệ thống. Dùng trong các trường hợp cần quyền truy cập đặc quyền vào hệ thống, như một số công việc quản trị hoặc các Pod điều khiển phần cứng.

• Baseline: Chế độ bảo mật trung bình, cung cấp các kiểm soát cơ bản nhưng vẫn cho phép một số tính năng cần thiết cho các ứng dụng phổ thông. Chế độ này không cho phép các quyền truy cập đặc quyền.Cấp độ này dùng cho các ứng dụng phổ thông không yêu cầu quyền đặc quyền nhưng cần một số khả năng như mạng lưới hoặc mount volume.

• Restricted: Đây là chế độ bảo mật cao nhất, giới hạn tối đa quyền truy cập và ngăn cấm hầu hết các hành vi nhạy cảm như quyền root, đặc quyền, mount volume đặc biệt, và khả năng thay đổi quyền hạn. Ứng dụng cho các ứng dụng cần mức độ bảo mật cao, không yêu cầu quyền truy cập vào tài nguyên đặc quyền hoặc phần cứng.

Tham khảo thêm các quyền của từng Level tại đây: https://kubernetes.io/docs/concepts/security/pod-security-standards/#user-namespaces

Nếu bạn chưa biết chọn level nào cho phù hợp với ứng dụng của mình thì có thể bắt đầu với Privileged level rồi tăng dần dần chỉnh sửa cấu hình tăng level lên Restricted khi ứng dụng đã đáp ứng đủ yêu cầu.

Usecases

• Bảo vệ chống lại các cuộc tấn công từ bên trong (Insider attacks): Nếu một Pod trong cụm Kubernetes bị tấn công, các chính sách bảo mật của PSS ngăn cản Pod đó leo thang quyền hạn hoặc can thiệp vào hệ thống máy chủ và các Pod khác. Điều này giúp ngăn chặn các cuộc tấn công từ bên trong.
• Đảm bảo sự tuân thủ của ứng dụng: Với các tiêu chuẩn bảo mật khác nhau (Privileged, Baseline, Restricted), quản trị viên có thể áp dụng các chính sách bảo mật phù hợp với yêu cầu của từng môi trường, đảm bảo rằng chỉ những ứng dụng tuân thủ chính sách mới được triển khai trong cụm.
• Hạn chế thiệt hại từ các Pod bị tấn công: PSS giới hạn những gì một Pod có thể làm trong trường hợp bị xâm nhập, từ đó giảm thiểu thiệt hại tiềm ẩn. Pod bị xâm nhập sẽ không thể truy cập vào các tài nguyên nhạy cảm hoặc thực hiện các hành động có quyền hạn cao.
• Tăng cường bảo mật cho hệ thống tệp và kernel: Bằng cách ngăn chặn Pod mount các volume đặc quyền hoặc truy cập vào các hệ thống tệp nhạy cảm, PSS bảo vệ hệ thống kernel và hệ thống tệp của Kubernetes khỏi việc bị xâm nhập hoặc thay đổi bởi các Pod không an toàn.
• Phát hiện và ngăn chặn các cấu hình sai (misconfigurations): Nếu một ứng dụng hoặc Pod cố gắng sử dụng quyền hạn đặc quyền mà không được phép (theo các tiêu chuẩn bảo mật đã đặt), PSS sẽ phát hiện và ngăn chặn việc triển khai đó, từ đó ngăn ngừa các cấu hình không an toàn.

Để sử dụng PSS cho namespace ta thêm label sau vào trong namespace

# The per-mode level label indicates which policy level to apply for the mode.
#
# MODE must be one of `enforce`, `audit`, or `warn`.
# LEVEL must be one of `privileged`, `baseline`, or `restricted`.
pod-security.kubernetes.io/<MODE>: <LEVEL> # Optional: per-mode version label that can be used to pin the policy to the
# version that shipped with a given Kubernetes minor version (for example v1.31).
#
# MODE must be one of `enforce`, `audit`, or `warn`.
# VERSION must be a valid Kubernetes minor version, or `latest`.
pod-security.kubernetes.io/<MODE>-version: <VERSION>

Security Context

Có phần tương tự như Pod Security Standard (PSS) nhưng Security Context tập trung vào pod hoặc container cụ thể. Security Context cho phép quản trị viên và người dùng kiểm soát cách thức các Pod hoặc Container tương tác với hệ thống tệp, tài khoản người dùng, và các khả năng hệ thống (system capabilities). Việc cấu hình Security Context là rất quan trọng để bảo vệ ứng dụng và cụm Kubernetes khỏi các mối đe dọa bảo mật.

Security Context thường được sử dụng để:

• Chạy container không có quyền root: Một ứng dụng web chạy trên Kubernetes có thể được cấu hình để luôn chạy dưới một tài khoản người dùng không có quyền root, giảm thiểu rủi ro bị tấn công leo thang quyền hạn.
• Giới hạn khả năng hệ thống cho container: Một container sử dụng một số lệnh hệ thống đặc biệt (như thay đổi cấu hình mạng) có thể được cấp quyền cụ thể thông qua Security Context mà không phải cấp quyền root hoàn toàn.
• Mount hệ thống file read-only: Một ứng dụng chỉ cần đọc dữ liệu cấu hình và không cần ghi lại dữ liệu có thể sử dụng cấu hình readOnlyRootFilesystem: true để bảo vệ hệ thống tập tin khỏi bị thay đổi bởi kẻ tấn công.

Sau đây là một ví dụ khi sử dụng Security Context trong Kubernetes

apiVersion: v1
kind: Pod
metadata: name: secure-pod
spec: securityContext: runAsUser: 1000 runAsGroup: 3000 fsGroup: 2000 allowPrivilegeEscalation: false seLinuxOptions: level: "s0:c123,c456" containers: - name: my-container image: nginx securityContext: capabilities: drop: - NET_ADMIN - SYS_TIME readOnlyRootFilesystem: true runAsNonRoot: true

securityContext ở cấp Pod:

• runAsUser: 1000: Tất cả container trong Pod sẽ chạy dưới tài khoản người dùng có ID là 1000, không phải người dùng root.
• runAsGroup: 3000: Các container sẽ chạy với quyền của nhóm 3000.
• fsGroup: 2000: Tất cả các hệ thống tập tin được mount bởi Pod sẽ thuộc về nhóm 2000.
• allowPrivilegeEscalation: false: Ngăn chặn các container trong Pod có khả năng leo thang quyền hạn.
• seLinuxOptions: Cấu hình chính sách SELinux, với mức bảo mật s0:c123,c456.

securityContext ở cấp container:

• capabilities.drop: Bỏ các khả năng hệ thống NET_ADMIN và SYS_TIME, giúp ngăn container can thiệp vào cài đặt mạng và thời gian của hệ thống.
• readOnlyRootFilesystem: true: Hệ thống tập tin root của container sẽ chỉ có quyền đọc, ngăn chặn việc ghi đè hoặc thay đổi tập tin hệ thống.
• runAsNonRoot: true: Đảm bảo rằng container sẽ không được chạy với quyền root.

Kết

Như vậy trong bài viết mìn đã đưa đến các bạn một số tính năng native của Kubernetes liên quan đến Security. Khi làm việc đến Security ta luôn phải cân nhắc giữa 3 yếu tố: Độ bảo mật - Chi phí - Độ tiện lợi, nếu một yếu tố tăng lên sẽ kéo yếu tố còn lại thấp xuống. Chúng ta sẽ không cần áp dụng toàn bộ các tính năng trên, bạn sẽ cần tìm hiểu để áp dụng vừa đủ vào hệ thống của mình.

Bài viết có thể còn thiếu các tính năng bảo mật khác có trong Kubernetes. Nếu bạn biết thêm tính năng nào hay chia sẻ ở phía dưới nhé Nếu thấy bài viết hay hãy Upvote và Follow mình để theo dõi thêm các bài viết khác liên quan đến Devops SRE,.. nhé! Trong bài viết tới mình có thể chia sẻ tiếp về các công cụ bảo mật có thể tích hợp thêm vào Kubernetes thuộc CNCF