[Series Zero Trust Hạ Tầng] Bài 4: Bảo Mật Cực Hạn – Quản Lý Truy Cập Database Và Cụm Kubernetes Toàn Diện

Chào các bạn, chào mừng các bạn đã quay trở lại với series Làm chủ Teleport. Ở Bài 3, chúng ta đã làm chủ kỹ thuật mở rộng hạ tầng, add thêm Server vệ tinh và thiết lập các hàng rào phân quyền RBAC cực kỳ chặt chẽ kèm theo tính năng quay video Terminal.

Hôm nay, chúng ta sẽ cùng nhau tiến sâu hơn vào hai thành phần cốt lõi và nhạy cảm nhất của bất kỳ hệ thống công nghệ nào: Database (Cơ sở dữ liệu) và Kubernetes Cluster.

Thông thường, để Dev hoặc Data Analyst vào check data, chúng ta hay phải cấp cho họ một tài khoản Database với mật khẩu tĩnh, hoặc share file config của cụm K8s. Việc này tiềm ẩn rủi ro cực lớn nếu máy tính của nhân sự bị tấn công hoặc file config bị lộ. Hãy xem Teleport giải quyết bài toán này tinh tế như thế nào nhé!

1. Teleport Database Access: Tạm Biệt Mật Khẩu Tĩnh

Cơ chế của Teleport đối với Database là nó đóng vai trò như một Database Proxy. Thay vì client kết nối trực tiếp vào DB, bạn sẽ dùng lệnh của Teleport để tự động sinh ra một chứng chỉ ngắn hạn (Short-lived X.509 Certificate) dựa trên danh tính SSO của bạn và dùng nó để authenticate với DB.

Các bước kết nối một Database (Ví dụ: PostgreSQL) vào Teleport:

1. Cấu hình Teleport Agent trên Database Server: Bạn sửa file /etc/teleport.yaml trên con server đang chạy Database hoặc một máy trung gian có quyền kết nối tới DB:

db_service:
  enabled: "yes"
  databases:
    - name: "postgres-prod"
      description: "Database Production của Hệ Thống"
      protocol: "postgres"
      uri: "localhost:5432"
      # Gán nhãn để phân quyền RBAC
      labels:
        env: production

2. Khởi động lại Teleport: sudo systemctl restart teleport. Lúc này, trên giao diện Web UI mục Databases sẽ xuất hiện thực thể postgres-prod.

Trải nghiệm phía Developer (Client):

Để kết nối vào DB này từ máy local, Developer không cần biết password của DB là gì, họ chỉ cần chạy 2 lệnh sau trên Terminal máy mình:

# 1. Login vào Teleport Cluster
tsh login --proxy=teleport.yourdomain.com:443

# 2. Login vào Database cụ thể
tsh db login postgres-prod

Ngay sau lệnh này, Teleport sẽ cấu hình một proxy cục bộ ở máy dev và hiển thị một câu lệnh giúp họ tích hợp thẳng vào các công cụ GUI quen thuộc như DBeaver, DataGrip hoặc dùng trực tiếp CLI:

tsh db connect postgres-prod

Toàn bộ các câu lệnh query dữ liệu (như SELECT, UPDATE, DROP) đều được Teleport ghi nhận lại vào hệ thống Audit Log để phục vụ việc kiểm toán sau này.

2. Teleport Kubernetes Access: Kiểm Soát Chặt Chẽ Lệnh kubectl

Đối với Kubernetes, Teleport hoạt động như một API Group Access Control. Nó thay thế hoàn toàn các file kubeconfig dài hạn bằng các token xác thực theo phiên làm việc.

Các bước add cụm K8s vào Teleport qua Helm Chart: Cách nhanh nhất để kết nối một cụm K8s (như EKS, GKE, hay cụm tự dựng K8s nội bộ) là sử dụng Helm để cài đặt teleport-kube-agent thẳng vào trong cluster.

# 1. Thêm Helm repo của Teleport
helm repo add teleport https://charts.releases.teleport.dev

# 2. Cài đặt Agent vào cụm K8s của bạn
helm install teleport-agent teleport/teleport-kube-agent \
  --set kubeClusterName=k8s-staging \
  --set proxyAddr=teleport.yourdomain.com:443 \
  --set authToken=YOUR_JOIN_TOKEN_HERE \
  --create-namespace \
  --namespace teleport-agent

(Bạn có thể lấy YOUR_JOIN_TOKEN_HERE bằng cách chạy lệnh tctl tokens add --type=kube trên server Teleport Auth).

Thực thi lệnh kubectl an toàn: Khi Agent đã active, Dev/DevOps muốn tương tác với cụm K8s chỉ cần gõ:

# Chọn cụm K8s muốn làm việc
tsh kube login k8s-staging

Lệnh này sẽ tự động cập nhật file ~/.kube/config ở máy local của bạn với một certificate có thời hạn (thường là vài tiếng). Bây giờ bạn có thể dùng các lệnhkubectl get pods, kubectl logs như bình thường.

Nếu bạn chạy lệnh kubectl exec để chui vào trong Pod gõ lệnh, Teleport thậm chí còn ghi hình lại toàn bộ session gõ lệnh bên trong Pod đó giống hệt như tính năng Session Recording của SSH server! Quá đỉnh đúng không?

3. Phân Quyền RBAC Cho Database & Kubernetes

Tương tự như bài trước, chúng ta có thể bổ sung quyền hạn vào file Role YAML để giới hạn chính xác ai được vào DB/K8s nào, và được đóng vai trò (User/Group) nào trong đó:

kind: role
version: v7
metadata:
  name: data-engineer
spec:
  allow:
    # Cho phép vào các DB có nhãn env: production
    db_labels:
      'env': 'production'
    # Được phép login vào DB bằng user db_readonly (Không cho dùng tài khoản root/postgres admin)
    db_users: [db_readonly]

    # Cho phép vào cụm K8s staging
    kubernetes_labels:
      'env': 'staging'
    # Khi vào K8s, họ sẽ thuộc K8s Group là 'view' (Chỉ được xem, không được sửa/xóa pod)
    kubernetes_groups: [view]

Tạm kết Bài 4

Việc đưa Database và Kubernetes về dưới sự quản lý của Teleport là một bước nhảy vọt về mặt an ninh hệ thống cho doanh nghiệp của bạn. Giờ đây, bạn đã xóa bỏ hoàn toàn lỗ hổng mang tên "lộ mật khẩu database" và kiểm soát được từng hành vi can thiệp sâu vào các container đang chạy trên Production.

Ở Bài 5 (Bài cuối của series), chúng ta sẽ khép lại chuỗi bài học bằng một chủ đề vô cùng mới mẻ và thời sự: Cấu hình Teleport Application để bảo mật các Web App nội bộ và quản lý quyền truy cập cho hệ thống AI thông qua Model Context Protocol (MCP) Server.

Hãy tiếp tục nhấn Upvote bài viết và để lại bình luận chia sẻ nếu bạn đang triển khai K8s/Database tại dự án của mình nhé! Chúc các bạn cấu hình hệ thống thành công!