Published Jan 13th, 8:15 p.m. 10 min read

117

Gemini CLI Nâng cao: Xây dựng kết nối MCP an toàn và xác thực

Khi Giao thức Ngữ cảnh Mô hình (Model Context Protocol - MCP) ngày càng phổ biến, ngày càng có nhiều lập trình viên bắt đầu sử dụng Gemini CLI để gỡ lỗi (debug) và kết nối với các máy chủ MCP khác nhau. Cho dù là kết nối với một bộ công cụ đơn giản hay giao tiếp với các dịch vụ cấp doanh nghiệp có kiểm soát quyền hạn nghiêm ngặt trên Google Cloud, việc lựa chọn phương thức xác thực phù hợp là điều không thể thiếu để đảm bảo cả tính bảo mật và khả năng sẵn sàng.

Cài đặt Gemini CLI

Nếu bạn chưa cài đặt Gemini CLI, bạn có thể thiết lập nhanh chóng bằng cách sau.

Quản lý phiên bản Node

Gemini CLI phụ thuộc vào môi trường Node.js. Ở đây, chúng ta vẫn sử dụng ServBay để quản lý phiên bản Node.js.

ServBay hỗ trợ cài đặt môi trường Node.js mới nhất chỉ với một cú nhấp chuột, và hỗ trợ phủ sóng toàn bộ các phiên bản từ Node 12 đến Node 24. Hơn nữa, ServBay cho phép các phiên bản Node.js khác nhau cùng tồn tại song song mà không cần chuyển đổi lặp đi lặp lại hay cấu hình biến môi trường, tạo nền tảng vững chắc để chạy và debug Gemini CLI.

Đảm bảo ServBay đang chạy và module Node đã được kích hoạt, sau đó cài đặt Gemini CLI:

npm install -g @google/gemini-cli

Tiếp theo, hãy xem cách định nghĩa bảo mật trong môi trường CLI.

Định nghĩa bảo mật trong môi trường CLI

Khi chạy CLI cục bộ, bảo mật không chỉ là mã hóa đường truyền (HTTPS), mà quan trọng hơn là quản lý thông tin xác thực (credential) và vòng đời của token.

Bảo mật thấp: Lưu API Key tĩnh, dài hạn dưới dạng văn bản thuần túy (plaintext) trong tệp cấu hình. Một khi tệp bị rò rỉ hoặc vô tình commit lên kho mã nguồn, thông tin xác thực sẽ bị lộ vĩnh viễn.
Bảo mật cao: Sử dụng Thông tin xác thực mặc định của ứng dụng (Application Default Credentials - ADC) hoặc mô phỏng tài khoản dịch vụ (Service Account impersonation). Các thông tin xác thực này thường được lưu trữ cục bộ nhưng có vòng đời ngắn và được Google Cloud CLI (gcloud) tự động làm mới. Ngay cả khi máy bị xâm nhập, thời gian tấn công của kẻ xấu cũng rất hạn chế.

Dưới đây là 4 chiến lược cấu hình xác thực chính.

1. HTTP Header tĩnh (API Keys & Bearer Tokens)

Đây là phương pháp trực tiếp nhất, áp dụng cho các dịch vụ bên thứ ba phụ thuộc vào API Key dài hạn hoặc Token truy cập cá nhân (PAT).

Mặc dù bạn có thể thêm chúng bằng cách chỉnh sửa tệp cấu hình, nhưng cách nhanh nhất là chỉ định trực tiếp qua tham số dòng lệnh khi thêm máy chủ. Gemini CLI cung cấp lệnh gemini mcp add, kết hợp với tham số --header.

Ví dụ dòng lệnh:

Giả sử bạn muốn thêm một dịch vụ thời tiết và bảo vệ nó bằng Bearer Token:

gemini mcp add weather-service https://api.weather-data.com/mcp \
    --transport http \
    --header "Authorization: Bearer secret-token-123"

Lệnh này sẽ tự động cập nhật tệp settings.json. Lưu ý rằng bạn cần định nghĩa rõ loại transport, vì chế độ mặc định là standard input/output (stdio) sẽ bỏ qua các HTTP header.

Ví dụ tệp cấu hình (settings.json):

Để tránh ghi Token dạng văn bản thuần túy vào tệp, Gemini CLI hỗ trợ tham chiếu biến môi trường trong tệp cấu hình. Khi CLI khởi tạo, ${ENV_VAR} sẽ được thay thế bằng giá trị thực tế.

{
  "mcpServers": {
    "data-tool": {
      "httpUrl": "https://api.myservice.com/mcp",
      "headers": {
        "Authorization": "Bearer ${APP_API_TOKEN}",
        "X-Org-Id": "org-888"
      }
    }
  }
}

Ưu điểm: Cấu hình đơn giản, dễ tạo thủ công.
Nhược điểm: Rủi ro rò rỉ Token dài hạn.

2. Google Credentials (`google_credentials`)

Đối với các nhà phát triển trong hệ sinh thái Google Cloud, đây là giải pháp ưu tiên hàng đầu. Nó tự động tận dụng thông tin xác thực của môi trường cục bộ — thường là ADC hoặc phiên gcloud đang kích hoạt.

Gemini CLI sẽ chặn yêu cầu và tiêm (inject) Google ID Token thuộc về người dùng hiện tại vào. Điều này cực kỳ phù hợp để gọi các dịch vụ MCP riêng tư được triển khai trên Cloud Run hoặc Cloud Functions.

