Skip to main content

Command Palette

Search for a command to run...

Lộ trình học Vault associate

Updated
16 min readView as Markdown

Ngày 1: Cài đặt

  • Mục tiêu: Dựng Vault như một service ngay từ đầu - có TLS, có systemd/Docker Compose, không dùng vault server -dev sau ngày này.

  • Nội dung:

    • Lý thuyết:

      • Vault là gì: Secret Management, Data Encryption, Identity-Based Access, Audit Logging.

      • Kiến trúc: Client, API, Auth Methods, Policies, Secret Engines, Storage Backend, Audit Log, Seal/Unseal, Cryptographic Barrier.

      • Luồng: Authentication → Authorization → Access.

      • So sánh Open Source/Enterprise/HCP Vault Dedicated.

    • Thực hành:

      • Cài Vault bằng binary, chạy dưới systemd với file service unit (không copy nguyên mẫu, tự viết).

      • Tự tạo CA (mkcert hoặc openssl) và bật TLS cho listener - đừng để "học TLS sau".

      • Viết file cấu hình HCL bằng tay: listener, storage (file backend tạm), api_addr.

      • vault operator init, lưu unseal keys & root token đúng cách (không paste ra Slack!), vault operator unseal.

  • Mini-Project:

    1. Vault chạy như service: systemd service tự khởi động lại khi crash, log ra file riêng, TLS bắt buộc (không cho phép VAULT_SKIP_VERIFY).

    2. Vault với Docker Compose: dựng file docker-compose.yml có volume, network riêng, TLS mount vào container.

Ngày 2: KV và Transit Secrets Engine

  • Mục tiêu: Quản lý secrets tĩnh và mã hóa dữ liệu.

  • Nội dung:

    • Lý thuyết: KV v1 vs v2, CAS; Transit (Encryption as a Service), key rotation, static vs dynamic secrets, lease.

    • Thực hành:

      • vault secrets enable -path=kv-v2 -version=2 kv; put/get/list/delete; versioning, -cas.

      • vault secrets enable transit; tạo key, encrypt/decrypt, vault write transit/rotate/my-key.

  • Mini-Project:

    1. Secret Management cho ứng dụng web: lưu config DB vào KV, viết script đọc và inject vào app.

    2. Mã hóa PII: dùng Transit mã hóa dữ liệu nhạy cảm trước khi ghi DB, kiểm tra ảnh hưởng khi rotate key lên dữ liệu cũ.

Ngày 3: Authentication Methods + Bài toán "Secret Zero"

  • Mục tiêu: Xác thực người dùng/ứng dụng, và giải quyết câu hỏi kiến trúc: ai cấp credential đầu tiên cho một service hoàn toàn mới?

  • Nội dung:

    • Lý thuyết: Userpass, AppRole, human vs machine auth, entities/groups. Secret Zero Problem: dùng trusted platform attestation (Kubernetes Service Account, AWS IAM instance identity, CI/CD OIDC) thay vì nhúng static credential vào code/pipeline.

    • Thực hành:

      • Userpass: enable, tạo user, login.

      • AppRole: enable, tạo role với token_ttl/token_max_ttl, lấy Role ID + Secret ID, login.

      • Thiết kế response wrapping cho Secret ID (CI job pull một-lần, không lưu Secret ID tĩnh).

  • Mini-Project:

    1. AppRole cho CI/CD an toàn: Secret ID được wrap, CI job pull-once, TTL ngắn - không có credential tĩnh nào nằm trong repo hay pipeline config.

    2. Entities & Groups: gom nhiều auth method (Userpass + AppRole) về chung 1 identity, áp policy theo Group.

Ngày 4: Policies (Path-Based, Capabilities)

  • Mục tiêu: Kiểm soát truy cập theo nguyên tắc least privilege.

  • Nội dung:

    • Lý thuyết: Syntax path/capabilities/description; capabilities (read/write/create/update/delete/list/sudo); *+ trong path; deny-by-default; policy mặc định default/root.

    • Thực hành: Viết policy cho path cụ thể, dùng biến ({{identity.entity.id}}) để policy động theo user, áp cho token/entity/group, test bằng token (không chỉ đọc policy mà phải verify bằng cách gọi API).

  • Mini-Project:

    1. RBAC: admin/developer/operator - mỗi role có policy, group, và bộ test xác nhận đúng quyền/sai quyền.

    2. Policy động theo user: mỗi user chỉ truy cập được thư mục secret riêng của họ.

