Secret rotation trong Kubernetes: đổi credentials mà không làm ứng dụng ngã dây chuyền

Một lần xoay secret sai nhịp có thể làm pod restart hàng loạt, queue nghẽn và cả đội mất cả buổi tối. Bài này là checklist để tránh cảnh đó.

Secret rotation nghe như một việc bảo mật định kỳ, nhưng trên hệ thống thật nó là bài toán phối hợp giữa ứng dụng, Kubernetes và cách bạn quan sát rollout. Secret rotation ko khó ở phần đổi giá trị, mà khó ở chỗ đổi xong hệ thống có tiếp tục phục vụ traffic bình thường hay không.

Khi secret rotation hay làm production rung lên

Dấu hiệu thường thấy khá quen:

• Pod mới lên nhưng readiness check chập chờn.
• App nối được vào database lúc đầu, vài phút sau thì rớt vì pool vẫn giữ credential cũ.
• Worker retry liên tục, làm backlog phình ra.
• On-call nhận alarm 5 phút sau deploy và mọi người khá dễ cuống cuồn.

Điểm khó là sự cố này hiếm khi đến từ một lỗi duy nhất. Nhiều team tưởng đã đổi Secret trong cluster là xong, nhưng vấn đề vẩn còn nằm ở connection pool, cache cấu hình, hoặc app chỉ đọc biến môi trường đúng một lần khi process start.

Gốc của sự cố thường nằm ở đâu?

Thường thường lỗi lớn nhất là thiếu một giai đoạn chuyển tiếp. Nếu bạn đổi password database ngay lập tức nhưng application chưa kịp reload hoặc chưa rollout hết pod mới, bạn tự tạo ra một cửa sổ fail rất khó chịu.

Có bốn nhóm nguyên nhân hay gặp:

1. Ứng dụng không hỗ trợ reload an toàn. Nếu app lấy secret qua environment variable, container đang chạy sẽ không tự thấy bản cập nhật cho tới khi restart. Kubernetes docs nói khá rõ điều này trong phần Secret consumption: cập nhật Secret không tự chảy vào env var của process đã chạy rồi, còn Secret mounted as volume thì được cập nhật theo cơ chế eventual propagation của kubelet chứ không phải tức thì. Xem thêm tại https://kubernetes.io/docs/concepts/configuration/secret/
2. Credential phía downstream không có thời gian overlap. Password mới có hiệu lực ngay, password cũ bị revoke ngay, trong khi pod cũ vẫn còn giữ kết nối cũ.
3. Rollout strategy quá gắt. maxUnavailable cao hoặc probe chưa phản ánh đúng khả năng phục vụ thật.
4. Thiếu quan sát ở lớp ứng dụng. Bạn thấy deploy thành công nhưng không thấy error rate ở endpoint ghi dữ liệu đang leo lên từ từ. Mấy lỗi kiểu này hơi lằng nhằng thiêt.

Checklist rollout không gãy

Đây là checklist tôi hay dùng khi thiết kế quy trình rotation cho Kubernetes và Security review:

1. Version secret, đừng overwrite mù mờ

Thay vì chỉ sửa một Secret hiện có rồi hi vọng app đọc lại đúng lúc, hãy gắn tư duy versioning. Ví dụ db-creds-v17 và db-creds-v18. Cách này giúp rollback dễ hơn và log/alert cũng rõ ràng hơn.

2. Tạo cửa sổ chấp nhận song song

Nếu downstream cho phép, hãy để cả credential cũ và mới cùng hợp lệ trong một khoảng ngắn. Đây là phần cứu mạng nhiều nhất. Với database hoặc API token nội bộ, một cửa sổ overlap 15-30 phút thường thực dụng hơn việc “xoay cái rụp”.

3. Rollout có kiểm soát, không đẩy cả cụm cùng lúc

Ưu tiên rolling update với maxUnavailable: 0 cho workload nhạy cảm, cộng với readiness probe thực sự kiểm tra đường đi quan trọng. Nếu app cần warm-up cache, đừng cho nhận traffic quá sớm.

4. Chủ động đóng kết nối cũ

Nhiều app giữ connection pool đã authenticated từ trước. Khi rotate xong, pod mới ổn nhưng pod cũ hoặc worker nền vẫn nói chuyện bằng credential cũ. Bạn cần cơ chế recycle pool, SIGHUP reload, hoặc rolling restart sạch sẽ.

5. Quan sát đúng tín hiệu

Trước khi bấm rollout, hãy chuẩn bị dashboard tối thiểu:

• error rate theo endpoint hoặc job type
• latency p95/p99
• số lượng reconnect tới database hoặc broker
• queue backlog hoặc consumer lag

Nếu bạn đang test thêm các luồng đăng ký sandbox, email xác minh, hay tài khoản throwaway trong lúc rotate, một temporary email address có thể hữu ích cho môi trường rủi ro thấp. Tôi chỉ dùng nó cho test account kiểu dummy e mail hoặc temp org mail, không cho tài khoản thật hay dữ liệu nhạy cảm.

Một ví dụ rollout an toàn cho ứng dụng stateful

Giả sử bạn có API ghi đơn hàng và worker xử lý background jobs:

1. Tạo credential mới ở database nhưng chưa revoke credential cũ.
2. Tạo Secret version mới trong Kubernetes.
3. Deploy API trước và theo dõi error rate ghi dữ liệu trong 10-15 phút.
4. Deploy worker sau, vì worker thường giữ kết nối lâu hơn API.
5. Khi metric ổn, revoke credential cũ.

Một vòng lệnh kiểm tra tối thiểu có thể đơn giản như sau:

kubectl rollout status deploy/orders-api -n production
kubectl rollout status deploy/orders-worker -n production
kubectl get pods -n production

Phần quan trọng không phải bản thân các lệnh này, mà là bạn đã định nghĩa điều kiện “ổn” trước khi chạy hay chưa. Nếu chưa có ngưỡng rõ ràng cho error budget, reconnect spike, hoặc backlog tăng bao nhiêu thì phải dừng, team rất dễ quyết định theo cảm giác.

Q&A nhanh

Có nên mount Secret dưới dạng file thay vì env var không?

Nếu ứng dụng của bạn hỗ trợ đọc lại file cấu hình hoặc watch file thay đổi, mount file thường linh hoạt hơn env var. Nhưng bạn vẫn cần kiểm tra cách app reload, vì Kubernetes chỉ cập nhật dữ liệu Secret theo chu kỳ đồng bộ chứ không bảo đảm tức thì.

Khi nào cần restart toàn bộ workload?

Khi app không hỗ trợ reload, connection pool không recycle được, hoặc dependency phía sau không cho phép overlap credential. Trong trường hợp đó, restart có kiểm soát vẫn an toàn hơn cố giữ zero-downtime bằng mọi giá.

Rotation nên chạy vào giờ thấp điểm hay giờ làm việc?

Nếu quy trình của bạn còn mới, hãy chạy vào giờ có đủ người hỗ trợ nhưng traffic vừa phải. Sau vài lần ổn định và có dashboard tử tế, bạn mới nên tự tin tự động hóa hơn.