Posted inVMware

Cấu hình VMware vCenter xác thực tập trung với Google Workspace qua OIDC: Thay thế LDAP và Active Directory

VMware tutorial - IT technology blog
VMware tutorial - IT technology blog

Vấn đề thực tế: Quản lý tài khoản vCenter khi team IT mở rộng

Mình quản lý cluster VMware với 8 host ESXi tại công ty, và đây là vấn đề mình đối mặt thực tế: ban đầu chỉ có 2–3 người access vCenter, dùng local account cho tiện. Rồi team mở rộng lên 8 người, thêm cả bên outsource vào, và bắt đầu loạn. Người nghỉ việc mà quên disable account, người mới vào phải chờ IT tạo thủ công, reset password thì ping Slack liên tục mỗi tuần.

Giải pháp đầu tiên nghĩ đến là LDAP hoặc Active Directory — tiêu chuẩn truyền thống của enterprise. Nhưng công ty mình 100% dùng Google Workspace, không có Windows Server nào cả. Dựng một AD server chỉ để authenticate vCenter thì chi phí và công sức hoàn toàn không xứng.

Tại sao LDAP và Active Directory không phải lúc nào cũng là lựa chọn phù hợp

LDAP và AD hoạt động tốt trong môi trường on-premise thuần Windows. Chuyển sang cloud-first hoặc Google Workspace thì một loạt vấn đề thực tế nổi lên:

  • Cần dựng thêm Windows Server Domain Controller — tốn license, tốn resource VM
  • LDAP dùng plain text nếu không cấu hình LDAPS cẩn thận — đây là security risk rõ ràng
  • Sync group từ Google Workspace vào AD là bài toán riêng, phức tạp và dễ lệch
  • Khi off-board user bên Google, AD không tự đồng bộ ngay — có độ trễ nguy hiểm

Mình đã dính đúng cái này một lần: LDAP bind account hết hạn password lúc 2 giờ sáng, toàn bộ authentication vCenter sập — không ai login được. Với OIDC, dependency này không còn tồn tại.

Các cách giải quyết và so sánh thực tế

Có ba hướng chính khi muốn tập trung xác thực vCenter:

  • LDAP/LDAPS: Cần directory server riêng, quản lý phức tạp, sync lag khi off-board
  • Active Directory: Tốt nếu đã có AD sẵn, nhưng không phù hợp môi trường Google Workspace-first
  • OIDC (OpenID Connect): Chuẩn hiện đại, hỗ trợ từ vCenter 7.0 U2, tích hợp thẳng với Google Workspace không cần trung gian

Từ vCenter Server 7.0 U2, VMware hỗ trợ External Identity Provider theo chuẩn OIDC. Google Workspace trở thành nguồn xác thực duy nhất — không cần dựng thêm server nào cả.

Cách tốt nhất: Cấu hình OIDC với Google Workspace từng bước

Bước 1 — Tạo OAuth 2.0 Client trên Google Cloud Console

Truy cập https://console.cloud.google.com, chọn project hoặc tạo project mới dành riêng cho internal tools.

Vào APIs & Services → OAuth consent screen:

  • User Type: Internal — chỉ user trong Google Workspace domain của bạn mới login được
  • Điền App name (ví dụ: vCenter SSO), User support email, Developer contact

Tiếp theo vào Credentials → Create Credentials → OAuth 2.0 Client ID:

  • Application type: Web application
  • Authorized redirect URIs: https://<vcenter-fqdn>/ui/login/oauth2/authcode

Sau khi tạo xong, lưu lại Client ID và Client Secret — hai giá trị này cần ở bước tiếp theo:

Client ID:     1234567890-abcdefgh.apps.googleusercontent.com
Client Secret: GOCSPX-xxxxxxxxxxxxxxxxxxxxxxxx

Bước 2 — Cấu hình Identity Provider trên vCenter

Đăng nhập vCenter bằng tài khoản [email protected], sau đó:

  1. Vào Administration → Single Sign On → Configuration → Identity Provider
  2. Click Change Identity Provider
  3. Chọn Microsoft ADFS — đừng nhầm! vCenter gọi chung là ADFS nhưng thực ra chấp nhận bất kỳ OIDC provider nào

