Docker & Application

Tích hợp SSO OIDC với Authentik cho ứng dụng nội bộ

Hướng dẫn tự host Authentik trên Docker Compose kết nối SSO (Google/Microsoft/Local Directory), cấu hình OIDC provider cho Grafana, Portainer và Nextcloud.

Tích hợp SSO OIDC Authentik cho ứng dụng nội bộ Grafana Portainer và Nextcloud
MỤC LỤC

Khi quy mô đội ngũ kỹ thuật tăng lên, số lượng công cụ nội bộ phục vụ phát triển và vận hành thường nở rộ nhanh chóng. Một nhóm vận hành điển hình có thể sử dụng Grafana để theo dõi số liệu giám sát, Portainer để quản trị các máy chủ container, Nextcloud để chia sẻ tài liệu kiến trúc và Wiki.js để lưu trữ tài liệu quy trình.

Nếu không có giải pháp định danh tập trung ngay từ đầu, mỗi công cụ nói trên sẽ duy trì một bảng tài khoản riêng biệt. Tình trạng phân mảnh định danh khiến kỹ sư phải nhớ nhiều mật khẩu khác nhau, đồng thời tiềm ẩn rủi ro an toàn thông tin: người dùng có xu hướng đặt mật khẩu giống nhau trên nhiều công cụ, quản trị viên không thể bắt buộc xác thực hai bước (MFA) đồng bộ, và khi một nhân sự rời công ty, nguy cơ bỏ sót tài khoản tại các hệ thống ngách là rất lớn.

Trong kiến trúc quản trị quyền truy cập hạ tầng doanh nghiệp, việc đưa vào một hệ thống Quản lý Định danh tập trung (Identity Provider - IdP) hỗ trợ Single Sign-On (SSO) là bước đi bắt buộc. Thay vì phải phụ thuộc vào các dịch vụ SaaS tốn kém với chi phí tính theo từng đầu người dùng, bài viết này hướng dẫn bạn cách tự host Authentik trên Docker Compose, chuẩn hóa nguồn định danh và cấu hình giao thức OpenID Connect (OIDC) để đăng nhập tập trung vào các công cụ nội bộ như Grafana và Portainer.

Kiến trúc đăng nhập tập trung Single Sign-On (SSO) qua Authentik OIDC

Tại sao chọn Authentik làm Identity Provider tự lưu trữ?

Trong hệ sinh thái các giải pháp định danh mã nguồn mở, Authentik nổi lên nhờ sự cân bằng giữa tính năng doanh nghiệp, giao diện trực quan và khả năng tùy biến luồng làm việc (flows) linh hoạt:

  1. Hỗ trợ đầy đủ các giao thức hiện đại: Authentik hỗ trợ chuẩn xác thực OpenID Connect (OIDC), OAuth 2.0, SAML 2.0 và LDAP Outpost. Đặc biệt, tính năng Forward Auth cho phép bạn gắn lớp bảo vệ đăng nhập SSO phía trước các ứng dụng web nội bộ cũ vốn không hỗ trợ sẵn bất kỳ giao thức OAuth nào.
  2. Quản trị luồng xác thực linh hoạt (Authentication & Authorization Flows): Bạn có thể quy định chính xác điều kiện để một người dùng được cấp quyền truy cập: bắt buộc bật xác thực hai yếu tố (TOTP hoặc khóa bảo mật cứng FIDO2/WebAuthn), kiểm tra dải IP mạng nội bộ, hoặc yêu cầu người dùng phải thuộc một nhóm phân quyền cụ thể.
  3. Cơ chế Outpost độc đáo: Authentik cho phép triển khai các Outpost (điểm trung gian xác thực) trên các máy chủ vệ tinh khác nhau, giúp bảo vệ các ứng dụng nội bộ phân tán mà không cần mở kết nối cơ sở dữ liệu trực tiếp về máy chủ trung tâm.
  4. Tiết kiệm tài nguyên hơn Keycloak: So với giải pháp truyền thống như Keycloak chạy trên nền tảng Java Virtual Machine (JVM) thường chiếm dụng từ 1.5GB đến 2GB RAM chỉ để khởi động, Authentik được tối ưu với lõi viết bằng Go kết hợp Python, hoạt động mượt mà trên các gói VPS chỉ có từ 2GB đến 4GB RAM.

