ABC về bảo mật trong Kubernetes: Xác thực, ủy quyền, kiểm tra

Sớm hay muộn, trong quá trình vận hành của bất kỳ hệ thống nào, vấn đề bảo mật cũng nảy sinh: đảm bảo xác thực, phân tách quyền, kiểm toán và các nhiệm vụ khác. Đã được tạo cho Kubernetes nhiều giải pháp, cho phép bạn đạt được sự tuân thủ các tiêu chuẩn ngay cả trong những môi trường có yêu cầu khắt khe nhất... Tài liệu tương tự được dành cho các khía cạnh cơ bản về bảo mật được triển khai trong các cơ chế tích hợp của K8. Trước hết, nó sẽ hữu ích cho những ai mới bắt đầu làm quen với Kubernetes - làm điểm khởi đầu cho việc nghiên cứu các vấn đề liên quan đến bảo mật.

Xác thực

Có hai loại người dùng trong Kubernetes:

• Tài khoản dịch vụ — các tài khoản được quản lý bởi API Kubernetes;
• Người dùng — người dùng “bình thường” được quản lý bởi các dịch vụ độc lập, bên ngoài.

Sự khác biệt chính giữa các loại này là đối với Tài khoản dịch vụ, có các đối tượng đặc biệt trong API Kubernetes (chúng được gọi là - ServiceAccounts), được gắn với một không gian tên và một tập hợp dữ liệu ủy quyền được lưu trữ trong cụm trong các đối tượng thuộc loại Bí mật. Những người dùng như vậy (Tài khoản dịch vụ) chủ yếu nhằm mục đích quản lý quyền truy cập vào API Kubernetes của các quy trình đang chạy trong cụm Kubernetes.

Người dùng thông thường không có mục trong API Kubernetes: chúng phải được quản lý bởi các cơ chế bên ngoài. Chúng dành cho những người hoặc quá trình sống bên ngoài cụm.

Mỗi yêu cầu API được liên kết với Tài khoản dịch vụ, Người dùng hoặc được coi là ẩn danh.

Dữ liệu xác thực người dùng bao gồm:

• Tên đăng nhập (Username) — tên người dùng (phân biệt chữ hoa chữ thường!);
• UID - chuỗi nhận dạng người dùng có thể đọc được bằng máy “nhất quán và duy nhất hơn tên người dùng”;
• Du lịch Nhóm - danh sách các nhóm mà người dùng thuộc về;
• thêm - các trường bổ sung có thể được sử dụng bởi cơ chế ủy quyền.

Kubernetes có thể sử dụng một số lượng lớn cơ chế xác thực: chứng chỉ X509, mã thông báo Bearer, proxy xác thực, HTTP Basic Auth. Bằng cách sử dụng các cơ chế này, bạn có thể triển khai một số lượng lớn các sơ đồ ủy quyền: từ tệp tĩnh có mật khẩu đến OpenID OAuth2.

Hơn nữa, có thể sử dụng đồng thời một số chương trình ủy quyền. Theo mặc định, cụm sử dụng:

• mã thông báo tài khoản dịch vụ - dành cho Tài khoản dịch vụ;
• X509 - dành cho Người dùng.

Câu hỏi về việc quản lý ServiceAccounts nằm ngoài phạm vi của bài viết này, nhưng đối với những ai muốn làm quen với vấn đề này một cách chi tiết hơn, tôi khuyên bạn nên bắt đầu với trang tài liệu chính thức. Chúng ta sẽ xem xét kỹ hơn vấn đề về cách thức hoạt động của chứng chỉ X509.

Chứng chỉ cho người dùng (X.509)

Cách làm việc cổ điển với chứng chỉ bao gồm:

• tạo khóa:

  mkdir -p ~/mynewuser/.certs/
  openssl genrsa -out ~/.certs/mynewuser.key 2048

• tạo yêu cầu chứng chỉ:

  openssl req -new -key ~/.certs/mynewuser.key -out ~/.certs/mynewuser.csr -subj "/CN=mynewuser/O=company"

• xử lý yêu cầu chứng chỉ bằng khóa CA của cụm Kubernetes, lấy chứng chỉ người dùng (để lấy chứng chỉ, bạn phải sử dụng tài khoản có quyền truy cập vào khóa CA của cụm Kubernetes, theo mặc định nằm ở /etc/kubernetes/pki/ca.key):

  openssl x509 -req -in ~/.certs/mynewuser.csr -CA /etc/kubernetes/pki/ca.crt -CAkey /etc/kubernetes/pki/ca.key -CAcreateserial -out ~/.certs/mynewuser.crt -days 500

