Giaosucan's blog - Chia sẻ kiến thức theo cách bá đạo

Ticker

20/recent/ticker-posts

Project Zeus 04 – Giải pháp Docker Security

 Tiếp tục phần 3 , bài này tập trung trình bày về phần bảo mật đối với hệ thống k8s.

Top 6 Kubernetes Security Best Practices 2020 | Medium

Trong giai đoạn đầu tiên của startup, cần release sản phẩm nhanh, nên hệ thống cũ đã bỏ qua nhiều vấn đề về bảo mật

Security Issues

Hệ thống không được phân quyền tốt, members của DevOps team từ member cho đến leader đều có full quyền trên gcp project, thậm chí có quyền grant admin permission cho members khác. Dẫn tới, members được cấp quyền bừa bãi, không tracking được. Vì không giới hạn quyền nên việc tạo resource trên k8s cluster không thể kiểm soát, làm cho cluster liên tục phải autoscale, làm chi phí tăng cao, cũng không thể track hết được ai đã tạo resource gì trên cluster

Cluster hiện tại là public, các jenkins agent có thể access ra ngoài internet thoải mái, không bị block. Điều này tiện lợi nhưng cũng tiềm ẩn rủi ro khi agent có thể vô tính download mailware về hệ thống

Jenkins agent và các application khác được package thành docker file và build thành image sau đó publish lên GCR. Nhưng những docker file này được viết không theo một best practice đặc biệt là phần docker security.

Inbound/outbound access không được chú ý kĩ, nhiều pod server mở port open ra internet. Đỉnh điểm là vụ hacker có nick name là Doctor Who đã lợi dụng lỗ hổng bảo mật log4j để cài cắm backdoor vào server, tạo một lượng data transfer outbound ra internet khổng lồ

Các cloud provider như AWS hay GCP đều charge data transfer cost out internet, backdoor như hình dưới. Trong trường hợp này, backdoor đã gửi một lượng lớn data ra ngoài, làm cho cost trên những server này tăng lên đột ngột, gây ra vụ security incident

AWS data transfer costs and how to minimize them | by Datapath.io | Medium

Giải pháp

Manage access k8s resources và GCP resources bằng IAM. Trên GCP project chỉ có SRE team có quyền admin, một số team như DevOps được cấp quyền write trên một số service như Secret Manager …user chỉ có quyền read

Trên k8s, user được phân quyền qua RBAC, theo mặc định, user chỉ có quyền readonly trên k8s resources. Mỗi team sẽ có permisson trên namespace của mình, trừ team lead của full permission trên team namespace, member khác chỉ có quyền write hoặc read tùy vị trí

Các role được tạo ra như pod-reader, pod-writer sau đó được binding cho group, users, service account …

What is RBAC in Kubernetes?. RBAC stands for Role-Based Access… | by Daniel  Chernenkov | Medium

Docker

Theo mặc định docker chỉ run với quyền root (sudo) hoặc user nằm trong docker group. Nếu không khi build image bạn sẽ gặp lỗi

Output
docker: Cannot connect to the Docker daemon. Is the docker daemon running on this host?.
See 'docker run --help'.

Vì sao vậy , trước hết cần hiểu về cơ chế của docker

Docker là một chương trình có thiết kế client-server. Lệnh docker bạn thường sử dụng chính là client, còn Docker daemon thì đóng vai trò làm server. Server này nghe các request bằng cả TCP socket lẫn Unix socket. Unix socket của Docker (là cái file đó) thì được được đặt tại var/run/docker.sock.

Docker Tips : about /var/run/docker.sock | by Luc Juggery | Better  Programming

docker.sock file này được manage bởi root user. Do đó nếu hacker có thể chiếm quyền file này, họ có thể chiếm quyền trên docker

Trên hệ thống mới, quyền root trên tất cả các agent bị loại bỏ, đồng nghĩa không thể run docker build theo cách thông thường (do daemon không tồn tại). Một số giải pháp được thử nghiệm

Docker rootless mode: run docker deamon và container trong user workspace. Tuy nhiên cách này lại có nhược điểm không hỗ trợ cgroup (Linux kernel dùng để giới hạn resource cho từng tiến trình) –> bạn không thể cấp phát resource limitation cho docker.

Docker in docker: cái tên cũng đủ hiểu, thay vì chạy docker command trên chính jenkins agent ( yêu cầu cần docker daemon root), sẽ launch 1 container và access vào nó (để chạy docker cli)

Team sử dụng sysbox runtime để tạo một container , sysbox sẽ tạo ra một virtual env trong container, từ đó bạn có thể sử dụng docker cli mà ko cần quyền root trên host. Tuy nhiên cách này quá phức tạp và rắc rối khi cài đặt và implement

Cuối cùng Kaniko build được lựa chọn

https://github.com/GoogleContainerTools/kaniko

Vì lý do sau

kaniko doesn't depend on a Docker daemon and executes each command within a Dockerfile completely in userspace

1 container được launch trên image kaniko , jenkins jobs sẽ access container này để thực hiên build / push image

/kaniko/executor --context $CI_PROJECT_DIR --dockerfile $CI_PROJECT_DIR/Dockerfile --no-push

Bài tiếp theo sẽ trình bày giải pháp quản lý việc tạo resource trên k8s, đảm bảo các pod phải follow các rules về securitys

Đăng nhận xét

0 Nhận xét