Keepers

CloudKeepers là các monitor tự trị thực thi các biện pháp bảo vệ về chi phí, bảo mật, và hiệu suất trên tất cả tài khoản đám mây và Kubernetes cluster đã kết nối. Thanh bên của ứng dụng hiển thị chúng dưới tên Keepers trong mục Infrastructure.

​

Cách tổ chức keepers

Keepers tạo thành ma trận 3 × 3 gồm nhà cung cấp và trụ cột: Mỗi keeper theo dõi một kết hợp nhà cung cấp–trụ cột. Chỉ bật các keeper bạn cần — ví dụ AWS-COST và K8S-SEC — hoặc cả chín để có độ phủ đầy đủ. Mỗi keeper chứa nhiều quy tắc phát hiện (tổng cộng 40+ quy tắc) mà bạn bật/tắt và tinh chỉnh riêng lẻ:

• Quy tắc chi phí: instance compute không dùng, storage chưa gắn kết, snapshot cũ, IP tĩnh không dùng, database quá lớn, load balancer không hoạt động, tài nguyên pod được yêu cầu quá mức, và nhiều hơn
• Quy tắc bảo mật: S3 bucket công khai, IAM role không dùng, MFA bị tắt trên root, security group mở, bí mật trong parameter store, và nhiều hơn
• Quy tắc hiệu suất: giới hạn kết nối RDS, thiếu health probe, pod CrashLooping, tài nguyên bị throttle, và nhiều hơn

​

Quyền tự trị

Mỗi quy tắc phát hiện chạy ở một trong hai chế độ: Quyền tự trị được đặt theo từng quy tắc, nên hầu hết quy tắc có thể giữ ở Manual trong khi các quy tắc chi phí đã hiểu rõ — như dọn dẹp volume chưa gắn kết — chạy ở Auto.

​

Điều kiện tiên quyết

• Ít nhất một tài khoản đám mây hoặc Kubernetes cluster đã kết nối với quyền đọc/giám sát và tùy chọn quyền khắc phục.
• Slack, Microsoft Teams, hoặc điểm đích email đã cấu hình nếu bạn muốn cảnh báo ngoài notifications trong ứng dụng.
• Tùy chọn: tags hoặc bộ lọc sẵn sàng nếu bạn có kế hoạch giới hạn phạm vi phát hiện cho các môi trường cụ thể.

​

Thiết lập keepers đầu tiên

​

Từ phát hiện đến khuyến nghị

Keepers biến các phát hiện thô thành công việc được theo dõi, có quản trị:

1. Phát hiện — mỗi keeper chạy theo lịch cron (mặc định: hàng ngày lúc 07:00 UTC) hoặc theo yêu cầu, quét tất cả tài nguyên được phép — không chỉ những tài nguyên bạn đã khám phá trước đó. Mỗi lần chạy để lại audit trail trong tab Runs.
2. Phân loại — mỗi phát hiện được gắn thẻ với trụ cột, mức độ nghiêm trọng, nỗ lực, và tiết kiệm ước tính để bạn ưu tiên các sửa chữa có giá trị nhất. Di chuyển phát hiện qua các trạng thái khi bạn xử lý:

   Trạng thái	Ý nghĩa
   New (Mới)	Vừa được phát hiện; chưa có ai xem xét.
   Acknowledged (Đã xác nhận)	Một thành viên trong nhóm đã thấy phát hiện này và chịu trách nhiệm theo dõi.
   Active (Đang xử lý)	Công việc xử lý phát hiện đang được tiến hành.
   Resolved (Đã giải quyết)	Vấn đề cơ bản đã được khắc phục và xác minh.
   Dismissed (Đã bỏ qua)	Đã được xem xét và chủ động không thực hiện hành động.

3. Đề bạt — phát hiện bắt đầu dưới dạng nháp; đề bạt những cái đáng hành động thành khuyến nghị active. Mỗi khuyến nghị bao gồm phân tích tác động với ước tính trước/sau và playbook từng bước. Từ chế độ xem chi tiết, dùng Impact Analytics để phân tích sâu hơn, Generate Guidelines cho runbook có thể chia sẻ, Custom Prompt để khám phá các trường hợp biên, hoặc Implement để thực hiện thay đổi.
4. Theo dõi — lưu khuyến nghị vào Plan để phê duyệt, lập lịch, và theo dõi thực thi, để đội quản trị, FinOps, và bảo mật chia sẻ cùng một nguồn sự thật.

​

Cài đặt keeper

Mỗi keeper có tab Settings riêng nơi bạn có thể cấu hình:

• Lịch: một biểu thức cron cho các lần chạy tự động (tối thiểu mỗi 1 giờ).
• Quy tắc phát hiện: bật/tắt từng quy tắc, đặt mỗi quy tắc thành Manual hoặc Auto, và điều chỉnh ngưỡng theo từng quy tắc (CPU % không dùng, ngày nhìn lại, tuổi snapshot tối đa).
• Lệnh & quyền: quản lý lệnh đám mây nào mỗi quy tắc được phép thực thi, với tác dụng theo từng lệnh (Allow / Require Approval / Deny).
• Thông báo: kênh Email, Slack, và Teams với ngưỡng mức độ nghiêm trọng tối thiểu theo từng kênh. Notifications trong ứng dụng luôn được gửi bất kể cài đặt kênh.

​

Ví dụ

​

Biện pháp bảo vệ chi phí

Hạ tầng phát triển hữu cơ ẩn chứa lãng phí mà kiểm tra thủ công hiếm khi bắt được. AWS-COST gắn cờ EC2 instance không dùng, EBS volume chưa gắn kết, snapshot cũ, và NAT gateway không được sử dụng — và nó đọc ngữ cảnh: volume được gắn thẻ để sao lưu hàng ngày có mục đích, trong khi volume test không được gắn thẻ từ năm ngoái thực sự là mồ côi. Xem xét phát hiện trên dashboard, đề bạt những cái có độ tin cậy cao, và lưu vào Plan để phê duyệt và thực thi.

​

Biện pháp bảo vệ bảo mật

Sự trượt bảo mật tích lũy giữa các cuộc kiểm tra: IAM role quá rộng, S3 bucket công khai, volume chưa mã hóa, và security group mở đến 0.0.0.0/0. AWS-SEC quét liên tục và cân nhắc ngữ cảnh vận hành — HTTP từ bất kỳ đâu là bình thường cho load balancer nhưng nguy hiểm cho database, và khóa truy cập tài khoản root quan trọng hơn IAM role chỉ đọc không dùng. Định tuyến phát hiện nghiêm trọng đến Slack để phân loại ngay và theo dõi sửa chữa đa nhóm trong Plan.

​

Liên quan