Ví dụ cấu hình (settings.json):

Chỉ cần chỉ định trường authProviderType:

{
  "mcpServers": {
    "cloud-logger": {
      "httpUrl": "https://logger-service-abc.a.run.app/sse",
      "authProviderType": "google_credentials"
    }
  }
}

Ưu điểm: Sử dụng Token ngắn hạn, có thể luân chuyển, độ bảo mật cao.
Nhược điểm: Phụ thuộc vào trạng thái đăng nhập của gcloud.

3. Mô phỏng tài khoản dịch vụ (`service_account_impersonation`)

Trong khi google_credentials sử dụng danh tính cá nhân, thì mô phỏng tài khoản dịch vụ (Service Account Impersonation) cho phép Gemini CLI sử dụng một danh tính độc lập, chỉ dành cho máy móc.

Trong phát triển cục bộ, cách này chủ yếu dùng để mô phỏng môi trường production (kiểm tra hành vi của Bot dưới các quyền hạn bị hạn chế) hoặc cách ly danh tính (khi máy chủ MCP mục tiêu từ chối người dùng thật và chỉ chấp nhận các Service Account cụ thể).

Quy trình làm việc:

Người dùng yêu cầu đóng vai Service Account.
Google IAM xác minh xem người dùng có vai trò "Token Creator" hay không.
Gemini CLI lấy Token đại diện cho Service Account đó và dùng nó để truy cập dịch vụ mục tiêu.

Ví dụ cấu hình (settings.json):

{
  "mcpServers": {
    "finance-bot": {
      "httpUrl": "https://secure-finance.a.run.app/sse",
      "authProviderType": "service_account_impersonation",
      "targetServiceAccount": "bot-sa@my-gcp-project.iam.gserviceaccount.com",
      "targetAudience": "https://secure-finance.a.run.app"
    }
  }
}

Lưu ý: Nếu là dịch vụ Cloud Run, targetAudience thường chính là URL của dịch vụ.

Thiết lập quyền hạn (IAM):

Bạn phải cấp quyền cho tài khoản người dùng hiện tại để mô phỏng Service Account.

# Định nghĩa biến
export PROJ_ID="my-gcp-project"
export SA_EMAIL="bot-sa@${PROJ_ID}.iam.gserviceaccount.com"
export MY_EMAIL="developer@company.com"

# Cấp vai trò Token Creator
gcloud iam service-accounts add-iam-policy-binding "${SA_EMAIL}" \
    --member="user:${MY_EMAIL}" \
    --role="roles/iam.serviceAccountTokenCreator" \
    --project="${PROJ_ID}"

Thay đổi quyền IAM có tính nhất quán cuối cùng (eventual consistency), có thể cần đợi một hoặc hai phút để có hiệu lực.

Ưu điểm: Tuân thủ nguyên tắc đặc quyền tối thiểu (least privilege), kiểm soát quyền hạn nghiêm ngặt.
Nhược điểm: Cấu hình IAM tương đối rườm rà.

4. Hỗ trợ OAuth 2.0 tích hợp sẵn

Đối với các dịch vụ bên thứ ba phức tạp như GitHub, Linear hoặc Slack yêu cầu quy trình đăng nhập người dùng tiêu chuẩn, Gemini CLI đã tích hợp sẵn trình xử lý OAuth.

Cách dùng lệnh Shell:

Trước khi bắt đầu làm việc, bạn có thể hoàn tất xác thực thông qua lệnh Shell.

# Xem danh sách dịch vụ cần xác thực
gemini mcp auth

# Khởi động quy trình đăng nhập dịch vụ GitLab (bật trình duyệt)
gemini mcp auth gitlab-server

Cách dùng lệnh tương tác:

Nếu gặp lỗi quyền hạn trong phiên tương tác của Gemini CLI, bạn không cần thoát công cụ, chỉ cần nhập lệnh trực tiếp trong hộp thoại:

>>> User: Hãy liệt kê các việc cần làm của tôi.
>>> Gemini: Tôi cần quyền truy cập Linear.
>>> /mcp auth linear-server

Ưu điểm: Quy trình OAuth chuẩn, tự động làm mới Token, trải nghiệm người dùng tốt.
Nhược điểm: Cần tương tác với trình duyệt định kỳ để đăng nhập.

Tổng kết

Việc chọn phương thức xác thực nào phụ thuộc vào vị trí lưu trữ thông tin xác thực và kịch bản sử dụng:

Header tĩnh: Thích hợp cho các dịch vụ bên thứ ba cung cấp API Key chung. Nên dùng kèm biến môi trường để tránh lưu văn bản thuần túy.
Google Credentials: Thích hợp cho phát triển công cụ nội bộ Google Cloud, nhanh và an toàn.
Mô phỏng Service Account: Thích hợp cho kiểm tra quyền hạn hoặc các kịch bản cần cách ly danh tính nghiêm ngặt.
OAuth tích hợp: Thích hợp cho các kịch bản cần thay mặt người dùng thao tác trong hệ sinh thái bên thứ ba (như GitHub PR).

Bất kể chọn cách nào, đảm bảo sự ổn định của môi trường Node.js nền tảng là bước đầu tiên. Sử dụng ServBay để quản lý phiên bản Node có thể giúp tránh hiệu quả các lỗi runtime do sự khác biệt về môi trường.