Ngày 5: Tokens (Service, Batch, Orphan) và Leases

  • Mục tiêu: Vòng đời token và secret động.

  • Nội dung:

    • Lý thuyết: Service/Batch/Orphan/Root token; token accessor; TTL/Max TTL; lease ID, renew/revoke, ảnh hưởng lease lên dynamic secrets.

    • Thực hành: vault token create/renew/revoke/capabilities/lookup; lấy dynamic secret (Database engine), theo dõi và renew/revoke lease.

  • Mini-Project:

    1. Token rotation tự động: cron/scheduled task lấy token mới định kỳ, TTL ngắn.

    2. Lease monitoring: liệt kê toàn bộ lease qua API, alert khi có lease sắp hết hạn.

**Ngày 6: Policy-as-Code với Terraform **

  • Mục tiêu: Không bao giờ vault write policy bằng tay trong production nữa. Mọi thay đổi qua Git + review + apply.

  • Nội dung:

    • Lý thuyết: Vault Terraform Provider; state file chứa secret → cần backend state mã hóa; drift detection; vì sao GitOps giảm rủi ro human-error trên production Vault.

    • Thực hành:

      • Viết .tf để tạo policy, auth method, secrets engine mount - từ Ngày 1-5, chuyển toàn bộ config đã làm tay sang Terraform.

      • Thiết lập pipeline CI (GitHub Actions) chạy terraform plan khi PR mở, apply khi merge.

  • Mini-Project:

    1. Vault Config as Code: repo Git chứa toàn bộ policy/auth/secrets-engine của môi trường demo, apply qua CI, có PR review giả lập.

Ngày 7: Vault Agent và Auto-Auth

  • Mục tiêu: Đơn giản hóa việc app lấy secret mà không cần biết Vault tồn tại.

  • Nội dung:

    • Lý thuyết: Auto-Auth methods; Caching (giảm latency); Templates (Consul Template syntax) để app "Vault-unaware".

    • Thực hành: Cấu hình Agent auto-auth bằng AppRole, cache token/lease, dùng template sinh file config từ secret.

  • Mini-Project:

    1. Vault Agent cho web app: Agent lấy config DB, render ra file, app tự động reload khi file đổi.

Ngày 8: PKI Secrets Engine - Root CA

  • Mục tiêu: Tự vận hành hạ tầng chứng chỉ nội bộ - use case production phổ biến bậc nhất, thường bị bỏ qua khi học Vault.

  • Nội dung:

    • Lý thuyết: PKI là gì trong Vault, Root CA vs Intermediate CA, vì sao không bao giờ để Root CA online lâu dài.

    • Thực hành: vault secrets enable pki, generate root CA, cấu hình max_lease_ttl, tạo role, issue certificate đầu tiên bằng CLI.

  • Mini-Project:

    1. Root CA offline: tạo Root CA, generate Intermediate CSR, sau đó seal/disable Root CA mount - mô phỏng đúng thực hành bảo mật (Root CA chỉ dùng để ký Intermediate rồi cất đi).

Ngày 9: PKI - Intermediate CA, Rotation, Tích hợp

  • Mục tiêu: Cấp và tự động renew cert cho một service.

  • Nội dung:

    • Lý thuyết: Intermediate CA ký cert leaf; CRL/OCSP; cert lifecycle và revoke; vì sao TTL cert ngắn + auto-renew tốt hơn cert dài hạn.

    • Thực hành:

      • Ký Intermediate CSR bằng Root CA, mount Intermediate, tạo role issue cert cho domain.

      • Cấu hình Nginx dùng cert do Vault cấp.

      • Dùng Vault Agent template để tự động renew cert trước khi hết hạn và reload Nginx.

      • Revoke 1 cert, kiểm tra CRL cập nhật.

  • Mini-Project:

    1. TLS nội bộ end-to-end: một service HTTPS chạy hoàn toàn bằng cert Vault cấp, tự renew, có revoke test.

Ngày 10: Kubernetes Authentication

  • Mục tiêu: Auth method phổ biến nhất cho microservices hiện đại.

  • Nội dung:

    • Lý thuyết: Vault xác thực Service Account token của K8s ra sao; Projected Service Account Token (bound audience) an toàn hơn long-lived SA token cũ.

    • Thực hành: Enable kubernetes auth, cấu hình kubernetes_host/CA cert, tạo role bind theo namespace + service account, pod gọi Vault lấy secret qua sidecar hoặc init container.

  • Mini-Project:

    1. Zero-credential pod: một pod K8s không có bất kỳ secret tĩnh nào, tự authenticate vào Vault bằng SA token và lấy DB credential.

