Xác thực người dùng Kubernetes với OIDC (Phần 2): Hướng dẫn dùng Authentik tự host

Ở Phần 1, chúng ta đã tích hợp OIDC với Microsoft Azure AD — giải pháp lý tưởng nếu tổ chức bạn đang dùng hệ sinh thái Microsoft 365. Nhưng nếu công ty bạn không dùng Azure, hoặc bạn muốn một Identity Provider tự host, không phụ thuộc vào cloud vendor, hoàn toàn miễn phí?

Trong bài này, mình sẽ hướng dẫn cấu hình Authentik kết hợp với Kubernetes — từ việc tạo OIDC application trên Authentik đến phân quyền RBAC trên cluster, hoàn toàn tự chủ trên hạ tầng của bạn.

Authentik là một open-source Identity Provider có thể tự deploy trên hạ tầng của bạn, hỗ trợ OIDC, SAML, LDAP và nhiều protocol khác. Giao diện quản trị trực quan, dễ cấu hình — và quan trọng là miễn phí :D.

Phạm vi bài viết sẽ không hướng dẫn cài đặt Authentik

I. Chuẩn bị

Một cluster Kubernetes mà bạn có quyền chỉnh sửa cấu hình kube-apiserver (bài viết sử dụng RKE2 để init Kubernetes).
Authentik server bạn đã deploy dùng làm Identity Provider.
Máy client để test có thể connect tới kube-apiserver và đã được cài đặt kubectl.

II. Cấu hình trên Authentik

Tạo Provider, tại giao diện Admin của Authentik, Chọn Application -> Provider -> New Provider -> OAuth2/OpenID Provider -> Next

Điền thông tin Provider của chúng ta và chọn Finish.

Chuyển qua mục Applications -> Create và điền thông tin application (Lưu ý Provider chọn Provider đã tạo ở bước trên)

Những thông tin cần thiết bao gồm:

OpenID Configuration Issuer: https://authentik.example.com/application/o/k8s-app-test-oidc/

Client ID: wh5CsEeiteVlj1WenHiUYtUCdmk92U9hU8Eh1HWe

Vậy là chúng ta đã cấu hình xong phần Application trên Authentik

III. Cấu hình kube-apiserver trên Kubernetes

Ở đây mình init cluster k8s bằng RKE2 nên sẽ sửa config tại /etc/rancher/rke2/config.yaml (đối với những cách init cluster khác sẽ có các file config đặt ở những vị trí khác nhau, hãy tìm hiểu thêm nhé)

Thêm config sau vào file config.yaml

kube-apiserver-arg:
- "oidc-issuer-url=https://authentik.example.com/application/o/k8s-app-test-oidc/"
- "oidc-client-id=wh5CsEeiteVlj1WenHiUYtUCdmk92U9hU8Eh1HWe"
- "oidc-username-claim=email"
- "oidc-groups-claim=groups"

Đây là 1 ví dụ của file config.yaml

Restart rke2-server bằng lệnh systemctl restart rke2-server.service

Tiếp theo chúng ta sẽ cấu hình tại máy client muốn sử dụng kubectl để quản trị cluster k8s.

IV. Cấu hình máy client

Đầu tiên cài đặt gói kubelogin theo hướng dẫn tại https://github.com/int128/kubelogin

Tạo file kubeconfig theo mẫu sau:

apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: <ca_cert của cluster>
    server: https://IP:6443
  name: default
contexts:
- context:
    cluster: default
    user: oidc-user
  name: oidc-context
current-context: oidc-context
kind: Config
preferences: {}
users:
- name: oidc-user
  user:
    exec:
        apiVersion: client.authentication.k8s.io/v1
        command: kubectl
        interactiveMode: IfAvailable
        args:
          - oidc-login
          - get-token
          - --oidc-issuer-url=https://authentik.example.com/application/o/k8s-app-test-oidc/
          - --oidc-client-id=wh5CsEeiteVlj1WenHiUYtUCdmk92U9hU8Eh1HWe
          - --oidc-extra-scope=profile,email,groups

Thử chạy lệnh kubectl để kiểm tra

Khi chạy lệnh trình duyệt sẽ popup 1 trang http://localhost:8000 để login bằng account Authentik.

Sau khi login xong kubectl đã lấy được username, group nhưng vì chúng ta chưa phân quyền cho user/group nên sẽ báo Forbidden.

Đây là dấu hiệu tốt! Lỗi Forbidden có nghĩa xác thực OIDC đã thành công — Kubernetes đã lấy được username và group từ token Authentik. Chúng ta chỉ cần tạo ClusterRoleBinding ở bước tiếp theo là xong.

Tiếp tục sử dụng RBAC trên K8S để phân quyền cho user/group có thể có những thao tác gì trên cluster K8S.

V. Phân quyền với Kubernetes RBAC

Thay vì gán quyền cho từng user, best practice là gán quyền theo group. Khi có nhân sự mới, chỉ cần thêm họ vào group trên Authentik — quyền truy cập K8S tự động có ngay, không cần tạo user thủ công. Ngược lại khi nhân sự nghỉ việc, chỉ cần disable/delete tài khoản Authentik là mất quyền toàn bộ.

Chúng ta tạo 1 group tên k8s-admin-group trên Authentik và add user vào group này.

Tạo ClusterRoleBinding để phân quyền cho group vừa tạo (quyền view)

Đã có quyền view nhưng chưa có quyền xoá/sửa

Sửa ClusterRoleBinding sang quyền cluster-admin

Đã có thể edit cluster k8s

Đã có quyền view nhưng chưa có quyền xoá/sửa

Từ giờ trở đi khi có các thay đổi về nhân sự, chúng ta chỉ cần tác động đến group trên Authentik mà không cần các bước như tạo user, cấp quyền trực tiếp trên cluster K8S.

Tip: Để buộc login lại hoặc tạo mới token hãy xoá thư mục cache tại $HOME/.kube/cache

VI. Kết luận

Sau khi hoàn thành các bước trên, bạn đã xây dựng được một hệ thống quản lý quyền truy cập Kubernetes tích hợp hoàn toàn với Authentik. Workflow quản lý từ đây rất đơn giản:

Nhân sự mới: Thêm vào group Authentik → tự động có quyền trên K8S ngay lập tức.
Nhân sự nghỉ việc: Disable hoặc Delete tài khoản Authentik → mất quyền toàn bộ trên K8S, không cần có thêm thao tác nào khác.
Thay đổi quyền: Di chuyển user giữa các group Authentik → quyền K8S thay đổi theo.

Qua 2 phần của series, chúng ta đã thấy dù dùng Azure AD hay Authentik, bản chất đều giống nhau: Kubernetes không cần quản lý identity, nó chỉ cần tin tưởng một bên thứ ba đã được xác thực. Đây là triết lý separation of concerns.

Với Developer hay SRE làm việc hàng ngày trên nhiều cluster, trải nghiệm cũng rõ rệt hơn: một lần login, dùng được mọi cluster, không phải quản lý hàng loạt kubeconfig hay sợ leak credential. Đây không còn là optional nữa - với bất kỳ tổ chức nào, tích hợp IdP nên được coi là baseline requirement, không phải nice-to-have.

Đọc thêm: Xây dựng SRE Agent tự động hóa vận hành Kubernetes với GPT-4o

Cảm ơn các bạn đã theo dõi series. Happy clustering!

TagTutorial VKS