• tạo một tập tin cấu hình:
  • mô tả cụm (chỉ định địa chỉ và vị trí của tệp chứng chỉ CA để cài đặt cụm cụ thể):

    kubectl config set-cluster kubernetes --certificate-authority=/etc/kubernetes/pki/ca.crt --server=https://192.168.100.200:6443

  • hoặc thế nào khôngtùy chọn được đề xuất - bạn không phải chỉ định chứng chỉ gốc (khi đó kubectl sẽ không kiểm tra tính chính xác của máy chủ api của cụm):

    kubectl config set-cluster kubernetes  --insecure-skip-tls-verify=true --server=https://192.168.100.200:6443

  • thêm người dùng vào tệp cấu hình:

    kubectl config set-credentials mynewuser --client-certificate=.certs/mynewuser.crt  --client-key=.certs/mynewuser.key

  • thêm bối cảnh:

    kubectl config set-context mynewuser-context --cluster=kubernetes --namespace=target-namespace --user=mynewuser

  • gán bối cảnh mặc định:

    kubectl config use-context mynewuser-context

Sau các thao tác trên, trong file .kube/config một cấu hình như thế này sẽ được tạo:

apiVersion: v1
clusters:
- cluster:
    certificate-authority: /etc/kubernetes/pki/ca.crt
    server: https://192.168.100.200:6443
  name: kubernetes
contexts:
- context:
    cluster: kubernetes
    namespace: target-namespace
    user: mynewuser
  name: mynewuser-context
current-context: mynewuser-context
kind: Config
preferences: {}
users:
- name: mynewuser
  user:
    client-certificate: /home/mynewuser/.certs/mynewuser.crt
    client-key: /home/mynewuser/.certs/mynewuser.key

Để chuyển cấu hình giữa các tài khoản và máy chủ dễ dàng hơn, việc chỉnh sửa giá trị của các khóa sau là rất hữu ích:

• certificate-authority
• client-certificate
• client-key

Để thực hiện việc này, bạn có thể mã hóa các tệp được chỉ định trong chúng bằng base64 và đăng ký chúng trong cấu hình, thêm hậu tố vào tên của các khóa -data, I E. đã nhận được certificate-authority-data vv

Chứng chỉ với kubeadm

Với việc phát hành Kubernetes 1.15 làm việc với các chứng chỉ đã trở nên dễ dàng hơn nhiều nhờ hỗ trợ phiên bản alpha của nó trong tiện ích kubeadm. Ví dụ: bây giờ việc tạo tệp cấu hình bằng khóa người dùng có thể trông như sau:

kubeadm alpha kubeconfig user --client-name=mynewuser --apiserver-advertise-address 192.168.100.200

NB: Yêu cầu địa chỉ quảng cáo có thể được tìm thấy trong cấu hình api-server, theo mặc định nằm ở /etc/kubernetes/manifests/kube-apiserver.yaml.

Cấu hình kết quả sẽ được xuất ra thiết bị xuất chuẩn. Nó cần được lưu vào ~/.kube/config tài khoản người dùng hoặc vào một tệp được chỉ định trong biến môi trường KUBECONFIG.

Đào sâu hơn

Dành cho những ai muốn hiểu rõ hơn các vấn đề được mô tả kỹ lưỡng hơn:

• bài báo riêng biệt về làm việc với các chứng chỉ trong tài liệu chính thức của Kubernetes;
• bài viết hay từ Bitnami, trong đó vấn đề cấp chứng chỉ được đề cập từ góc độ thực tế.
• tài liệu chung về xác thực trong Kubernetes.

Ủy quyền

Tài khoản được ủy quyền mặc định không có quyền hoạt động trên cụm. Để cấp quyền, Kubernetes triển khai cơ chế ủy quyền.

Trước phiên bản 1.6, Kubernetes đã sử dụng loại ủy quyền được gọi là ABAC (Kiểm soát truy cập dựa trên thuộc tính). Thông tin chi tiết về nó có thể được tìm thấy trong tài liệu chính thức. Phương pháp này hiện được coi là cũ nhưng bạn vẫn có thể sử dụng nó cùng với các loại xác thực khác.

