Bài này chỉ dám xưng em và các bác để các bác tay to chia sẻ học hỏi thêm. Cái này từ kinh nghiệm của em khi hôm event AWS có ngồi với mấy ông “bạn lạ” chém gió. Và em thấy là. Em nói thật, GitOps phần lớn fail, không phải vì kỹ thuật phức tạp, mà vì secret quản lý kiểu… vô tổ chức (mấy cái bank thì còn thấy ổn ổn chút).

Như này các bác tin không?

Thậm trí mấy công ty có hẳn DEVOPS TEAM chứ không phải mấy ông tay ngang quản trị,

• Repo GitOps công khai, ai cũng clone được. Secret thì để trong file values.yaml, chỉ base64 chứ không encrypt.
• Dùng Sealed Secrets nhưng key của controller để trong PVC, không có backup. Lỡ xóa namespace là mất hết secret.
• Có bác viết một script decrypt.sh rồi đẩy lên cùng repo, xài SOPs mà không có age key rotation luôn.
• Một team thì dùng Vault nhưng mở hết permission cho tất cả các namespace, không chia policy rõ ràng. Dẫn tới ai cũng đọc được secret của người khác.
• Có nơi… push secret lên Git rồi kêu “repo này private rồi mà lo gì”.

Tại sao lại fail?

Vì GitOps gắn chặt với khái niệm “single source of truth” – mọi thứ phải versioned, traceable, reproducible.

Secret không quản lý đúng cách sẽ phá hỏng toàn bộ triết lý đó.

• Bác rollback version của app nhưng secret không khớp → pod crash.
• Bác clone repo staging để tạo prod → xài nhầm secret → rò rỉ dữ liệu thật.
• Bác không audit được ai đổi secret lúc nào → mất tính traceable.

Và tệ hơn nữa, đó là một lỗ hổng bảo mật trực tiếp.

Theo em nghĩ sai lầm nằm ở

1. Tư duy “secret là chuyện nhỏ” Nhiều team chỉ tập trung build app, CI/CD, deploy, mà quên rằng secret là máu nuôi app. Rò rỉ hoặc lệch secret là mất cả production.

2. Chọn công cụ mà không hiểu bản chất Nhiều bác nghe trend xài SOPs, Sealed Secrets, HashiCorp Vault,… nhưng không hề hiểu nó hoạt động thế nào. Dùng sai còn tệ hơn không dùng.

3. Không ai chịu own phần security Thường DevOps lo GitOps, còn Security team thì xa vời. Cuối cùng ai cũng nghĩ người kia lo phần secret → không ai lo cả.

Vậy làm sao để mô hình GitOps thực sự work?

• Secret phải tách riêng, có policy và lifecycle rõ ràng.
• Chọn công cụ thì hiểu rõ key management, access control và có backup + rotate.
• Có rule CI để check repo không chứa base64/xác định leakage.
• Phải có người chịu trách nhiệm rõ ràng cho phần secret: rotate, revoke, monitor.

Chắc vậy thôi

GitOps không phải YAML đẹp là xong. Không quản được secret thì chẳng khác gì bác để chìa khoá nhà dán sau cánh cửa rồi tự hào là mình có smartlock.

Em chỉ muốn nói thẳng cho nó nhanh: GitOps mà không lo quản lý secret tử tế thì thất bại là cái chắc.