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.
Và 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 và Điều khiển+f vì CAP_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ường và xanh 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ể:
Để 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: