Điểm:0

Các cụm Kubernetes không được cấp khả năng bảo mật CAPSYSADMIN

lá cờ br

Trong AKS của chúng tôi, đã tìm thấy cảnh báo mức độ nghiêm trọng cao liên quan đến vấn đề này trong Trung tâm bảo mật Azure.

CAPSYSADMIN dùng để làm gì? Theo mặc định, các nhóm có được bật với thuộc tính này không? Bởi vì chúng tôi không kích hoạt cụ thể nó trong AKS của mình? Sau đó, những gì sẽ là lý do cho cảnh báo này? Và làm thế nào chúng ta có thể khắc phục cảnh báo này?

Michael Hampton avatar
lá cờ cz
Điều này được thực hiện bởi bất cứ ai đã tạo ra các nhóm. Kiểm tra định nghĩa nhóm YAML.
Vowneee avatar
lá cờ br
Có, tôi đã kiểm tra và không có thuộc tính nào được đặt để kích hoạt tính năng này. Nó thực sự kỳ lạ là tại sao nó hiển thị lỗi này mặc dù thuộc tính không được đặt
mario avatar
lá cờ cm
Bạn có thể chia sẻ toàn bộ thông báo cảnh báo từ ASC không?
Vowneee avatar
lá cờ br
@mario cảnh báo giống như tôi đã đưa ra trong tiêu đề vấn đề. Không có thêm chi tiết có sẵn.
Điểm:1
lá cờ cm

Giải trình:

CAPSYSADMIN dùng để làm gì?

Bản thân các khả năng của Linux là một chủ đề rộng nhưng tóm lại, như bạn có thể đọc đây:

Bắt đầu từ kernel 2.2, Linux phân chia đặc quyền theo truyền thống được liên kết với siêu người dùng thành các đơn vị riêng biệt, được gọi là khả năng, có thể được kích hoạt độc lập và Vô hiệu hóa. Khả năng là một thuộc tính cho mỗi luồng.

Vì vậy, nói cách khác, chúng là những đơn vị riêng biệt có thể được sử dụng để kiểm soát sự leo thang đặc quyền trong HĐH Linux của bạn.

CAP_SYS_ADMIN là một trong số đó và trên thực tế, nó khá mạnh mẽ. Nó cho phép thực hiện một loạt các hoạt động quản trị hệ thống, những hoạt động đặc quyền mà người dùng bình thường không thể thực hiện được. Đối với danh sách đầy đủ xin vui lòng tham khảo tài liệu nàyĐiều khiển+fCAP_SYS_ADMIN.

Như bạn có thể tưởng tượng, từ khía cạnh bảo mật, việc sử dụng khả năng này không được khuyến nghị, trừ khi nó thực sự cần thiết. Điều này phù hợp với nguyên tắc đặc quyền tối thiểu về cơ bản có nghĩa là "chỉ cung cấp cho tài khoản người dùng hoặc xử lý những đặc quyền cần thiết để thực hiện chức năng dự định của nó".

Nhưng hãy quay trở lại bối cảnh của kubernetes, khẩu súng trườngxanh vì có lẽ bạn vẫn tò mò làm thế nào tất cả những gì tôi đề cập ở trên phù hợp ở đó.

Theo mặc định, các nhóm có được bật với thuộc tính này không?

Không, trừ khi bạn kích hoạt nó một cách rõ ràng trong một vỏ Định nghĩa. Vì vậy, cảnh báo bạn nhận được không phải là khả năng này được sử dụng bởi bất kỳ nhóm nào của bạn mà là về khả năng thuộc tính này có thể được sử dụng bởi bất kỳ người dùng nào của bạn, những người được ủy quyền tạo nhóm mới trong khẩu súng trường cụm. Nói cách khác, tại thời điểm này, các nhóm tận dụng CAP_SYS_ADMIN khả năng được phép tạo trên của bạn khẩu súng trường cụm.

Dưới đây bạn có thể thấy một ví dụ về một vỏ:

phiên bản api: v1
loại: Vỏ
metadata:
  tên: bảo mật-bối cảnh-demo-4
thông số kỹ thuật:
  hộp đựng:
  - tên: sec-ctx-4
    hình ảnh: gcr.io/google-samples/node-hello:1.0
    bối cảnh bảo mật:
      khả năng:
        thêm: ["SYS_ADMIN"]

Để biết thêm chi tiết xin vui lòng tham khảo Đặt khả năng cho Vùng chứa phần trong tài liệu kubernetes chính thức.

Bạn có thể dễ dàng tự mình kiểm tra và bạn sẽ thấy rằng những điều trên vỏ sẽ được tạo thành công vì hiện tại nó không bị cấm theo bất kỳ cách nào.

sau đó bạn có thể giám đốc điều hành kubectl để như vậy vỏ và xác minh rằng CAP_SYS_ADMIN khả năng thực sự được sử dụng bởi nó. Đơn giản chỉ cần chạy:

kubectl exec -it security-context-demo-4 -- /bin/bash

Sau khi kết nối với vỏ bạn có thể chạy:

viết hoa --print | grep cap_sys_admin

Và bạn sẽ thấy rằng cap_sys_admin khả năng được kích hoạt.

Bạn có thể kiểm tra tương tự trong một vỏ mà không sử dụng khả năng này:

phiên bản api: v1
loại: Vỏ
metadata:
  tên: bảo mật-bối cảnh-demo-4-1
thông số kỹ thuật:
  hộp đựng:
  - tên: sec-ctx-4
    hình ảnh: gcr.io/google-samples/node-hello:1.0

Khi bạn giám đốc điều hành kubectl vào đó:

kubectl exec -ti security-context-demo-4-1 -- /bin/bash

và chạy lệnh tương tự:

viết hoa --print | grep cap_sys_admin

bạn sẽ thấy nó không được bật theo mặc định.

Dung dịch:

Mặc du khẩu súng trường là một dịch vụ kubernetes được quản lý và trên thực tế, rất nhiều lớp bảo mật đã được Microsoft xử lý cho bạn, bạn vẫn được giao nhiều trách nhiệm khi nói đến việc quản lý tài khoản của mình. khẩu súng trường cụm. Bạn có thể ví dụ tự mình thực hiện một số hành động khác để làm cho nó thậm chí còn an toàn hơn.

Tin vui là bạn không hoàn toàn đơn độc với những nhiệm vụ như vậy và bạn được cung cấp rất nhiều giải pháp sẵn sàng mà bạn có thể áp dụng một cách đơn giản trong môi trường Azure của mình.

một trong số đó là Trung tâm bảo mật Azure, giúp bạn giảm bớt gánh nặng trong việc tự mình phát hiện các mối đe dọa tiềm ẩn mới trong thiết lập hiện tại của mình. Như bạn có thể đọc đây khuyến nghị Các cụm Kubernetes không được cấp khả năng bảo mật CAPSYSADMIN là một phần của Các đề xuất mới để củng cố cụm Kubernetes vẫn đang ở dạng xem trước, vì vậy bạn có thể chưa xem chúng trước đây:

Các đề xuất mới để củng cố cụm Kubernetes (trong bản xem trước)

Các khuyến nghị sau đây cho phép bạn tăng cường hơn nữa Cụm Kubernetes

  • Các cụm Kubernetes không nên sử dụng không gian tên mặc định - Để bảo vệ chống truy cập trái phép cho ConfigMap, Pod, Secret, Các loại tài nguyên Dịch vụ và Tài khoản Dịch vụ, ngăn chặn việc sử dụng không gian tên mặc định trong cụm Kubernetes.
  • Các cụm Kubernetes nên tắt thông tin xác thực API tự động đếm - Để ngăn chặn tài nguyên Pod có khả năng bị xâm phạm chạy các lệnh API đối với các cụm Kubernetes, hãy tắt thông tin đăng nhập API tự động hóa.
  • Các cụm Kubernetes không được cấp khả năng bảo mật CAPSYSADMIN

Sau đó, những gì sẽ là lý do cho cảnh báo này?

Với những điều trên, câu hỏi này có thể được trả lời: để cung cấp cho bạn khả năng cải thiện bảo mật cụm kubernetes của bạn bằng cách giảm bề mặt tấn công tiềm ẩn của các vùng chứa của bạn. Nhưng việc bạn có quyết định làm theo đề xuất này hay không hoàn toàn phụ thuộc vào bạn.

Quá nhiều cho phần phát hiện mối đe dọa. Còn phần khắc phục thì sao?

Và làm thế nào chúng ta có thể khắc phục cảnh báo này?

chính sách Azure là câu trả lời cho điều đó. Bạn có thể đã nghe nói về họ rồi. May mắn thay, để khắc phục mối đe dọa cụ thể này, bạn không cần phải viết chính sách tùy chỉnh của riêng mình vì Azure cung cấp định nghĩa chính sách tích hợp cho Azure Kubernetes Service và bạn có thể chỉ cần tận dụng chúng trên khẩu súng trường cụm.

Trong cột đầu tiên, bạn được cung cấp liên kết trực tiếp đến Cổng thông tin Azure của bạn, sẽ đưa bạn đến trang định nghĩa chính sách, tại đây bạn có thể kiểm tra thông tin chi tiết của chính sách và nơi có thể chỉ định chính sách cho một nhóm đăng ký và tài nguyên cụ thể:

nhập mô tả hình ảnh ở đây

nhập mô tả hình ảnh ở đây

Để biết thêm chi tiết xin vui lòng tham khảo:

Các liên kết hữu ích khác:

Đăng câu trả lời

Hầu hết mọi người không hiểu rằng việc đặt nhiều câu hỏi sẽ mở ra cơ hội học hỏi và cải thiện mối quan hệ giữa các cá nhân. Ví dụ, trong các nghiên cứu của Alison, mặc dù mọi người có thể nhớ chính xác có bao nhiêu câu hỏi đã được đặt ra trong các cuộc trò chuyện của họ, nhưng họ không trực giác nhận ra mối liên hệ giữa câu hỏi và sự yêu thích. Qua bốn nghiên cứu, trong đó những người tham gia tự tham gia vào các cuộc trò chuyện hoặc đọc bản ghi lại các cuộc trò chuyện của người khác, mọi người có xu hướng không nhận ra rằng việc đặt câu hỏi sẽ ảnh hưởng—hoặc đã ảnh hưởng—mức độ thân thiện giữa những người đối thoại.