DevOps 31/08/2026 7 phút

Tôi cấp một ServiceAccount đúng quyền 'chỉ đọc' Secret — rồi đọc ra ngay SieuBiMat123, và ba quyền nghe vô hại khác hoá ra tương đương quyền quản trị

Cấp quyền từng lớp cho một ServiceAccount rồi đo chính xác nó mở ra được gì. Role bó rất chặt (đúng động từ, đúng tài nguyên, đúng namespace), nhưng 'chỉ đọc' Secret là đọc được mọi mật khẩu vì base64 không phải mã hoá. Ba quyền nghe vô hại trong một bản YAML — create pods, get secrets, create rolebindings — đều là đường leo thang lên quyền toàn cụm. Và kubectl auth can-i là cách duy nhất kiểm quyền thực tế thay vì đọc YAML rồi đoán.

DevOps 31/08/2026 6 phút

DaemonSet hứa 'một bản trên mỗi node' — nhưng cụm 4 node của tôi chỉ có 3 bản, vì chữ 'mỗi' luôn kèm một điều kiện ẩn

DaemonSet chạy đúng một bản trên mỗi node — nghe đơn giản, nhưng 'mỗi node' có một điều kiện ẩn: node control plane bị bỏ qua vì có vết, nên cụm 4 node ra 3 bản. Thêm một dòng toleration là đủ 4. Đo tiếp: DaemonSet phản ứng với thay đổi tập node trong 0,1 giây (theo dõi qua watch) so với gần 6 phút khi node CHẾT — vì độ trễ nằm ở việc kết luận node đã chết, không phải ở việc phản ứng. Và vì sao DaemonSet không có replicas: số bản là hệ quả của số node, nó co giãn theo hạ tầng chứ không theo tải.

DevOps 31/08/2026 7 phút

Manifest khai cpu=50m nhưng pod chạy với cpu=410m — VPA sửa con số giữa đường, và kubectl get deployment vẫn thản nhiên hiện số cũ

HPA thêm bản, VPA sửa requests của từng bản. Đo VPA trên cụm thật: khuyến nghị đầu tiên sau ~60 giây (target 410m dùng được, nhưng upperBound 8.856 nhân là vô nghĩa vì chưa đủ lịch sử). Auto mode làm hai việc dễ tưởng là một: bộ admission ghi đè requests lúc tạo pod (manifest 50m → pod 410m, mà get deployment vẫn hiện 50m — vỡ nguồn-sự-thật của GitOps), và bộ updater chỉ giết pod khi requests nằm NGOÀI khoảng tin cậy. Vì sao VPA hay trông như không làm gì, và vì sao VPA với HPA-theo-CPU đá nhau.

DevOps 31/08/2026 7 phút

Mức restricted của Kubernetes từ chối thẳng một pod nginx hoàn toàn vô hại — không vì nó nguy hiểm, mà vì nó không chịu khai rằng mình an toàn

Pod Security Standards bật bằng đúng một nhãn namespace, không cài gì thêm. Đo trên cùng một pod ở ba mức: restricted từ chối cả một nginx bình thường, và toàn văn lời từ chối cho thấy lý do — nó đòi bốn dòng securityContext khai báo tường minh, vì mặc định của Kubernetes là mở (chạy root, giữ đủ capability, cho leo thang quyền) nên im lặng bị coi là nguy hiểm. Thêm cái bẫy: enforce chỉ xét lúc TẠO pod nên pod vi phạm đang chạy vẫn sống, và sự cố chỉ nổ ở lần deploy hoặc scale tiếp theo.

DevOps 31/08/2026 7 phút

Ai cũng bảo nginx non-root chết vì không mở nổi cổng 80 — tôi đo thì cổng 80 mở ngon lành, thứ giết nó là một lệnh mkdir

Thêm runAsUser: 1000 vào nginx thì pod chết — nhưng không phải vì cổng. Log chỉ thẳng: lỗi mkdir /var/cache/nginx, tức lỗi ghi hệ tệp, sửa bằng chown chứ chẳng cần đặc quyền gì. Đo tiếp cái ai cũng lặp lại 'cổng dưới 1024 cần root hoặc NET_BIND_SERVICE': uid 1000 mở cổng 80 vẫn được, capability kia chẳng làm gì, vì ip_unprivileged_port_start trong netns container là 0. Và một lần thử fsGroup không tái tạo nổi lỗi vì thư mục emptyDir là 0777 — bài học về phép thử dễ dãi cho kết quả xanh vô nghĩa.

DevOps 31/08/2026 7 phút

Sửa ConfigMap thì tệp gắn cập nhật sau 65 giây, còn biến môi trường thì không bao giờ đổi — cùng một giá trị, hai cách giao, hai số phận

Cấu hình vào pod bằng bốn cách và chúng hành xử khác hẳn khi bạn sửa. Đo: đổi ConfigMap thì tệp gắn cập nhật sau 65 giây (qua một cú hoán đổi liên kết mềm nguyên tử), còn biến môi trường KHÔNG BAO GIỜ đổi vì nó bị đóng băng lúc container khởi động — đó là bản chất của biến môi trường ở mức HĐH, không phải giới hạn Kubernetes. Và base64 của Secret không phải mã hoá: ai đọc được là đọc được mật khẩu, khác biệt thật chỉ là RBAC tách riêng và gắn qua tmpfs không chạm đĩa.