Mô hình luồng xác thực OpenID Connect chuẩn

Để cấu hình và xử lý sự cố chính xác, bạn cần nắm vững luồng trao đổi dữ liệu theo chuẩn OpenID Connect Authorization Code Flow kết hợp cơ chế bảo vệ PKCE:

  1. Khởi tạo yêu cầu: Khi kỹ sư truy cập Grafana và nhấn vào nút "Sign in with Authentik", Grafana đóng vai trò là Bên dựa vào định danh (Relying Party - RP) sẽ chuyển hướng trình duyệt của người dùng đến Authentik (Identity Provider - IdP). Yêu cầu này mang theo mã định danh ứng dụng (client_id), địa chỉ nhận kết quả (redirect_uri), danh sách quyền yêu cầu (scope=openid profile email groups) và một chuỗi ngẫu nhiên (state) để phòng chống tấn công giả mạo yêu cầu chéo trang (CSRF).
  2. Xác thực và cấp quyền tại IdP: Authentik hiển thị giao diện đăng nhập. Kỹ sư nhập tài khoản, mật khẩu và mã xác thực hai bước (TOTP hoặc Touch ID qua WebAuthn). Authentik đối chiếu quyền hạn: nếu tài khoản hợp lệ và nằm trong nhóm được cấp phép, Authentik sẽ tạo một mã ủy quyền tạm thời (Authorization Code) có hiệu lực rất ngắn (thường dưới 60 giây).
  3. Chuyển hướng trả mã: Authentik chuyển hướng trình duyệt của kỹ sư quay trở lại địa chỉ redirect_uri của Grafana kèm theo Authorization Code.
  4. Trao đổi Token ở kênh máy chủ nội bộ (Back-channel): Backend của Grafana sẽ trực tiếp gọi một yêu cầu HTTP POST tới Authentik Token Endpoint (/application/o/token/) qua mạng nội bộ, gửi kèm Authorization Code và client_secret. Vì bước này diễn ra trực tiếp giữa hai máy chủ và không đi qua trình duyệt người dùng, thông tin bí mật không bao giờ bị lộ ra ngoài.
  5. Cấp phát định danh: Authentik xác minh mã, sau đó trả về cho Grafana hai token quan trọng:
  • id_token: Một chuỗi JSON Web Token (JWT) có chữ ký số chứa thông tin định danh người dùng (tên, email, danh sách nhóm).
  • access_token: Token ủy quyền dùng để truy xuất thêm thông tin từ UserInfo Endpoint nếu cần.
  1. Hoàn tất đăng nhập: Grafana kiểm tra chữ ký số của id_token bằng khóa công khai (JWKS) của Authentik, giải mã các thông tin thuộc tính (claims), tự động gán vai trò tương ứng (Admin, Editor hoặc Viewer) dựa trên nhóm của người dùng và thiết lập phiên làm việc cục bộ.
Luồng xác thực OpenID Connect Authorization Code Flow

Chuẩn bị hạ tầng và triển khai Authentik qua Docker Compose

Một cụm dịch vụ Authentik tiêu chuẩn bao gồm bốn thành phần chính:

  • authentik-server: Xử lý giao diện web, các API xác thực, điều hướng luồng và cấp phát token.
  • authentik-worker: Tiến trình chạy nền xử lý các tác vụ bất đồng bộ như gửi thư điện tử, dọn dẹp các phiên làm việc hết hạn và kiểm tra tình trạng dịch vụ.
  • postgresql: Cơ sở dữ liệu quan hệ lưu trữ thông tin tài khoản, nhóm, chính sách phân quyền và nhật ký kiểm toán (audit log).
  • redis: Đóng vai trò làm bộ nhớ đệm tốc độ cao và hàng đợi thông điệp liên lạc giữa server và worker.
Kiến trúc cụm dịch vụ Authentik trên hạ tầng Docker Compose

Bước 1: Tạo cấu trúc thư mục và sinh khóa bí mật

Đăng nhập SSH vào máy chủ VPS quản trị định danh và tạo thư mục làm việc:

