Cơn ác mộng mang tên “Quản lý SSH Key”
Hồi mới đi làm, mình từng mất cả buổi sáng chỉ để setup quyền truy cập cho một team dev 20 người. Quy trình cực kỳ thủ công: dev gửi Public Key, mình copy-paste vào file authorized_keys trên Bastion Host và từng server mục tiêu.
Mọi thứ bắt đầu rối tung khi nhân sự biến động. Một người nghỉ việc đồng nghĩa với việc mình phải rà soát hàng chục server để xóa key. Sau khi audit bảo mật cho hệ thống 15+ server, mình phát hiện ra những con số giật mình: hơn 30% key cũ vẫn tồn tại dù nhân sự đã nghỉ từ lâu. Bastion Host lúc này không còn là lớp bảo vệ mà trở thành cái “rốn” rủi ro. Chỉ cần một private key bị lộ, toàn bộ hạ tầng coi như phơi bày trước hacker.
Tại sao mô hình Bastion Host truyền thống đã lỗi thời?
Vấn đề không nằm ở giao thức SSH. Lỗi nằm ở cách chúng ta quản trị nó. Có 3 điểm yếu chí mạng khiến các SRE dần quay lưng với Bastion Host:
- Định danh mù mờ: Bastion Host chỉ quan tâm key có khớp hay không. Nó chẳng biết ai thực sự là người đang gõ lệnh. Nó hoàn toàn tách biệt với hệ thống quản lý nhân sự (IdP) như Google hay Okta.
- Quyền hạn quá rộng: Chỉ cần nhảy vào được Bastion, user thường có thể “vẫy vùng” trong toàn bộ mạng nội bộ. Điều này đi ngược lại nguyên tắc Quyền hạn tối thiểu (Least Privilege).
- Truy vết (Audit) là cực hình: Thấy log user
ubuntuxóa database lúc 2 giờ sáng, nhưngubuntuđó là ai trong 20 dev? Việc tìm ra thủ phạm thường mất cả ngày rà soát log SSH thủ công.
Những giải pháp thay thế thường gặp
Trước khi biết đến Boundary, mình đã thử qua vài phương án chữa cháy:
- Dùng VPN: Cách này an toàn hơn nhưng lại cấp quyền ở mức Network (Lớp 3). User vào VPN là “thấy” cả những server họ không được phép chạm vào.
- SSH Certificate Authority (SSH CA): Giải pháp này chuyên nghiệp vì dùng key có thời hạn. Tuy nhiên, việc vận hành một hệ thống CA riêng là quá sức với các team nhỏ hoặc startup.
- Identity-aware Proxy (Boundary): Đây là chân ái. Thay vì kiểm tra IP hay Key, hệ thống xác thực dựa trên Định danh (Identity). Bạn là ai thì bạn mới được thấy những gì thuộc về mình.
HashiCorp Boundary: Truy cập hạ tầng không cần Key
Boundary giúp bạn kết nối vào server mà không cần quan tâm IP hay quản lý file key phức tạp. Bạn chỉ cần đăng nhập bằng tài khoản công ty. Sau đó, Boundary tự động thiết lập một đường truyền bảo mật tạm thời đến đúng tài nguyên cần thiết.
Bước 1: Khởi tạo nhanh với chế độ Dev
Đừng vội cài đặt phức tạp. Hãy thử chế độ dev để hiểu cách nó vận hành trong 5 phút. Nó sẽ tự dựng một môi trường demo ngay trong bộ nhớ máy bạn.
# Cài đặt trên Ubuntu
wget -O- https://apt.releases.hashicorp.com/gpg | sudo gpg --dearmor -o /usr/share/keyrings/hashicorp-archive-keyring.gpg
echo "deb [signed-by=/usr/share/keyrings/hashicorp-archive-keyring.gpg] https://apt.releases.hashicorp.com $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/hashicorp.list
sudo apt update && sudo apt install boundary
# Chạy Boundary dev mode
boundary dev
Sau lệnh này, terminal sẽ hiện ra Auth Method ID và mật khẩu. Hãy mở trình duyệt truy cập http://127.0.0.1:9200 để bắt đầu khám phá giao diện quản trị.
Bước 2: Thiết lập Target và Host
Cấu trúc của Boundary đi theo phân cấp: Host Catalog -> Host Group -> Host -> Target.
Trong thực tế, việc chia subnet cho Worker rất quan trọng. Mình thường dùng IP Subnet Calculator để tính toán dải IP cho các vùng mạng riêng biệt. Việc này giúp các Worker kết nối tới target chính xác, tránh xung đột IP giữa các môi trường Staging và Prod.
Dưới đây là cách tạo một Target SSH bằng dòng lệnh:
# Tạo scope cho dự án
boundary scopes create -name "Project_Alpha" -scope-id "global"
# Khai báo danh sách server
boundary host-catalogs create static -name "Backend_Pool" -scope-id "p_1234567890"
# Thêm server cụ thể
boundary hosts create static -name "DB_Master" -address "10.0.1.50" -host-catalog-id "hc_1234567890"
Bước 3: Kết nối “một chạm”
Quên lệnh ssh root@ip đi. Với Boundary, bạn chỉ cần một lệnh duy nhất. Hệ thống sẽ tự tạo một proxy trung gian ngay tại máy local.
boundary connect ssh -target-id t_1234567890
Boundary tự động mở một cổng local và map thẳng vào server đích. Bạn vẫn dùng được các tool quen thuộc như Termius hay iTerm2. Điểm cộng lớn nhất là mọi phiên làm việc đều được ghi lại (Session Recording). Nếu có sự cố, bạn chỉ cần xem lại “cuộn băng” để biết chuyện gì đã xảy ra.
Mẹo nhỏ khi triển khai thực tế
Khi cấu hình các file YAML phức tạp cho Boundary, mình hay dùng YAML ↔ JSON Converter để kiểm tra cú pháp. Công cụ này chạy 100% trên trình duyệt nên cực kỳ an toàn. Bạn không lo bị lộ thông tin hạ tầng nhạy cảm lên server của bên thứ ba.
Nếu bạn cần tạo các token hoặc ID định danh không trùng lặp cho hệ thống, hãy ghé qua UUID Generator. Nó giúp tạo nhanh các chuỗi UUID v4 chuẩn xác để gán cho các resource trong Boundary.
Lời khuyên cho môi trường Production
Chế độ dev chỉ để học tập. Khi triển khai thật, hãy lưu ý 3 nguyên tắc:
- Cô lập Controller: Đặt Controller ở vùng mạng an toàn nhất. Chỉ Worker mới cần tiếp xúc trực tiếp với Target server.
- Bảo mật Root Key: Luôn dùng AWS KMS hoặc HashiCorp Vault để mã hóa các khóa gốc của Boundary.
- Tích hợp OIDC ngay lập tức: Đừng bao giờ tạo user bằng tay. Hãy kết nối với Google Workspace. Khi một nhân viên nghỉ việc, bạn chỉ cần khóa mail là xong. Mọi quyền truy cập server của họ sẽ bốc hơi ngay lập tức trong 1 giây.
Chuyển đổi từ tư duy “giữ chìa khóa” sang “xác thực định danh” là bước đi sống còn của DevOps hiện đại. Nó không chỉ bảo vệ hệ thống tốt hơn mà còn giúp team SRE thoát khỏi những tác vụ lặp đi lặp lại nhàm chán.