Cách phân chia quyền truy cập hiện tại (và linh hoạt hơn) cho một cụm được gọi là RBAC (Kiểm soát truy cập dựa trên vai trò). Nó đã được tuyên bố là ổn định kể từ phiên bản Kubernetes 1.8. RBAC thực hiện một mô hình quyền trong đó mọi thứ không được cho phép rõ ràng đều bị cấm.
Để kích hoạt RBAC, bạn cần khởi động máy chủ api Kubernetes với tham số --authorization-mode=RBAC. Các tham số được đặt trong tệp kê khai với cấu hình api-server, theo mặc định nằm dọc theo đường dẫn /etc/kubernetes/manifests/kube-apiserver.yaml, trong phần command. Tuy nhiên, RBAC đã được bật theo mặc định, vì vậy rất có thể bạn không nên lo lắng về điều đó: bạn có thể xác minh điều này bằng giá trị authorization-mode (trong phần đã đề cập kube-apiserver.yaml). Nhân tiện, trong số các ý nghĩa của nó có thể có các loại ủy quyền khác (node, webhook, always allow), nhưng chúng tôi sẽ để chúng nằm ngoài phạm vi của tài liệu.

Nhân tiện, chúng tôi đã xuất bản rồi Bài viết với mô tả khá chi tiết về các nguyên tắc và tính năng khi làm việc với RBAC, vì vậy, tôi sẽ giới hạn bản thân trong danh sách ngắn gọn về những điều cơ bản và ví dụ.

Các thực thể API sau được sử dụng để kiểm soát quyền truy cập trong Kubernetes thông qua RBAC:

• Role и ClusterRole - các vai trò dùng để mô tả quyền truy cập:
• Role cho phép bạn mô tả các quyền trong một không gian tên;
• ClusterRole - trong cụm, bao gồm các đối tượng cụ thể của cụm như nút, url không phải tài nguyên (tức là không liên quan đến tài nguyên Kubernetes - ví dụ: /version, /logs, /api*);
• RoleBinding и ClusterRoleBinding - dùng để ràng buộc Role и ClusterRole cho người dùng, nhóm người dùng hoặc ServiceAccount.

Các thực thể Vai trò và Ràng buộc vai trò bị giới hạn bởi không gian tên, tức là. phải nằm trong cùng một không gian tên. Tuy nhiên, RoleBinding có thể tham chiếu ClusterRole, cho phép bạn tạo một tập hợp các quyền chung và kiểm soát quyền truy cập bằng cách sử dụng chúng.

Vai trò mô tả các quyền bằng cách sử dụng bộ quy tắc có chứa:

• Nhóm API - xem tài liệu chính thức bởi apiGroups và đầu ra kubectl api-resources;
• tài nguyên (tài nguyên: pod, namespace, deployment và như thế.);
• Động từ (động từ: set, update v.v.)
• tên tài nguyên (resourceNames) - dành cho trường hợp bạn cần cung cấp quyền truy cập vào một tài nguyên cụ thể chứ không phải tất cả các tài nguyên thuộc loại này.

Bạn có thể tìm thấy phân tích chi tiết hơn về ủy quyền trong Kubernetes trên trang tài liệu chính thức. Thay vào đó (hay đúng hơn là ngoài điều này), tôi sẽ đưa ra những ví dụ minh họa cho công việc của cô ấy.

Ví dụ về các thực thể RBAC

Đơn giản Role, cho phép bạn lấy danh sách và trạng thái của các nhóm và theo dõi chúng trong không gian tên target-namespace:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: target-namespace
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "watch", "list"]

Ví dụ ClusterRole, cho phép bạn lấy danh sách và trạng thái của các nhóm và theo dõi chúng trong toàn bộ cụm:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  # секции "namespace" нет, так как ClusterRole задействует весь кластер
  name: secret-reader
rules:
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get", "watch", "list"]

Ví dụ RoleBinding, cho phép người dùng mynewuser nhóm "đọc" trong không gian tên my-namespace:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
  namespace: target-namespace
subjects:
- kind: User
  name: mynewuser # имя пользователя зависимо от регистра!
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role # здесь должно быть “Role” или “ClusterRole”
  name: pod-reader # имя Role, что находится в том же namespace,
                   # или имя ClusterRole, использование которой
                   # хотим разрешить пользователю
  apiGroup: rbac.authorization.k8s.io

Kiểm tra sự kiện