bash
sudo mkdir -p /opt/authentik/{media,templates,certs}
cd /opt/authentik

Tạo tệp biến môi trường .env. Tất cả các chuỗi bí mật phải được sinh ngẫu nhiên bằng lệnh mã hóa:

bash
# Sinh chuỗi bí mật cho Authentik core
SECRET_KEY=$(openssl rand -base64 36)

# Sinh mật khẩu mạnh cho PostgreSQL
PG_PASS=$(openssl rand -base64 24)

cat <<EOF > .env
AUTHENTIK_SECRET_KEY=${SECRET_KEY}
AUTHENTIK_ERROR_REPORTING__ENABLED=false
AUTHENTIK_DISABLE_UPDATE_CHECK=true

PG_PASS=${PG_PASS}
AUTHENTIK_POSTGRESQL__USER=authentik
AUTHENTIK_POSTGRESQL__NAME=authentik
AUTHENTIK_POSTGRESQL__HOST=postgresql
AUTHENTIK_POSTGRESQL__PASSWORD=${PG_PASS}

AUTHENTIK_REDIS__HOST=redis
AUTHENTIK_PORT_HTTP=9000
AUTHENTIK_PORT_HTTPS=9443
EOF

chmod 600 .env

Bước 2: Biên soạn tệp docker-compose.yml chuẩn hóa

Tạo tệp docker-compose.yml với các dịch vụ cốt lõi, mạng nội bộ cô lập và kiểm tra trạng thái sức khỏe (healthcheck) rõ ràng:

yaml
version: '3.8'

services:
  postgresql:
    image: docker.io/library/postgres:16-alpine
    restart: unless-stopped
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -d $${POSTGRES_DB} -U $${POSTGRES_USER}"]
      interval: 10s
      timeout: 5s
      retries: 5
    environment:
      POSTGRES_PASSWORD: ${PG_PASS}
      POSTGRES_USER: ${AUTHENTIK_POSTGRESQL__USER}
      POSTGRES_DB: ${AUTHENTIK_POSTGRESQL__NAME}
    volumes:
      - postgres_data:/var/lib/postgresql/data
    networks:
      - authentik_backend

  redis:
    image: docker.io/library/redis:7-alpine
    command: --save 60 1 --loglevel warning
    restart: unless-stopped
    healthcheck:
      test: ["CMD-SHELL", "redis-cli ping | grep PONG"]
      interval: 10s
      timeout: 5s
      retries: 5
    volumes:
      - redis_data:/data
    networks:
      - authentik_backend

  server:
    image: ghcr.io/goauthentik/server:2024.8.3
    restart: unless-stopped
    command: server
    environment:
      AUTHENTIK_REDIS__HOST: redis
      AUTHENTIK_POSTGRESQL__HOST: postgresql
      AUTHENTIK_POSTGRESQL__USER: ${AUTHENTIK_POSTGRESQL__USER}
      AUTHENTIK_POSTGRESQL__NAME: ${AUTHENTIK_POSTGRESQL__NAME}
      AUTHENTIK_POSTGRESQL__PASSWORD: ${PG_PASS}
      AUTHENTIK_SECRET_KEY: ${AUTHENTIK_SECRET_KEY}
      AUTHENTIK_ERROR_REPORTING__ENABLED: "false"
      AUTHENTIK_DISABLE_UPDATE_CHECK: "true"
    volumes:
      - ./media:/media
      - ./templates:/templates
    ports:
      - "127.0.0.1:${AUTHENTIK_PORT_HTTP}:9000"
    depends_on:
      postgresql:
        condition: service_healthy
      redis:
        condition: service_healthy
    networks:
      - authentik_backend
      - proxy_net

  worker:
    image: ghcr.io/goauthentik/server:2024.8.3
    restart: unless-stopped
    command: worker
    environment:
      AUTHENTIK_REDIS__HOST: redis
      AUTHENTIK_POSTGRESQL__HOST: postgresql
      AUTHENTIK_POSTGRESQL__USER: ${AUTHENTIK_POSTGRESQL__USER}
      AUTHENTIK_POSTGRESQL__NAME: ${AUTHENTIK_POSTGRESQL__NAME}
      AUTHENTIK_POSTGRESQL__PASSWORD: ${PG_PASS}
      AUTHENTIK_SECRET_KEY: ${AUTHENTIK_SECRET_KEY}
      AUTHENTIK_ERROR_REPORTING__ENABLED: "false"
      AUTHENTIK_DISABLE_UPDATE_CHECK: "true"
    user: root
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - ./media:/media
      - ./certs:/certs
      - ./templates:/templates
    depends_on:
      postgresql:
        condition: service_healthy
      redis:
        condition: service_healthy
    networks:
      - authentik_backend

