Quản lý Kafka Users và ACLs theo phong cách GitOps - Không lưu secret trong repo

TL;DR

Quản lý Kafka users và ACLs bằng tay dễ gây lỗi, không có audit trail, và rất khó scale. GitOps giải quyết vấn đề này bằng cách đưa toàn bộ cấu hình vào Git - mọi thay đổi đều qua pull request, được review, và tự động apply qua CI/CD pipeline. Oracle vừa công bố hướng dẫn chi tiết cách thực hiện trên OCI Streaming với Apache Kafka và GitLab CI, không lưu secret trong repository.

GitLab CI pipeline chạy job fn-sync-kafka-acl - kết quả JSON cho thấy 6 ACL được tạo thành công trong 41 giây

Vấn đề với cách truyền thống

Mô hình quản lý ACL Kafka phổ biến hiện nay: chạy lệnh kafka-acls trực tiếp trên cluster, dùng script bash rải rác, hoặc phụ thuộc vào "người biết lệnh". Cách này có ba vấn đề lớn:

Không có audit trail: Không biết ai thêm ACL nào, khi nào, tại sao.
Permission creep: Quyền được thêm dần dần, không ai dám xóa vì sợ break production.
Không thể replicate: Môi trường dev/staging/prod ACL lệch nhau, gây bug khó debug.

Khi tổ chức scale lên hàng chục team và hàng trăm topic, mô hình này sụp đổ hoàn toàn. Một số tổ chức báo cáo quản lý hơn 78 Kafka cluster - không thể làm thủ công.

GitOps hoạt động thế nào

GitOps đưa Git trở thành source of truth duy nhất. Thay vì chạy lệnh trực tiếp, bạn khai báo trạng thái mong muốn trong file YAML, commit vào Git, và để CI/CD tự apply.

Quy trình ba bước:

Desired State: File YAML mô tả toàn bộ topics, users, và ACLs mong muốn.
Plan: Tool so sánh desired state với actual state trên cluster, tạo plan (diff) như Terraform.
Apply: CI/CD apply plan lên cluster sau khi được review và approve qua PR.

Mọi thay đổi đều là Git commit - ai thêm gì, khi nào, tại sao đều có record. Rollback chỉ cần git revert.

Kỹ thuật đằng sau

Tool phổ biến nhất cho pattern này là kafka-gitops. Cú pháp desired-state file rất đơn giản:

topics:
  app-orders:
    partitions: 6
    replication: 3

services:
  orders-producer:
    type: application
    principal: User:orders-producer
    produces:
      - app-orders

  orders-consumer:
    type: application
    principal: User:orders-consumer
    consumes:
      - app-orders

Điểm mạnh: khai báo quan hệ produces/consumes là đủ - tool tự sinh ACL phù hợp (Write cho producer, Read cho consumer). Không cần viết từng ACL rule thủ công, không cần hiểu sâu về Kafka ACL internals.

Lệnh chạy trong CI:

# Chạy khi mở PR - post kết quả vào PR comment để review
kafka-gitops -f state.yaml plan -o plan.json

# Chạy khi merge vào main branch
kafka-gitops -f state.yaml apply -p plan.json

Cấu hình kết nối cluster qua env vars, không hardcode vào file: KAFKA_BOOTSTRAP_SERVERS, KAFKA_SASL_JAAS_USERNAME, KAFKA_SASL_JAAS_PASSWORD. Đây là lý do secret không cần lưu trong repository.

Về bảo mật, OCI Streaming dùng AclAuthorizer chuẩn của Kafka. Quan trọng: đổi config allow.everyone.if.no.acl.found=false (mặc định là true) để enforce deny-by-default - ai không có ACL sẽ bị từ chối.

Chiều	Truyền thống	GitOps
Source of truth	Cluster state	Git repository
Audit trail	Không có	Đầy đủ Git history
Review process	Ad-hoc	Mandatory PR gate
Drift detection	Không có	Continuous reconciliation
Rollback	Thủ công, dễ sai	git revert + apply
ACL generation	Viết từng rule thủ công	Auto-generate từ quan hệ

Ai nên dùng ngay

Platform/SRE team đang chạy nhiều Kafka cluster - GitOps scale tốt hơn bất kỳ approach thủ công nào.
Security team cần audit trail rõ ràng - mỗi ACL có commit, reviewer, timestamp đầy đủ.
Developer muốn tự phục vụ - thay vì mở ticket chờ ops team, tự tạo PR thêm topic/service, đợi review là xong.
Ngành regulated (finance, healthcare) - compliance cần bằng chứng ai có quyền gì, khi nào - Git history là câu trả lời chính xác nhất.
Team đang migrate từ on-prem lên AWS MSK hoặc OCI Streaming - export state, apply lên cluster mới, ACLs replicate chính xác.

Hạn chế cần biết

Không tự bootstrap state file từ cluster đang chạy - phải viết tay lần đầu (tốn thời gian với cluster lớn).
Consumer group ID customization còn hạn chế trong kafka-gitops.
Không có built-in ACL expiration - phải tự implement logic cleanup cho time-bound access.
Multi-cluster federation phức tạp cần thêm Crossplane + ArgoCD.

Bắt đầu với GitLab CI

Oracle đã demo toàn bộ pattern này trên OCI Streaming. Ảnh ở đầu bài là output thực tế từ pipeline chạy thành công: 6 ACL được tạo, users được sync qua SCRAM-SHA-512, pipeline hoàn thành trong 41 giây. Đây là các bước cơ bản để bắt đầu:

Cài kafka-gitops, tạo state.yaml mô tả cluster hiện tại (topics + services).
Thêm CI job: plan khi mở PR (post kết quả vào PR comment), apply khi merge vào main.
Đưa Kafka credentials vào CI secrets - không bao giờ commit vào repo.
Set allow.everyone.if.no.acl.found=false trên cluster để enforce deny-by-default.
Áp dụng quy tắc: mọi thay đổi ACL phải qua PR, cấm chạy kafka-acls thủ công trực tiếp.

Nguồn: Oracle Developers Blog, kafka-gitops trên GitHub, Collectors Tech Blog.