Ngày 11: Vault Secrets Operator (VSO)

  • Mục tiêu: Quản lý secret trong Kubernetes theo kiểu native.

  • Nội dung:

    • Lý thuyết: VSO CRDs, Instant Updates, Encrypted Client Cache, Secret Transformation.

    • Thực hành: Cài VSO (Helm), tạo VaultConnection, VaultAuth, VaultStaticSecret/VaultDynamicSecret, deploy app dùng secret được sync tự động.

  • Mini-Project:

    1. DB credentials qua VSO: app K8s nhận credential tự cập nhật khi Vault xoay secret, không cần restart pod.

Ngày 12: Integrated Storage (Raft) - Cluster nhiều node

  • Mục tiêu: Không dựng cluster giả lập bằng port khác nhau trên localhost - dùng 3 máy ảo/container riêng biệt, qua network.

  • Nội dung:

    • Lý thuyết: Raft consensus, leader election, log replication, retry_join, node_id.

    • Thực hành: Cấu hình 3 node Vault riêng biệt (VM/container khác host), retry_join qua địa chỉ mạng, TLS giữa các node, vault operator raft list-peers.

  • Mini-Project:

    1. Cluster 3-node qua network: join thành công, xác nhận leader/follower, ghi secret ở 1 node và đọc được ở node khác.

Ngày 13: HA Cluster - Load Balancer + Network Topology

  • Mục tiêu: Đưa cluster ra "trước" một load balancer.

  • Nội dung:

    • Lý thuyết: Vì sao client phải luôn hit qua LB (không hit trực tiếp node); active-node redirection; health check endpoint (sys/health).

    • Thực hành: Dựng HAProxy/Nginx đứng trước cluster, health check để chỉ route vào node đang là leader (hoặc dùng ?perfstandbyok), test failover: kill leader, quan sát LB tự route sang leader mới.

  • Mini-Project:

    1. Failover có đo thời gian: kill process leader, đo thời gian client bị gián đoạn đến khi cluster bầu leader mới và LB route lại - ghi số liệu.

Ngày 14: Seal/Unseal và Auto Unseal

  • Mục tiêu: Hiểu và vận hành cơ chế bảo vệ dữ liệu cốt lõi của Vault.

  • Nội dung:

    • Lý thuyết: Shamir's Secret Sharing; Auto Unseal (AWS KMS/Azure Key Vault/GCP KMS); recovery keys vs unseal keys.

    • Thực hành: Cấu hình Auto Unseal với AWS KMS (free tier), restart node và xác nhận tự unseal không cần thao tác tay.

  • Mini-Project:

    1. Auto Unseal cho cả cluster 3-node: toàn bộ node tự unseal khi restart, không ai cần cầm unseal key thủ công nữa.

Ngày 15: Backup, Restore & Chaos Drill

  • Mục tiêu: Không chỉ biết lệnh - phải từng thật sự mất dữ liệu và tự cứu được.

  • Nội dung:

    • Lý thuyết: vault operator raft snapshot; RTO/RPO là gì; vì sao snapshot định kỳ + lưu ngoài cluster (S3) là bắt buộc.

    • Thực hành:

      • Cron job tự động snapshot lên S3/MinIO hàng giờ.

      • Drill 1 - mất 1 follower: kill node, xác nhận cluster vẫn phục vụ, join lại node mới.

      • Drill 2 - mất quorum: kill 2/3 node cùng lúc, quan sát cluster mất khả năng ghi, restore từ snapshot, đo thời gian phục hồi (RTO thực tế).

  • Mini-Project:

    1. Báo cáo Chaos Drill: viết lại đúng những gì đã xảy ra, RTO đo được, và checklist cải thiện cho lần sau.

Ngày 16: Vault Upgrade & Version Migration

  • Mục tiêu: Upgrade cluster production không downtime - kỹ năng gần như không ai học nhưng luôn cần.

  • Nội dung:

    • Lý thuyết: Đọc CHANGELOG/upgrade guide tìm breaking change trước khi upgrade; thứ tự upgrade standby trước, leader sau (rolling upgrade); version skew tạm thời có chấp nhận được không.

    • Thực hành: Upgrade cluster 3-node từ version N lên N+1 theo rolling fashion, xác nhận không mất quorum, không downtime cho client.

  • Mini-Project:

    1. Upgrade runbook: viết runbook từng bước kèm rollback plan nếu upgrade lỗi giữa chừng.