volumes:
  postgres_data:
    driver: local
  redis_data:
    driver: local

networks:
  authentik_backend:
    internal: true
  proxy_net:
    external: true

Lưu ý rằng cổng dịch vụ được gắn vào 127.0.0.1:9000 thay vì 0.0.0.0:9000. Điều này giúp đảm bảo Authentik không bị truy cập trực tiếp từ Internet mà được định tuyến qua Reverse Proxy Nginx có mã hóa HTTPS.

Khởi chạy cụm dịch vụ:

bash
docker compose up -d

Kiểm tra trạng thái khởi động bằng lệnh:

bash
docker compose ps
docker compose logs -f server

Khi thấy dòng nhật ký Starting authentik... và các chỉ số healthcheck chuyển sang trạng thái healthy, hệ thống đã sẵn sàng đón nhận kết nối.

Bước 3: Cấu hình Reverse Proxy Nginx

Authentik cần nhận biết chính xác URL gốc và giao thức truy cập của người dùng để sinh ra các đường dẫn callback OIDC hợp lệ. Bạn thiết lập một Virtual Host Nginx như sau:

nginx
server {
    listen 80;
    server_name sso.internal.example.com;
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl http2;
    server_name sso.internal.example.com;

    ssl_certificate /etc/letsencrypt/live/sso.internal.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/sso.internal.example.com/privkey.pem;

    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers HIGH:!aNULL:!MD5;

    client_max_body_size 20M;

    location / {
        proxy_pass http://127.0.0.1:9000;
        proxy_http_version 1.1;

        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";

        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Forwarded-Host $host;
        proxy_set_header X-Forwarded-Port $server_port;

        proxy_connect_timeout 60s;
        proxy_send_timeout 60s;
        proxy_read_timeout 60s;
    }
}

Kiểm tra cú pháp và tải lại cấu hình Nginx:

bash
sudo nginx -t && sudo systemctl reload nginx

Bước 4: Khởi tạo tài khoản quản trị viên

Mở trình duyệt và truy cập vào đường dẫn thiết lập ban đầu: https://sso.internal.example.com/if/flow/initial-setup/

Tại đây, bạn thiết lập mật khẩu cho tài khoản quản trị tối cao (akadmin). Đây là tài khoản dùng để xây dựng các chính sách, tạo nhóm người dùng và khai báo ứng dụng ban đầu.

Kết nối Nguồn định danh gốc (Federated Identity Sources)

Sau khi đăng nhập vào Authentik Admin Interface, bạn có hai phương án tổ chức danh bạ người dùng:

Phương án 1: Sử dụng Authentik làm kho định danh nội bộ độc lập

Bạn tạo trực tiếp các người dùng tại mục Directory -> Users và phân chia họ vào các nhóm (Groups) như:

  • infra-admins: Quản trị viên hạ tầng và DevOps.
  • developers: Lập trình viên phụ trách phát triển ứng dụng.
  • qa-engineers: Đội ngũ kiểm thử chất lượng phần mềm.

Authentik cung cấp sẵn quy trình tự phục hồi mật khẩu (Password Reset Flow) và kích hoạt MFA qua mã QR TOTP hoặc Touch ID/FIDO2.

Phương án 2: Kết nối Federated với Google Workspace hoặc Microsoft Entra ID

Nếu doanh nghiệp của bạn đã sử dụng Google Workspace hoặc Microsoft 365, phương án tối ưu là sử dụng Authentik làm Identity Broker (cầu nối định danh). Khi đó, Authentik sẽ chuyển hướng bước đăng nhập về Google hoặc Microsoft:

  • Vào mục Directory -> Federation & Social Logins -> Create Google OAuth Source.
  • Cung cấp Google Client ID và Client Secret thu được từ Google Cloud Console.
  • Bật tính năng User Matching: Khi kỹ sư đăng nhập bằng email @company.com, Authentik sẽ tự động liên kết danh tính và đưa người dùng vào các nhóm nội bộ đã định nghĩa sẵn.