Về mặt sơ đồ, kiến ​​trúc Kubernetes có thể được biểu diễn như sau:

Thành phần Kubernetes chính chịu trách nhiệm xử lý các yêu cầu là máy chủ api. Tất cả các hoạt động trên cụm đều đi qua nó. Bạn có thể đọc thêm về các cơ chế nội bộ này trong bài viết “Điều gì xảy ra trong Kubernetes khi bạn chạy kubectl run?'.

Kiểm tra hệ thống là một tính năng thú vị trong Kubernetes, tính năng này bị tắt theo mặc định. Nó cho phép bạn ghi lại tất cả các lệnh gọi tới API Kubernetes. Như bạn có thể đoán, tất cả các hành động liên quan đến giám sát và thay đổi trạng thái của cụm đều được thực hiện thông qua API này. Một mô tả hay về khả năng của nó có thể được tìm thấy (như thường lệ) trong tài liệu chính thức K8. Tiếp theo, tôi sẽ cố gắng trình bày chủ đề bằng ngôn ngữ đơn giản hơn.

Vì vậy, cho phép kiểm toán, chúng ta cần chuyển ba tham số bắt buộc vào vùng chứa trong api-server, được mô tả chi tiết hơn bên dưới:

• --audit-policy-file=/etc/kubernetes/policies/audit-policy.yaml
• --audit-log-path=/var/log/kube-audit/audit.log
• --audit-log-format=json

Ngoài ba tham số cần thiết này, còn có nhiều cài đặt bổ sung liên quan đến kiểm tra: từ xoay vòng nhật ký đến mô tả webhook. Ví dụ về các tham số xoay nhật ký:

• --audit-log-maxbackup=10
• --audit-log-maxsize=100
• --audit-log-maxage=7

Nhưng chúng tôi sẽ không nói chi tiết hơn - bạn có thể tìm thấy tất cả thông tin chi tiết trong tài liệu kube-apiserver.

Như đã đề cập, tất cả các tham số được đặt trong tệp kê khai với cấu hình máy chủ api (theo mặc định /etc/kubernetes/manifests/kube-apiserver.yaml), trong phần command. Hãy quay lại 3 tham số bắt buộc và phân tích chúng:

1. audit-policy-file - đường dẫn đến tệp YAML mô tả chính sách kiểm tra. Chúng ta sẽ quay lại nội dung của nó sau, nhưng bây giờ tôi sẽ lưu ý rằng quy trình api-server phải đọc được tệp. Do đó, cần phải gắn nó vào bên trong vùng chứa, bạn có thể thêm đoạn mã sau vào các phần thích hợp của cấu hình:

     volumeMounts:
       - mountPath: /etc/kubernetes/policies
         name: policies
         readOnly: true
     volumes:
     - hostPath:
         path: /etc/kubernetes/policies
         type: DirectoryOrCreate
       name: policies

2. audit-log-path - đường dẫn đến tệp nhật ký. Đường dẫn cũng phải có thể truy cập được đối với quy trình máy chủ api, vì vậy chúng tôi mô tả việc gắn kết nó theo cách tương tự:

     volumeMounts:
       - mountPath: /var/log/kube-audit
         name: logs
         readOnly: false
     volumes:
     - hostPath:
         path: /var/log/kube-audit
         type: DirectoryOrCreate
       name: logs

3. audit-log-format - định dạng nhật ký kiểm tra. Mặc định là json, nhưng định dạng văn bản cũ cũng có sẵn (legacy).

Chính sách kiểm toán

Bây giờ về tệp được đề cập mô tả chính sách ghi nhật ký. Khái niệm đầu tiên về chính sách kiểm toán là level, mức độ ghi nhật ký. Chúng như sau:

• None - không đăng nhập;
• Metadata — siêu dữ liệu yêu cầu nhật ký: người dùng, thời gian yêu cầu, tài nguyên đích (nhóm, không gian tên, v.v.), loại hành động (động từ), v.v.;
• Request — ghi nhật ký siêu dữ liệu và nội dung yêu cầu;
• RequestResponse - ghi nhật ký siêu dữ liệu, nội dung yêu cầu và nội dung phản hồi.

Hai cấp độ cuối cùng (Request и RequestResponse) không ghi nhật ký các yêu cầu không truy cập tài nguyên (truy cập vào cái gọi là url không phải tài nguyên).