Ngày 17: Rekey & Root/Unseal Key Rotation không downtime

  • Mục tiêu: Xoay key định kỳ - yêu cầu compliance phổ biến (PCI-DSS, SOC2) mà bản kế hoạch cũ bỏ qua.

  • Nội dung:

    • Lý thuyết: vault operator rekey; root token regeneration; vì sao root token chỉ nên tồn tại trong thời gian ngắn (generate khi cần, revoke ngay sau).

    • Thực hành: Rekey cluster đang chạy traffic, generate root token tạm thời cho một tác vụ, revoke ngay sau khi dùng xong.

  • Mini-Project:

    1. Chính sách xoay key định kỳ: viết script/cron nhắc rekey mỗi quý, kèm quy trình phân phối recovery key an toàn cho nhiều người giữ (Shamir threshold).

Ngày 18: Vault Enterprise Replication (Performance & DR)

  • Mục tiêu: Đảm bảo tính sẵn sàng và phục hồi ở quy mô multi-region (nếu có Enterprise trial).

  • Nội dung:

    • Lý thuyết: Performance Replication vs DR Replication - bảng so sánh (mirror token/lease, ai xử lý client request); replication topology.

    • Thực hành: Cấu hình DR Replication giữa 2 cluster, thực hiện failover, đo thời gian và xác nhận secret/policy mirror đúng. Cấu hình Performance Replication với path filter.

  • Mini-Project:

    1. DR Plan: xác định rủi ro, cấu hình DR Replication, chạy failover test, viết báo cáo kết quả.

Ngày 19: Deployment Architecture & Capacity Planning

  • Mục tiêu: Biết cluster của bạn chịu được bao nhiêu tải bằng số liệu, không đoán.

  • Nội dung:

    • Lý thuyết: Single node vs Clustered vs HCP Vault Dedicated; các yếu tố HA/Scalability/Security/Monitoring cần cân nhắc khi thiết kế.

    • Thực hành: Dùng vault bench (hoặc load test tool tương tự) đo throughput/latency của cluster ở các mức tải khác nhau, xác định điểm nghẽn (CPU, disk I/O của Raft, network).

  • Mini-Project:

    1. Capacity report: số liệu về req/s cluster chịu được, khuyến nghị khi nào cần scale thêm node hoặc đổi storage backend.

Ngày 20: Vault API

  • Mục tiêu: Tự động hóa mọi tác vụ quản trị qua API.

  • Nội dung:

    • Lý thuyết: Authentication, Secrets/Policy/Auth Method CRUD, Audit, System Ops (seal/unseal/rekey/rotate) qua API; SDK (Go/Python); error handling, rate limiting, idempotency.

    • Thực hành: Viết script Python dùng hvac (hoặc curl thuần) để tự động enable auth method + tạo policy + tạo role trong 1 lần chạy.

  • Mini-Project:

    1. Vault bootstrap script: một script chạy 1 lệnh dựng toàn bộ cấu hình ban đầu của cluster mới (auth, secrets engine, policy cơ bản) - dùng lại được cho môi trường mới bất kỳ lúc nào.

Ngày 21: Observability - Telemetry, Prometheus, Grafana

  • Mục tiêu: Nhìn thấy sức khỏe cluster theo thời gian thực, không chỉ khi có sự cố mới biết.

  • Nội dung:

    • Lý thuyết: telemetry block; metric quan trọng: seal status, leader change count, request latency, token/lease count, storage I/O.

    • Thực hành: Cấu hình Vault export metric ra Prometheus, dựng Grafana dashboard, cấu hình Alertmanager cảnh báo khi seal hoặc mất leader.

  • Mini-Project:

    1. Dashboard + Alert: dashboard hiển thị đủ metric cốt lõi, alert bắn về Slack/email khi cluster sealed hoặc latency vượt ngưỡng.

Ngày 22: Audit Logging

  • Mục tiêu: Phát hiện truy cập bất thường bằng audit log, không chỉ biết bật tính năng.

  • Nội dung:

    • Lý thuyết: Audit device (file/syslog/socket); cấu trúc log request/response (đã hash sensitive field).

    • Thực hành: Bật audit log ra file, tạo vài truy cập "đáng ngờ" giả lập (nhiều lần login sai, truy cập path lạ), viết script jq phân tích log tìm ra pattern bất thường.

  • Mini-Project:

    1. Audit anomaly script: script tự động quét audit log định kỳ, cảnh báo khi có nhiều lần "permission denied" liên tiếp từ cùng 1 client.