Cách làm này mang lại lợi ích kép: người dùng không cần nhớ thêm một mật khẩu mới, và khi bạn khóa email công ty của nhân sự trên Google Workspace, quyền truy cập vào Authentik và các công cụ kỹ thuật sẽ lập tức bị ngắt.

Tích hợp OIDC thực tế vào các ứng dụng nội bộ

Sau khi đã có kho định danh tập trung, bạn tiến hành cấu hình OIDC Provider trên Authentik và kết nối với từng công cụ cụ thể.

Tích hợp 1: Giám sát hạ tầng với Grafana

Grafana là công cụ quan sát hạ tầng có hỗ trợ giao thức Generic OAuth rất mạnh mẽ. Mục tiêu của chúng ta là khi kỹ sư đăng nhập qua Authentik, Grafana sẽ tự động cấp quyền:

  • Thành viên nhóm infra-admins trên Authentik sẽ nhận quyền Admin trên Grafana.
  • Thành viên nhóm developers sẽ nhận quyền Editor.
  • Những người dùng còn lại chỉ nhận quyền Viewer.

Bước 1.1: Tạo Provider và Application trên Authentik

  1. Đăng nhập vào trang quản trị Authentik, điều hướng tới Applications -> Providers.
  2. Chọn Create, chọn loại OAuth2/OpenID Provider:
  • Name: Grafana SSO Provider
  • Authentication flow: Chọn default-authentication-flow
  • Authorization flow: Chọn default-provider-authorization-explicit-consent (hoặc luồng implicit để bỏ qua bước xác nhận cấp quyền)
  • Client type: Confidential
  • Client ID: Điền chuỗi định danh, ví dụ grafana-internal-client
  • Client Secret: Điền một chuỗi bí mật dài ngẫu nhiên (lưu lại chuỗi này để cấu hình Grafana)
  • Redirect URIs: Điền chính xác URL callback của Grafana:

https://grafana.internal.example.com/login/generic_oauth

  • Signing Key: Chọn chứng chỉ tự ký mặc định của Authentik
  • Scopes: Đảm bảo đã chọn openid, email, profile và authentik default OAuth Mapping: OpenID 'groups'
  1. Nhấn Finish.
  2. Tiếp theo, vào Applications -> Applications, chọn Create:
  • Name: Grafana Monitoring
  • Slug: grafana-monitoring
  • Provider: Chọn Grafana SSO Provider vừa tạo
  • Launch URL: https://grafana.internal.example.com

Bước 1.2: Cấu hình Grafana để kích hoạt SSO

Mở tệp cấu hình grafana.ini (hoặc khai báo qua biến môi trường Docker trong tệp docker-compose.yml của Grafana):

ini
[auth.generic_oauth]
enabled = true
name = Authentik SSO
allow_sign_up = true
auto_login = false

client_id = grafana-internal-client
client_secret = [chuỗi_client_secret_đã_lưu_ở_trên]
scopes = openid profile email groups
empty_scopes = false

auth_url = https://sso.internal.example.com/application/o/authorize/
token_url = https://sso.internal.example.com/application/o/token/
api_url = https://sso.internal.example.com/application/o/userinfo/

# Ánh xạ thuộc tính nhóm sang vai trò Grafana
role_attribute_path = contains(groups[*], 'infra-admins') && 'Admin' || contains(groups[*], 'developers') && 'Editor' || 'Viewer'
role_attribute_strict = true
allow_assign_grafana_admin = true

Khởi động lại Grafana để áp dụng thay đổi:

bash
docker compose restart grafana

Truy cập giao diện Grafana, bạn sẽ thấy xuất hiện nút "Sign in with Authentik SSO". Nhấn vào nút này, trình duyệt sẽ chuyển hướng sang Authentik để xác thực và quay trở về Grafana với vai trò được tự động phân bổ chính xác theo nhóm.

Tích hợp 2: Quản trị Docker với Portainer CE