Ngoài ra tất cả các yêu cầu đều phải trải qua nhiều giai đoạn:

• RequestReceived - giai đoạn khi bộ xử lý nhận được yêu cầu và chưa được truyền đi xa hơn dọc theo chuỗi bộ xử lý;
• ResponseStarted — tiêu đề phản hồi được gửi, nhưng trước khi nội dung phản hồi được gửi. Được tạo cho các truy vấn chạy dài (ví dụ: watch);
• ResponseComplete - nội dung phản hồi đã được gửi đi, sẽ không gửi thêm thông tin nào nữa;
• Panic - các sự kiện được tạo ra khi phát hiện một tình huống bất thường.

Để bỏ qua bất kỳ bước nào bạn có thể sử dụng omitStages.

Trong tệp chính sách, chúng tôi có thể mô tả một số phần với các mức ghi nhật ký khác nhau. Quy tắc khớp đầu tiên được tìm thấy trong mô tả chính sách sẽ được áp dụng.

Daemon kubelet giám sát các thay đổi trong tệp kê khai bằng cấu hình máy chủ api và nếu phát hiện thấy bất kỳ thay đổi nào, hãy khởi động lại vùng chứa bằng máy chủ api. Nhưng có một chi tiết quan trọng: những thay đổi trong tệp chính sách sẽ bị nó bỏ qua. Sau khi thực hiện các thay đổi đối với tệp chính sách, bạn sẽ cần khởi động lại máy chủ api theo cách thủ công. Vì api-server được khởi động như nhóm tĩnh, đội kubectl delete sẽ không làm cho nó khởi động lại. Bạn sẽ phải làm điều đó một cách thủ công docker stop trên kube-masters, nơi chính sách kiểm tra đã được thay đổi:

docker stop $(docker ps | grep k8s_kube-apiserver | awk '{print $1}')

Khi kích hoạt kiểm tra, điều quan trọng cần nhớ là tải trên kube-apiserver tăng lên. Đặc biệt, mức tiêu thụ bộ nhớ để lưu trữ ngữ cảnh yêu cầu tăng lên. Việc ghi nhật ký chỉ bắt đầu sau khi tiêu đề phản hồi được gửi. Tải cũng phụ thuộc vào cấu hình chính sách kiểm toán.

Ví dụ về chính sách

Hãy xem cấu trúc của các tệp chính sách bằng các ví dụ.

Đây là một tập tin đơn giản policyđể ghi lại mọi thứ ở cấp độ Metadata:

apiVersion: audit.k8s.io/v1
kind: Policy
rules:
- level: Metadata

Trong chính sách, bạn có thể chỉ định danh sách người dùng (Users и ServiceAccounts) và nhóm người dùng. Ví dụ: đây là cách chúng tôi sẽ bỏ qua người dùng hệ thống nhưng ghi lại mọi thứ khác ở cấp độ Request:

apiVersion: audit.k8s.io/v1
kind: Policy
rules:
  - level: None
    userGroups:
      - "system:serviceaccounts"
      - "system:nodes"
    users:
      - "system:anonymous"
      - "system:apiserver"
      - "system:kube-controller-manager"
      - "system:kube-scheduler"
  - level: Request

Cũng có thể mô tả các mục tiêu:

• không gian tên (namespaces);
• Động từ (động từ: get, update, delete và những người khác);
• tài nguyên (tài nguyên, Như sau: pod, configmaps v.v.) và các nhóm tài nguyên (apiGroups).

Chú ý! Có thể lấy tài nguyên và nhóm tài nguyên (nhóm API, tức là apiGroups), cũng như các phiên bản của chúng được cài đặt trong cụm bằng cách sử dụng các lệnh:

kubectl api-resources
kubectl api-versions

Chính sách kiểm toán sau đây được cung cấp như một minh chứng cho các thông lệ tốt nhất trong Tài liệu về Đám mây của Alibaba:

apiVersion: audit.k8s.io/v1beta1
kind: Policy
# Не логировать стадию RequestReceived
omitStages:
  - "RequestReceived"
