Nỗi lo khi scale hệ thống từ 5 lên 50+ server
Cảnh tượng thường thấy ở các startup: hồi đầu chỉ có 5 con server Ubuntu, mọi thứ cực kỳ thong dong. Mỗi khi có dev mới, mình chỉ mất 2 phút copy public key rồi dùng Ansible đẩy vào authorized_keys là xong. Thế nhưng, khi hệ thống vọt lên 50+ server, đi kèm hàng chục cụm Kubernetes (K8s) và database, quy trình “thủ công mỹ nghệ” này bắt đầu bộc lộ lỗ hổng.
Ác mộng thực sự đến khi có nhân sự nghỉ việc. Mình từng mất nguyên một buổi chiều chỉ để rà soát và gỡ key của một bạn trên hàng chục máy chủ. Chỉ cần sót đúng một máy, đó sẽ là một cái cửa hậu (backdoor) đầy rủi ro. Ngoài ra, việc anh em share chung tài khoản root khiến việc truy cứu trách nhiệm gần như bất khả thi. Nếu ai đó lỡ tay rm -rf vào 2 giờ sáng, mình cũng chẳng biết ai là thủ phạm vì audit log của SSH quá sơ sài.
Tại sao SSH Key truyền thống lại dễ “phản chủ”?
Vấn đề cốt lõi nằm ở Static Credentials (thông tin đăng nhập tĩnh). Một cặp SSH Key thường có giá trị vĩnh viễn cho đến khi bị xóa thủ công. Trong môi trường doanh nghiệp, đây là rủi ro tiềm tàng vì:
- Danh tính lỏng lẻo: SSH Key gắn với máy tính, không gắn với con người. Nếu laptop của dev bị đánh cắp hoặc nhiễm malware, kẻ xấu có thể ung dung vào server mà không cần qua lớp bảo vệ nào.
- Phân quyền (RBAC) cực hình: Việc quy định ông A chỉ được vào Web Server, ông B chỉ được vào DB Server bằng SSH truyền thống là một thử thách về mặt quản trị.
- Kubeconfig rò rỉ: File cấu hình Kubernetes chứa chứng chỉ dài hạn thường được anh em tiện tay lưu trong Slack hay Google Drive, cực kỳ dễ mất kiểm soát.
Những phương án “chống cháy” không mấy hiệu quả
Trước khi biết tới Teleport, mình đã thử dùng Jump Host (Bastion Host). Cách này giúp ẩn server khỏi internet nhưng vẫn dùng key tĩnh. Mình cũng từng viết script tự động xoay vòng (rotate) key hàng tuần. Tuy nhiên, script càng chạy càng phát sinh lỗi, có lần lỗi script khiến cả team DevOps bị khóa ngoài hệ thống suốt 2 tiếng.
Một số bên dùng VPN như WireGuard hay OpenVPN. Đây là giải pháp tốt ở lớp mạng nhưng lại bỏ ngỏ lớp định danh. VPN chỉ cho phép bạn “vào nhà”, còn việc bạn làm gì trong phòng (server) thì nó không quan tâm và cũng không ghi chép lại.
Teleport: Giải pháp quản lý truy cập tập trung mình ưng ý nhất
Sau 6 tháng thực chiến trên production, mình thấy Teleport đã giải quyết triệt để bài toán bảo mật. Thay vì dùng key tĩnh, Teleport sử dụng Short-lived Certificates. Khi login, bạn được cấp một chứng chỉ chỉ có hiệu lực trong vài giờ (thường mình set là 8 tiếng làm việc). Hết giờ, chứng chỉ tự hủy, mọi quyền truy cập đóng lại.
Ba tính năng giúp mình “kê cao gối ngủ”:
- SSO làm gốc: Tích hợp thẳng với Google Workspace hoặc GitHub. User phải qua MFA (2FA) của công ty mới lấy được quyền SSH.
- Session Recording: Nó quay lại toàn bộ thao tác trên terminal như một đoạn video. Bạn có thể tua đi tua lại để xem anh em đã debug thế nào, cực kỳ hữu ích để đào tạo hoặc điều tra sự cố.
- Một cho tất cả: Quản lý tập trung từ SSH, Kubernetes cho đến Database (Postgres, MySQL…) trên duy nhất một giao diện.
Hướng dẫn triển khai Teleport nhanh
Bạn cần một server làm Teleport Proxy & Auth. Hãy chuẩn bị sẵn một tên miền và SSL certificate (Certbot là lựa chọn quốc dân).
1. Cài đặt lên Ubuntu
Chạy lệnh sau để lấy bản ổn định nhất:
curl https://apt.releases.teleport.dev/gpg -o /usr/share/keyrings/teleport-archive-keyring.asc
echo "deb [signed-by=/usr/share/keyrings/teleport-archive-keyring.asc] https://apt.releases.teleport.dev/ubuntu $(lsb_release -cs) stable main" | sudo tee /etc/apt/sources.list.d/teleport.list
sudo apt update && sudo apt install teleport
2. Cấu hình tự động
Giả sử domain của bạn là teleport.example.com. Lệnh này sẽ tự sinh file config chuẩn:
sudo teleport configure --acme [email protected] --cluster-name=teleport.example.com -o /etc/teleport.yaml
sudo systemctl enable --now teleport
3. Khởi tạo Admin
Tạo một user quản trị ban đầu để vào giao diện Web:
sudo tctl users add admin --roles=editor,access --logins=root,ubuntu
Copy link hiển thị ra trình duyệt để đặt mật khẩu và quét mã OTP.
Trải nghiệm thực tế: Tạm biệt lệnh ssh cũ kỹ
Bây giờ, team mình không còn gõ ssh user@ip nữa. Thay vào đó là tool tsh thần thánh:
# Login một lần duy nhất vào buổi sáng
tsh login --proxy=teleport.example.com
# Xem danh sách máy chủ mình có quyền vào
tsh ls
# Truy cập server bằng tên gợi nhớ
tsh ssh root@web-server-01
Điểm cộng lớn là tsh tự cấu hình kubeconfig cho bạn. Chỉ cần lệnh tsh kube login, bạn có thể dùng kubectl ngay lập tức mà không cần cầm file cert đi khắp nơi.
Bài học xương máu sau nửa năm vận hành
Nếu định đưa Teleport vào production, bạn cần lưu ý:
- Bảo vệ Auth Server: Nếu server này sập, cả team sẽ không thể truy cập bất cứ đâu. Hãy ưu tiên backup dữ liệu cấu hình thường xuyên.
- Phân quyền tối thiểu: Đừng cấp quyền
rootcho tất cả mọi người. Team Dev chỉ nên có role vào Staging, chỉ DevOps mới được chạm vào Production. - Giám sát Audit Log: Hãy đẩy log của Teleport về ELK hoặc Splunk. Nếu có sự cố, đây là bằng chứng thép giúp bạn tìm ra nguyên nhân gốc rễ chỉ trong vài phút.
Chuyển từ SSH sang Teleport cũng giống như đổi từ khóa cơ sang khóa vân tay thông minh. Có thể lúc đầu lắp đặt hơi kỳ công, nhưng sự an tâm và chuyên nghiệp mà nó mang lại là hoàn toàn xứng đáng với công sức bỏ ra.