Portainer Community Edition (CE) từ các phiên bản 2.x trở lên đã hỗ trợ tính năng đăng nhập OAuth/OIDC tiêu chuẩn.

Bước 2.1: Khai báo Provider trên Authentik

  1. Vào Applications -> Providers -> Create và chọn OAuth2/OpenID Provider:
  • Name: Portainer OIDC Provider
  • Client type: Confidential
  • Client ID: portainer-internal-client
  • Client Secret: [Sinh chuỗi ngẫu nhiên 32 ký tự]
  • Redirect URIs: Portainer sử dụng trang chủ làm điểm tiếp nhận callback:

https://portainer.internal.example.com/

  • Scopes: openid, profile, email
  1. Nhấn Finish, sau đó tạo Application tương ứng có tên Portainer Ops gắn với Provider này.

Bước 2.2: Cấu hình OAuth trong giao diện Portainer

  1. Đăng nhập vào Portainer bằng tài khoản quản trị cục bộ ban đầu.
  2. Điều hướng tới Settings -> Authentication.
  3. Chọn tùy chọn OAuth:
  • Bật tính năng Use SSO.
  • Client ID: portainer-internal-client
  • Client secret: [Chuỗi Client Secret đã tạo ở Authentik]
  • Authorization URL: https://sso.internal.example.com/application/o/authorize/
  • Access token URL: https://sso.internal.example.com/application/o/token/
  • Resource URL: https://sso.internal.example.com/application/o/userinfo/
  • Redirect URL: https://portainer.internal.example.com/
  • User identifier: preferred_username (hoặc email)
  • Scopes: openid profile email
  1. Tại mục Automatic user provisioning, gạt công tắc sang Enabled. Tính năng này giúp Portainer tự động tạo tài khoản nội bộ ngay trong lần đầu tiên kỹ sư đăng nhập thành công qua Authentik mà quản trị viên không cần tạo thủ công trước.
  2. Nhấn Save settings. Đăng xuất và thử nghiệm đăng nhập lại bằng nút SSO.

Quản trị phân quyền nâng cao và kiểm soát phiên làm việc

Việc triển khai IdP không dừng lại ở mức đăng nhập thuận tiện, mà giá trị cốt lõi nằm ở khả năng kiểm soát tập trung:

1. Bắt buộc kích hoạt xác thực hai bước (MFA Enforcement)

Thay vì phải kiểm tra xem từng kỹ sư đã bật 2FA trên từng ứng dụng hay chưa, bạn có thể thiết lập quy tắc bắt buộc ngay tại Authentik:

  • Vào mục Flows and Stages -> Flows.
  • Chỉnh sửa default-authentication-flow.
  • Thêm một Stage loại Authenticator Validation và đặt điều kiện: Nếu người dùng chưa liên kết thiết bị MFA (TOTP app hoặc FIDO2 key), hệ thống sẽ bắt buộc chuyển hướng người dùng tới trang khởi tạo mã xác thực trước khi cho phép tiếp tục truy cập bất kỳ ứng dụng nào.

2. Thiết lập thời gian sống của Token và Phiên làm việc

Trong cấu hình của từng OAuth2 Provider trên Authentik, bạn có thể tinh chỉnh các tham số thời gian:

  • Access Token Validity: Nên đặt từ 15 phút đến 30 phút. Access Token là chìa khóa gửi kèm trong các request; việc đặt thời hạn ngắn giúp giảm thiểu rủi ro nếu token bị lộ trong bộ nhớ tạm của trình duyệt.
  • Refresh Token Validity: Đặt từ 12 giờ đến 24 giờ. Đây là khoảng thời gian cho phép ứng dụng âm thầm xin cấp Access Token mới mà không bắt kỹ sư phải gõ lại mật khẩu giữa ngày làm việc.

Khi bạn vô hiệu hóa một tài khoản trên Authentik, phiên làm việc tại Authentik sẽ bị thu hồi ngay lập tức. Sau tối đa 15-30 phút (khi Access Token hiện tại của ứng dụng hết hạn), ứng dụng sẽ gửi Refresh Token lên Authentik để gia hạn nhưng bị từ chối, từ đó buộc người dùng phải đăng xuất hoàn toàn khỏi toàn bộ các công cụ nội bộ.