Điền thông tin kết nối:

Client Identifier:  <Client ID từ Google>
Shared Secret:      <Client Secret từ Google>
OpenID Address:     https://accounts.google.com
Redirect URI:       https://<vcenter-fqdn>/ui/login/oauth2/authcode

vCenter tự động discover các endpoint của Google qua https://accounts.google.com/.well-known/openid-configuration. Điền domain Google Workspace của bạn (ví dụ: company.com) và lưu lại.

Bước 3 — Phân quyền user trong vCenter

Sau khi lưu cấu hình OIDC, đăng xuất khỏi vCenter — màn hình login sẽ xuất hiện nút Sign in with company.com. Thấy nút này là kết nối đã đúng, bước tiếp theo là phân quyền.

Thêm permission cho từng user:

  1. Vào Administration → Access Control → Global Permissions
  2. Click Add → Search user bằng email Google ([email protected])
  3. Assign role phù hợp: Read-Only, Virtual Machine Power User, Administrator…

Có nhiều user cần assign cùng lúc thì dùng PowerCLI cho nhanh:

Connect-VIServer -Server vcenter.company.com

$users = @(
    "[email protected]",
    "[email protected]",
    "[email protected]"
)

foreach ($user in $users) {
    New-VIPermission -Entity (Get-Folder -NoRecursion) `
        -Principal $user `
        -Role "ReadOnly" `
        -Propagate $true
    Write-Host "Added: $user"
}

Bước 4 — Lưu ý về Group Claims

Google OIDC không tự động include group membership trong JWT token. Đây là điểm hay gây lúng túng khi mới cấu hình. Có hai hướng xử lý:

  • Option A: Dùng Google Cloud Directory Sync (GCDS) để sync Google Groups vào LDAP phụ — nhưng lại đưa LDAP quay lại…
  • Option B (mình đang dùng): Quản lý permission trực tiếp theo email user thay vì group. Dưới 20 người thì hoàn toàn ổn, dùng PowerCLI để bulk assign khi cần.

Best practices sau khi triển khai

Giữ lại local SSO account làm break-glass

Cái này mình coi là bắt buộc, không thương lượng:

[email protected] — ĐỪNG bao giờ disable account này

Nếu Google OIDC có sự cố — dù chỉ là Google outage ngắn hay misconfiguration — bạn cần có cách login khẩn cấp vào vCenter. Local SSO account là cứu cánh cuối cùng khi mọi thứ hỏng.

Test off-boarding ngay sau khi setup

Tạo test user trong Google Workspace → assign permission trong vCenter → suspend user bên Google Admin Console → verify không login được vào vCenter nữa. Bước này thường bị bỏ qua nhưng rất quan trọng.

Mình đã xác nhận: suspend user bên Google Admin Console là mất quyền login vCenter ngay lập tức. Không cần làm gì thêm ở phía vCenter. Đây là điểm mạnh nhất so với LDAP — với LDAP, nếu quên disable hoặc sync chậm, user vẫn có thể login một lúc sau khi off-board.

Monitor failed authentication

Theo dõi log SSO giúp phát hiện sớm brute force hoặc account bị revoke nhưng vẫn cố login:

# SSH vào vCenter Appliance, check log SSO:
tail -f /var/log/vmware/sso/vmware-sts-idmd.log

# Grep failed authentication:
grep "FAILED" /var/log/vmware/sso/vmware-sts-idmd.log | tail -50

Kiểm tra phiên bản vCenter trước khi cấu hình

OIDC chỉ hỗ trợ từ vCenter 7.0 U2 trở lên. vCenter 6.x không có tính năng này — phải nâng cấp trước.

# SSH vào vCenter Appliance:
cat /etc/applmgmt/applianceVersion

Từ khi chuyển sang OIDC + Google Workspace, cluster 8 ESXi với gần 200 VM không còn là gánh nặng quản lý tài khoản nữa. Onboard/offboard engineer giảm từ 15 phút xuống 0 phút ở phía vCenter — chỉ cần xử lý bên Google Admin Console là xong. Không còn account zombie. Không còn bind account hết hạn lúc nửa đêm. Và MFA của Google tự áp dụng cho cả vCenter, không cần cấu hình thêm gì.

Share:
Tags: