Building Uber's Multi-Cloud Secrets Management Platform to Enhance Security

Uber · 2025 · 3. Quy mô lớn · Độ khó: Trung bình — bài gốc

Bối cảnh

• Hơn 5.000 microservice, 5.000 database, hơn 500.000 job phân tích mỗi ngày, hơn 400 tích hợp nhà cung cấp và 400 ứng dụng SaaS; hơn 150.000 secret dùng để xác thực giữa chúng. Credential bị lộ là một nguyên nhân hàng đầu của tấn công.
• Vấn đề: secret rải trong code, cấu hình, hệ thống không mã hoá; nhiều kho secret "tự dựng" của từng team; chia sẻ secret không an toàn; khó xoay vòng khi cần.

Thay đổi chính

• Chặn và dọn secret rải rác: CLI chạy như pre-commit hook chặn commit chứa secret; quét real-time PR, commit, tin nhắn Slack, log build; quét định kỳ repo, filesystem, image container. Phát hiện thì tự tìm chủ sở hữu, mở ticket theo mức ưu tiên; chủ phải thu hồi secret và xoá khỏi chỗ lộ.
• Gom kho: chuẩn nội bộ bắt mọi secret nằm trong kho được duyệt do một team (Secrets team) quản lý; dựng kho trên cloud cạnh HashiCorp Vault on-prem; chuyển secret từ kho tự dựng sang (qua External Secrets Operator cho Kubernetes…). Lộ ra chuyện secret của một pipeline lại đọc được từ mọi pipeline chạy qua Piper (điều phối workflow dữ liệu), tương tự trong CI (Buildkite); thêm giám sát truy cập. 25 kho của nhiều team thành 6 kho của một team, vẫn chia theo môi trường để giới hạn phạm vi ảnh hưởng.
• Metadata là nền: mỗi secret có provider (hệ sinh ra và cài secret vào tài nguyên), deployment platform (hệ đưa secret tới workload), impact level (mức nghiêm trọng nếu lộ). Điền bù bằng heuristic (suy impact theo tài nguyên được bảo vệ), phần còn lại hỏi chủ sở hữu.
• Xoay vòng tự động: hàng trăm loại secret, nhiều nền tảng deploy (Up/Kubernetes, Odin, Flink, YARN…), có loại chỉ cho một mật khẩu hợp lệ mỗi lúc nên đổi là có downtime. Hai bộ API: Secret Provider (Generate, Revoke, Rollback) và Deployment Platform (rollout, Fetch trước khi khởi chạy). Bật dần theo rủi ro và khối lượng; trung bình 20.000 secret/tháng được xoay vòng không cần người. Dọn secret mồ côi (không chủ, không tài nguyên, không workload dùng).
• Trao đổi với bên thứ ba (SSX): nhà cung cấp xác minh bằng OTP qua email rồi tự nhập secret, đi thẳng vào kho mà không nhân viên nào thấy; có test sanity trước khi đưa tới service và tự quay về giá trị cũ nếu secret mới làm hỏng tích hợp.
• Đội nền tảng chỉ 10 kỹ sư; nhân rộng bằng chương trình toàn công ty dựa trên số liệu, chọn "đối tác thiết kế" (bộ phận dữ liệu khách hàng và thanh toán), ưu tiên theo rủi ro (credential cloud trước).

Còn lại (theo Uber)

• Không thể tự động xoay vòng mọi loại secret vì quá nhiều tích hợp; hướng đi là không dùng secret (workload identity qua SPIFFE/SPIRE). Xoay vòng tự động lỗi cũng là rủi ro độ tin cậy, nên họ muốn coi cập nhật secret như một lần deploy code.

Bài học cho SWE

• Gom quyền sở hữu kho secret về một đội trước, rồi mới xây lớp quản trị chung; kho rải rác thì không áp chuẩn được.
• Secret cũng cần metadata (ai sinh, ai phân phối, mức ảnh hưởng) như mọi tài nguyên khác thì mới tự động hoá được.
• Chặn ở pre-commit rẻ hơn mọi bước sau.

Liên quan

• Slack 2023 (đổi mặc định nền tảng để bỏ một kiểu credential dễ lộ) · Uber 2025
• Stack Overflow 2021 (secret rải rác là đường tấn công thật)
• Bảo mật hạ tầng và quản lý secret · Nền tảng nội bộ cho service (đường ray chung)