Kịch bản ứng phó rủi ro và Kế hoạch cứu hộ (Break-Glass Plan)

Bất kỳ hệ thống tập trung nào cũng đi kèm với rủi ro trở thành điểm lỗi đơn lẻ (Single Point of Failure - SPOF). Nếu máy chủ Authentik gặp sự cố, cơ sở dữ liệu PostgreSQL bị nghẽn đĩa hoặc chứng chỉ SSL của tên miền SSO hết hạn, toàn bộ đội ngũ có thể bị khóa khỏi các công cụ giám sát và vận hành quan trọng nhất.

Để loại bỏ rủi ro này, bạn cần thiết lập quy trình cứu hộ khẩn cấp ngay từ giai đoạn triển khai:

1. Duy trì tài khoản quản trị cục bộ (Break-glass Account)

  • Trên mỗi ứng dụng như Grafana và Portainer, luôn duy trì tối thiểu một tài khoản quản trị viên nội bộ (Local Admin) không phụ thuộc vào SSO.
  • Trong cấu hình Grafana, luôn đặt auto_login = false. Điều này đảm bảo khi trang đăng nhập mở ra, ngoài nút SSO, người dùng vẫn có thể bấm vào đường dẫn đăng nhập bằng tài khoản cục bộ dự phòng.
  • Mật khẩu của tài khoản cứu hộ này phải được sinh ngẫu nhiên từ 30 ký tự trở lên, lưu trữ trong két quản lý mật khẩu của cấp quản lý hoặc niêm phong trong phong bì vật lý an toàn, chỉ được mở khi xảy ra sự cố gián đoạn hệ thống định danh.

2. Chiến lược sao lưu dữ liệu Authentik

Dữ liệu của Authentik rất nhẹ nhưng đóng vai trò sống còn. Bạn cần thiết lập sao lưu định kỳ cho cơ sở dữ liệu PostgreSQL:

bash
# Lệnh trích xuất bản sao lưu PostgreSQL
docker compose exec -T postgresql pg_dump -U authentik authentik | gzip > /opt/backups/authentik_$(date +%Y%m%d_%H%M%S).sql.gz

Kết hợp với việc sao lưu tệp .env và thư mục media/templates, bạn có thể khôi phục toàn bộ hệ thống định danh lên một máy chủ VPS mới chỉ trong vòng dưới 10 phút.

3. Quy trình thu hồi quyền khẩn cấp (Emergency Session Revocation)

Khi phát hiện một thiết bị của kỹ sư bị thất lạc hoặc có dấu hiệu lộ thông tin đăng nhập:

  1. Quản trị viên đăng nhập vào Authentik Admin Interface.
  2. Điều hướng tới Directory -> Users, chọn tài khoản liên quan.
  3. Chuyển trạng thái tài khoản sang Disabled.
  4. Chuyển sang tab Sessions của người dùng đó và nhấn Revoke all sessions. Thao tác này sẽ hủy bỏ ngay lập tức toàn bộ mã phiên trong Redis, làm vô hiệu hóa tất cả Refresh Token đang lưu hành của tài khoản đó trên mọi hệ sinh thái nội bộ.

Việc thiết lập thành công Authentik giúp doanh nghiệp xây dựng được một hàng rào bảo vệ vững chắc ở tầng ứng dụng, chuẩn hóa trải nghiệm làm việc cho đội ngũ kỹ thuật và sẵn sàng đáp ứng các tiêu chuẩn kiểm toán an toàn thông tin khắt khe. Trong bước tiếp theo của lộ trình bảo mật hạ tầng phát triển, bạn nên kết hợp hệ thống định danh này với giải pháp quản lý Secret và biến môi trường tập trung bằng Infisical để loại bỏ hoàn toàn các tệp cấu hình chứa mật khẩu trôi nổi trên máy tính cá nhân của lập trình viên.

Nội dung hướng dẫn này có hữu ích với hệ thống của bạn không?

Chia sẻ bài viết hữu ích

Gửi bài viết này cho đồng nghiệp

Đọc tiếp

Bài nên đọc tiếp

Xem tất cả bài về Docker & Application