Ngày 23: Troubleshooting & Incident Response Runbook

  • Mục tiêu: Tự đóng vai on-call, xử lý sự cố theo runbook của chính mình viết.

  • Nội dung:

    • Lý thuyết: Common issues: auth failure, connectivity, performance, data corruption, unreachable cluster. Công cụ: vault status, sys/health, debug logging, tcpdump.

    • Thực hành: Mô phỏng 3 sự cố (network cắt giữa các node, auth method cấu hình sai, disk đầy) và tự khắc phục theo thời gian thực (bấm giờ).

  • Mini-Project:

    1. Runbook "Vault sealed lúc nửa đêm": viết đủ chi tiết để một người khác (không phải bạn) follow theo và tự xử lý được sự cố.

Ngày 24: Security Hardening và Compliance

  • Mục tiêu: Đưa cluster đạt chuẩn bảo mật, không chỉ "chạy được".

  • Nội dung:

    • Lý thuyết: Network segmentation, least privilege, vulnerability scanning; PCI DSS/HIPAA/GDPR/SOC2 - Vault hỗ trợ compliance thế nào.

    • Thực hành: Firewall hạn chế kết nối đến Vault, review toàn bộ policy hiện có xem có policy nào quá rộng quyền, chạy vulnerability scan cơ bản.

  • Mini-Project:

    1. Vault Security Audit: báo cáo đánh giá rủi ro cấu hình hiện tại + khuyến nghị cải thiện, có mức độ ưu tiên.

Ngày 25: Multi-Tenancy - Namespaces + Sentinel

  • Mục tiêu: Governance ở quy mô nhiều team/tenant, gắn liền với Policy-as-Code.

  • Nội dung:

    • Lý thuyết: Namespace hierarchy, policy inheritance, resource isolation; Sentinel: data source, mocks, policy set.

    • Thực hành: Tạo namespace cho từng team qua Terraform (không tay), viết Sentinel policy enforce naming convention và giới hạn secret TTL.

  • Mini-Project:

    1. Vault as a Service nội bộ: mỗi team có namespace riêng, tự quản policy trong namespace của mình, Sentinel policy tổ chức áp đặt từ cấp trên.

Ngày 26: Vault và Cloud (AWS/Azure/GCP)

  • Mục tiêu: Cấp credential tạm thời cho cloud resource, không dùng static key.

  • Nội dung:

    • Lý thuyết: IAM Role/Managed Identity/Service Account làm auth method; Cloud Secrets Engine tạo credential tạm thời.

    • Thực hành: Cấu hình AWS Secrets Engine, tạo role sinh credential tạm cho S3, dùng credential đó trong một Lambda.

  • Mini-Project:

    1. Serverless không static key: Lambda function lấy credential từ Vault runtime, không có access key nào lưu trong biến môi trường.

Ngày 27: Vault và CI/CD (Jenkins/GitHub Actions)

  • Mục tiêu: Secrets-as-code trong pipeline, tích hợp với Ngày 6.

  • Nội dung:

    • Lý thuyết: Dynamic credentials generation trong pipeline; OIDC trust giữa CI platform và Vault (thay AppRole tĩnh khi có thể).

    • Thực hành: Cấu hình GitHub Actions OIDC → Vault JWT auth, pipeline lấy credential ngắn hạn để deploy, không lưu secret nào trong GitHub Secrets.

  • Mini-Project:

    1. Pipeline zero-static-secret: toàn bộ pipeline CI/CD deploy hạ tầng mà không có bất kỳ long-lived credential nào lưu trữ ở đâu cả.

Ngày 28: CAPSTONE - Dựng lại toàn bộ hệ thống

  • Mục tiêu: Bài kiểm tra sự. Làm được bài này thì Associate lẫn Ops Professional chỉ còn là thủ tục.

  • Đề bài:

    Công ty X có 3 team (payments, web, data). Yêu cầu: Vault HA 3-node qua network + TLS đầu-cuối; PKI tự cấp cert nội bộ cho service; AppRole/OIDC cho CI-CD; Kubernetes auth cho microservices; policy theo namespace mỗi team quản lý qua Terraform; backup tự động hàng ngày lên S3; alert khi seal hoặc mất leader; runbook DR hoàn chỉnh.

  • Ràng buộc: không xem lại tutorial cũ, tự dựng trong 3-5 ngày, tính luôn cả 1 lần chaos drill do người khác (hoặc chính bạn, giấu note) tạo ra để kiểm tra runbook có dùng được không.

  • Kết quả cần có: repo Terraform, dashboard Grafana, runbook DR, báo cáo capacity, và cluster đang chạy sống được review bởi người khác (hoặc chính bạn sau 1 tuần không đụng vào).

Knowledge

Part 1 of 50