rules:
  # Не логировать события, считающиеся малозначительными и не опасными:
  - level: None
    users: ["system:kube-proxy"]
    verbs: ["watch"]
    resources:
      - group: "" # это api group с пустым именем, к которому относятся
                  # базовые ресурсы Kubernetes, называемые “core”
        resources: ["endpoints", "services"]
  - level: None
    users: ["system:unsecured"]
    namespaces: ["kube-system"]
    verbs: ["get"]
    resources:
      - group: "" # core
        resources: ["configmaps"]
  - level: None
    users: ["kubelet"]
    verbs: ["get"]
    resources:
      - group: "" # core
        resources: ["nodes"]
  - level: None
    userGroups: ["system:nodes"]
    verbs: ["get"]
    resources:
      - group: "" # core
        resources: ["nodes"]
  - level: None
    users:
      - system:kube-controller-manager
      - system:kube-scheduler
      - system:serviceaccount:kube-system:endpoint-controller
    verbs: ["get", "update"]
    namespaces: ["kube-system"]
    resources:
      - group: "" # core
        resources: ["endpoints"]
  - level: None
    users: ["system:apiserver"]
    verbs: ["get"]
    resources:
      - group: "" # core
        resources: ["namespaces"]
  # Не логировать обращения к read-only URLs:
  - level: None
    nonResourceURLs:
      - /healthz*
      - /version
      - /swagger*
  # Не логировать сообщения, относящиеся к типу ресурсов “события”:
  - level: None
    resources:
      - group: "" # core
        resources: ["events"]
  # Ресурсы типа Secret, ConfigMap и TokenReview могут содержать  секретные данные,
  # поэтому логируем только метаданные связанных с ними запросов
  - level: Metadata
    resources:
      - group: "" # core
        resources: ["secrets", "configmaps"]
      - group: authentication.k8s.io
        resources: ["tokenreviews"]
  # Действия типа get, list и watch могут быть ресурсоёмкими; не логируем их
  - level: Request
    verbs: ["get", "list", "watch"]
    resources:
      - group: "" # core
      - group: "admissionregistration.k8s.io"
      - group: "apps"
      - group: "authentication.k8s.io"
      - group: "authorization.k8s.io"
      - group: "autoscaling"
      - group: "batch"
      - group: "certificates.k8s.io"
      - group: "extensions"
      - group: "networking.k8s.io"
      - group: "policy"
      - group: "rbac.authorization.k8s.io"
      - group: "settings.k8s.io"
      - group: "storage.k8s.io"
  # Уровень логирования по умолчанию для стандартных ресурсов API
  - level: RequestResponse
    resources:
      - group: "" # core
      - group: "admissionregistration.k8s.io"
      - group: "apps"
      - group: "authentication.k8s.io"
      - group: "authorization.k8s.io"
      - group: "autoscaling"
      - group: "batch"
      - group: "certificates.k8s.io"
      - group: "extensions"
      - group: "networking.k8s.io"
      - group: "policy"
      - group: "rbac.authorization.k8s.io"
      - group: "settings.k8s.io"
      - group: "storage.k8s.io"
  # Уровень логирования по умолчанию для всех остальных запросов
  - level: Metadata

Một ví dụ điển hình khác về chính sách kiểm toán là hồ sơ được sử dụng trong GCE.

Để phản hồi nhanh chóng các sự kiện kiểm toán, có thể mô tả webhook. Vấn đề này được đề cập trong tài liệu chính thức, Tôi sẽ để nó ngoài phạm vi của bài viết này.

Kết quả

Bài viết cung cấp cái nhìn tổng quan về các cơ chế bảo mật cơ bản trong cụm Kubernetes, cho phép bạn tạo tài khoản người dùng được cá nhân hóa, phân tách quyền của họ và ghi lại hành động của họ. Tôi hy vọng nó sẽ hữu ích cho những ai đang phải đối mặt với những vấn đề như vậy về mặt lý thuyết hoặc thực tế. Tôi cũng khuyên bạn nên đọc danh sách các tài liệu khác về chủ đề bảo mật trong Kubernetes, được cung cấp trong “PS” - có lẽ trong số đó bạn sẽ tìm thấy những thông tin chi tiết cần thiết về các vấn đề liên quan đến mình.

PS

Đọc thêm trên blog của chúng tôi:

• «Hơn 33 công cụ bảo mật Kubernetes»;
• «Giới thiệu về Chính sách mạng Kubernetes dành cho chuyên gia bảo mật»;
• «Tìm hiểu RBAC trong Kubernetes»;
• «9 Thực tiễn tốt nhất về bảo mật Kubernetes»;
• «11 cách để (không) trở thành nạn nhân của vụ hack Kubernetes'.

Nguồn: www.habr.com