Lab 15 — 🔐 ArgoCD Security & RBAC
🎯 1. Mục tiêu
Sau Lab này, bạn sẽ:
- 🔐 Hiểu tại sao ArgoCD cần Authentication và Authorization.
- 👤 Tạo user và phân quyền bằng RBAC.
- 🛡️ Hiểu cách giới hạn quyền theo Application / Project.
- 🧪 Kiểm tra user nào được phép làm gì.
- 🚨 Nhận biết những lỗi RBAC thường gặp trong môi trường Production.
🤔 2. Vấn đề thực tế
Hãy tưởng tượng team DevOps có 3 người:
ArgoCD
│
┌─────────────┼─────────────┐
│ │ │
Dev QA DevOps
│ │ │
Read Sync Admin
Nếu tất cả mọi người đều dùng:
admin
thì có một vấn đề rất nguy hiểm:
Developer có thể vô tình xóa hoặc thay đổi Production Application.
Ví dụ:
Developer
│
│ argocd app delete production-api
▼
ArgoCD
│
▼
💥 Production bị ảnh hưởng
Trong Production, chúng ta không muốn:
"Ai đăng nhập được ArgoCD thì làm được mọi thứ."
Thay vào đó:
Developer → Read
QA → Sync
DevOps → Full Access
Đây chính là lúc RBAC xuất hiện.
RBAC = Role-Based Access Control.
Thay vì cấp quyền trực tiếp cho từng người, chúng ta tạo Role rồi gán người dùng vào Role đó.
ArgoCD thực hiện authorization bằng cách kiểm tra user/group và đối chiếu với các RBAC policy.
🧠 3. Hiểu nhanh
🔑 3.1 Authentication vs Authorization
Đây là hai khái niệm rất dễ nhầm.
Authentication — "Bạn là ai?"
Ví dụ:
username: developer
password: ******
ArgoCD xác định:
→ Đây là user developer
Authorization — "Bạn được làm gì?"
Sau khi biết user là developer, ArgoCD kiểm tra:
developer
│
▼
Role: developer
│
├── applications: get ✅
├── applications: sync ❌
└── applications: delete ❌
Có thể nhớ đơn giản:
Authentication
↓
"Bạn là ai?"
↓
Authorization
↓
"Bạn được làm gì?"
👥 3.2 Role là gì?
Role là một tập hợp quyền.
Ví dụ:
role:developer
├── xem Application
├── xem Status
└── xem Logs
Trong khi:
role:devops
├── xem Application
├── Sync
├── Update
└── Delete
Điểm quan trọng:
Không cấp quyền trực tiếp một cách tùy tiện cho từng user. Hãy gom quyền thành Role.
🛡️ 3.3 ArgoCD RBAC hoạt động như thế nào?
Một policy có dạng khái quát:
p, <role>, <resource>, <action>, <object>, <effect>
Ví dụ:
p, role:developer, applications, get, todo-app/*, allow
Có thể đọc thành:
role developer
│
│ được
▼
applications
│
│ action = get
▼
todo-app/*
│
▼
allow
Nói đơn giản:
Developer được xem các Application thuộc project
todo-app.
ArgoCD sử dụng argocd-rbac-cm để cấu hình RBAC global; ngoài ra AppProject Roles cho phép giới hạn quyền theo từng project.
🏗️ 4. Architecture
Trong Lab này, chúng ta xây dựng mô hình:
┌───────────────┐
│ ArgoCD │
│ │
│ Authentication│
│ + │
│ RBAC │
└───────┬───────┘
│
┌──────────────┼──────────────┐
│ │ │
▼ ▼ ▼
Developer QA DevOps
│ │ │
Read-only Sync Admin
│ │ │
└─────────────────┼──────────────┘
│
▼
┌─────────────┐
│ Application │
│ │
│ todo-dev │
│ todo-prod │
└─────────────┘
Mục tiêu:
Developer
│
├── xem Dev ✅
├── xem Prod ✅
├── Sync Dev ❌
└── Delete Prod ❌
DevOps
│
├── xem Dev ✅
├── Sync Dev ✅
├── Sync Prod ✅
└── Delete Prod ✅
🧪 5. Chuẩn bị Lab
📦 5.1 Kiểm tra ArgoCD
Đảm bảo ArgoCD đang chạy:
kubectl get pods -n argocd
Kết quả mong đợi:
NAME READY STATUS
argocd-server-xxxxx 1/1 Running
argocd-repo-server-xxxxx 1/1 Running
argocd-application-controller-xxxxx 1/1 Running
Kiểm tra CLI:
argocd version
🔐 5.2 Login ArgoCD
Nếu đang dùng Minikube, có thể port-forward:
kubectl port-forward svc/argocd-server \
-n argocd 8080:443
Sau đó:
argocd login localhost:8080 \
--username admin \
--password <ADMIN_PASSWORD> \
--insecure
Trong Production, không nên sử dụng
--insecure. Lab dùng nó vì ArgoCD đang chạy local.
👤 6. Tạo User Developer
🤔 Tại sao cần user riêng?
Hiện tại chúng ta đang dùng:
admin
Nhưng admin có quyền rất lớn.
Production nên có:
admin
├── DevOps
├── Developer
└── QA
Mỗi người chỉ nhận quyền cần thiết.
🛠️ 6.1 Enable local account
Chúng ta sửa ConfigMap:
kubectl edit configmap argocd-cm -n argocd
Thêm:
data:
accounts.developer: login
ArgoCD hỗ trợ tạo local account bằng các key accounts.<username> trong argocd-cm.
Kiểm tra:
kubectl get configmap argocd-cm -n argocd -o yaml
Bạn sẽ thấy:
accounts.developer: login
🔑 7. Thiết lập Password
Đăng nhập bằng admin:
argocd login localhost:8080 \
--username admin \
--password <ADMIN_PASSWORD> \
--insecure
Sau đó thiết lập password cho user:
argocd account update-password \
--account developer
CLI sẽ yêu cầu password theo từng bước.
Sau khi hoàn tất, kiểm tra:
argocd account list
Bạn sẽ thấy user:
NAME ENABLED
admin true
developer true
🛡️ 8. Tạo RBAC Policy
🤔 Tại sao chưa đủ khi đã tạo user?
Có user không có nghĩa là user đó được quyền làm mọi thứ.
Chúng ta cần nói với ArgoCD:
developer
↓
được phép làm gì?
📝 8.1 Cấu hình argocd-rbac-cm
Mở:
kubectl edit configmap argocd-rbac-cm -n argocd
Thêm:
data:
policy.csv: |
p, role:developer, applications, get, todo-app/*, allow
p, role:developer, logs, get, todo-app/*, allow
g, developer, role:developer
policy.default: role:readonly
Giải thích:
p
│
├── role:developer
├── applications
├── get
├── todo-app/*
└── allow
Nghĩa là:
Role
developerđược phép xem Application trong projecttodo-app.
Dòng:
g, developer, role:developer
có nghĩa:
developer
↓
role:developer
👀 9. Kiểm tra quyền Developer
Đăng nhập bằng developer:
argocd login localhost:8080 \
--username developer \
--password <DEVELOPER_PASSWORD> \
--insecure
Kiểm tra Application:
argocd app list
Developer có thể xem Application.
Thử:
argocd app get todo-app
Kết quả:
Name: todo-app
Project: todo-app
Sync Status: Synced
Health Status: Healthy
🚫 10. Thử một hành động bị cấm
Đây mới là phần quan trọng nhất của Lab.
Developer thử:
argocd app sync todo-app
Kỳ vọng:
PermissionDenied
Tương tự:
argocd app delete todo-app
cũng phải bị từ chối.
Mô hình lúc này:
Developer
│
┌──────────┴──────────┐
│ │
GET App SYNC App
│ │
▼ ▼
✅ ❌
🔬 11. Kiểm tra RBAC trực tiếp
Thay vì thử từng command bằng tay, ArgoCD cung cấp command để kiểm tra RBAC.
Ví dụ:
argocd admin settings rbac can \
developer \
get \
applications \
todo-app/my-app \
--namespace argocd
Command này giúp trả lời câu hỏi:
"User này có được phép thực hiện action này trên resource này không?"
ArgoCD có command argocd admin settings rbac can để kiểm tra quyền của role/subject.
Đây là một trick rất hữu ích khi debug RBAC.
👨💻 12. Tạo Role DevOps
Developer chỉ có quyền đọc.
DevOps thì cần nhiều quyền hơn.
Sửa:
kubectl edit configmap argocd-rbac-cm -n argocd
Thêm:
data:
policy.csv: |
# Developer
p, role:developer, applications, get, todo-app/*, allow
p, role:developer, logs, get, todo-app/*, allow
# DevOps
p, role:devops, applications, *, todo-app/*, allow
p, role:devops, logs, get, todo-app/*, allow
# User -> Role
g, developer, role:developer
g, devops, role:devops
policy.default: role:readonly
Bây giờ:
Developer
│
└── role:developer
│
├── get
└── logs
DevOps
│
└── role:devops
│
├── get
├── sync
├── update
└── delete
🏢 13. RBAC theo Project
Trong Production, việc giới hạn quyền theo Application là chưa phải cách duy nhất.
Một cách tốt hơn là tổ chức Application thành các AppProject:
ArgoCD
│
├── project: development
│ ├── frontend-dev
│ └── backend-dev
│
├── project: staging
│ ├── frontend-staging
│ └── backend-staging
│
└── project: production
├── frontend-prod
└── backend-prod
Sau đó:
Developer
│
└── development
QA
│
└── staging
DevOps
│
├── development
├── staging
└── production
Đây là mô hình gần với Production hơn:
Không chỉ hỏi "user được làm gì?" mà còn hỏi "user được làm trên project nào?"
ArgoCD hỗ trợ Project Roles, cho phép tạo role ngay trong một AppProject và giới hạn policy vào project đó.
🧪 14. Thực hành Project Role
Tạo file:
mkdir -p argocd/security
cd argocd/security
Tạo:
apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
name: development
namespace: argocd
spec:
description: Development project
sourceRepos:
- "*"
destinations:
- namespace: todo-app
server: https://kubernetes.default.svc
roles:
- name: developer
description: Developer read-only role
policies:
- p, proj:development:developer, applications, get, development/*, allow
groups:
- developers
Apply:
kubectl apply -f development-project.yaml
Kiểm tra:
kubectl get appproject -n argocd
Kết quả:
NAME AGE
development 10s
default 10d
🧠 15. Hiểu sự khác nhau
Có hai nơi bạn sẽ thường gặp RBAC.
Global RBAC
argocd-rbac-cm
Phù hợp khi:
Admin
DevOps
Developer
QA
cần các quyền dùng chung trên toàn ArgoCD.
Project RBAC
AppProject
Phù hợp khi:
Team A → Project A
Team B → Project B
Ví dụ:
ArgoCD
│
┌─────────┴─────────┐
│ │
Development Production
│ │
Developers DevOps
│ │
Read Full
Trong môi trường lớn, Project Role thường giúp boundary rõ ràng hơn.
🚨 16. Một lỗi Security rất nguy hiểm
Hãy cẩn thận với policy kiểu:
p, role:developer, applications, *, */*, allow
Nó gần như có nghĩa:
Developer
│
├── get
├── create
├── update
├── delete
└── ...
trên rất nhiều Application.
Đây đi ngược lại nguyên tắc:
Least Privilege — chỉ cấp đúng quyền cần thiết.
Thay vì:
applications, *
hãy bắt đầu bằng:
applications, get
và chỉ mở rộng khi thực sự cần.
⚠️ 17. Cẩn thận với exec
ArgoCD có resource RBAC dành cho exec.
Điều này rất quan trọng vì:
exec
↓
Pod shell
↓
Có thể thực hiện command trong container
Vì vậy không nên vô tình cấp:
*, *
cho role không đáng tin cậy.
ArgoCD cũng lưu ý rằng các policy wildcard có thể vô tình bao phủ thêm quyền mới khi phiên bản ArgoCD bổ sung resource/action mới; đây là lý do nên khai báo quyền cụ thể thay vì dùng wildcard quá rộng.
🔐 18. RBAC không phải Kubernetes RBAC
Đây là điểm rất quan trọng.
Bạn sẽ có hai lớp RBAC:
User
│
▼
┌──────────────┐
│ ArgoCD │
│ RBAC │
└──────┬───────┘
│
▼
┌──────────────┐
│ Kubernetes │
│ RBAC │
└──────┬───────┘
│
▼
Pod
ArgoCD RBAC
Quyết định:
User có được phép thao tác Application trong ArgoCD không?
Kubernetes RBAC
Quyết định:
ArgoCD có quyền thao tác resource trong Kubernetes không?
Hai lớp này không giống nhau.
ArgoCD mặc định cần quyền Kubernetes đủ để theo dõi và deploy resource; trong Production, quyền Kubernetes mà ArgoCD sử dụng cũng có thể được giới hạn thay vì giữ toàn quyền cluster.
🧪 19. Bài tập thực hành
Hãy tự xây dựng mô hình:
ArgoCD
│
┌───────────┼───────────┐
│ │ │
Developer QA DevOps
│ │ │
Read Sync Admin
│ │ │
▼ ▼ ▼
Dev Staging Production
Exercise 1 — Developer
Tạo:
developer
Cho phép:
applications → get
logs → get
Không cho phép:
sync
delete
Exercise 2 — QA
Tạo:
qa
Cho phép:
applications → get
applications → sync
Nhưng chỉ trên:
staging/*
Exercise 3 — DevOps
Tạo:
devops
Cho phép quản lý:
development
staging
production
Exercise 4 — Security Test
Đăng nhập bằng từng user.
Kiểm tra:
Developer
├── View Dev → ?
├── Sync Dev → ?
└── Delete Prod → ?
QA
├── View Staging → ?
├── Sync Staging → ?
└── Sync Production → ?
DevOps
├── Sync Production → ?
└── Delete App → ?
Mục tiêu:
View Sync Delete
Developer ✅ ❌ ❌
QA ✅ ✅ ❌
DevOps ✅ ✅ ✅
🔎 20. Troubleshooting
❌ User đăng nhập được nhưng không thấy Application
Kiểm tra:
kubectl get configmap argocd-rbac-cm \
-n argocd \
-o yaml
Đặc biệt kiểm tra:
policy.csv
và:
policy.default
❌ User thấy Application nhưng không Sync được
Kiểm tra policy:
applications, get
chỉ cho phép:
GET
Nếu muốn Sync cần policy tương ứng:
applications, sync
❌ User có quyền quá nhiều
Tìm wildcard:
applications, *, */*, allow
hoặc:
*, *, *, allow
Đây là dấu hiệu cần review RBAC.
❌ Sửa RBAC nhưng chưa thấy thay đổi
Kiểm tra ConfigMap:
kubectl get configmap argocd-rbac-cm -n argocd -o yaml
Sau đó kiểm tra lại session/user.
Nếu cần, restart ArgoCD server:
kubectl rollout restart deployment argocd-server -n argocd
💡 21. Kinh nghiệm Production
1️⃣ Không dùng admin cho công việc hàng ngày
❌ Developer → admin
❌ QA → admin
✅ Developer → developer role
✅ QA → qa role
✅ DevOps → devops role
2️⃣ Ưu tiên Least Privilege
Bắt đầu từ:
Không có quyền
↓
get
↓
sync
↓
update
↓
delete
Không bắt đầu bằng:
*
rồi tìm cách khóa lại.
3️⃣ Tách Production
Một mô hình tốt:
Developer
│
└── Dev
QA
│
└── Staging
Senior DevOps
│
└── Production
Production nên có boundary rõ ràng.
4️⃣ Dùng SSO trong Production
Local account phù hợp cho Lab.
Production thường nên tích hợp:
ArgoCD
│
▼
SSO / OIDC
│
├── Google
├── Azure AD
├── Okta
└── Keycloak
Khi đó có thể quản lý:
GitHub Team
Azure AD Group
↓
ArgoCD Role
Thay vì tạo hàng trăm local account.
5️⃣ Review RBAC thường xuyên
Đặc biệt sau khi:
- thêm Application
- thêm Project
- thêm team
- upgrade ArgoCD
- thêm tính năng như
exec - thay đổi CI/CD
Một policy wildcard hôm nay có thể mang ý nghĩa rộng hơn sau khi hệ thống được nâng cấp.
🧠 22. Tổng kết
Sau Lab này, hãy nhớ 5 điều:
1. Authentication
→ Bạn là ai?
2. Authorization
→ Bạn được làm gì?
3. Role
→ Gom các quyền thành một nhóm.
4. ArgoCD RBAC
→ Kiểm soát user được thao tác Application nào.
5. Kubernetes RBAC
→ Kiểm soát ArgoCD được thao tác resource nào trong cluster.
Mô hình cuối cùng:
User
│
▼
┌─────────────────┐
│ ArgoCD RBAC │
└────────┬────────┘
│
Allowed Action?
│
┌────┴────┐
│ │
YES NO
│ │
▼ ▼
ArgoCD API ❌
│
▼
Kubernetes RBAC
│
▼
Kubernetes
Tư duy quan trọng nhất của Lab này không phải là nhớ policy.csv.
Mà là:
🔐 Mỗi người chỉ nên có đúng quyền cần thiết để hoàn thành công việc của mình.
Đó chính là Least Privilege — một trong những nguyên tắc nền tảng khi đưa GitOps/ArgoCD vào Production.
All rights reserved
