# Syllabus học Boundary # TUẦN 0 - Tư duy nền tảng ### Ngày 1: Boundary là gì và giải quyết bài toán gì * **Mục tiêu:** Hiểu vị trí Boundary trong hệ sinh thái HashiCorp và so với VPN/bastion host/PAM truyền thống. * **Nội dung:** * Lý thuyết: Boundary là "identity-aware proxy" cho least-privileged, just-in-time access. Triết lý: Boundary lo **access** (ai được kết nối tới đâu), Vault lo **secrets** (credential động) - Boundary không thay thế Vault, hai sản phẩm bổ trợ nhau. * So sánh: VPN/bastion (trust theo network/IP) vs Boundary (trust theo identity, session có thời hạn, ghi log/record được). * 4 giai đoạn core workflow: **User Authentication** → **Granular Authorization** → **Dynamic catalog selection** → **Access**. * Thực hành: Cài Boundary dev mode (`boundary dev`), login, thử `boundary connect` tới 1 target demo. * **Mini-Project:** Không, warm-up. # TUẦN 1 - Domain Model & Core Concepts ### Ngày 2: Scopes - đơn vị tổ chức & blast radius * **Mục tiêu:** Hiểu cấu trúc phân cấp `Global → Organization → Project`. * **Nội dung:** * Lý thuyết: Scope là "container" cho resource và permission, mỗi scope có permission boundary cô lập → giới hạn blast radius. Global: admin cấu hình toàn hệ thống. Org: nên chia theo business unit. Project: chia theo sản phẩm/ứng dụng. * Thực hành: Tạo 1 org scope + 2 project scope, quan sát cây scope qua `boundary scopes list`. ### Ngày 3: IAM - Users, Groups, Auth Methods, Accounts * **Mục tiêu:** Hiểu cách Boundary định danh và xác thực principal. * **Nội dung:** * Lý thuyết: **Principal** = User hoặc Group. **Auth method** hỗ trợ password, OIDC, LDAP. **Account** là bộ credential cụ thể trong 1 auth method, gắn với 1 user; 1 user có thể có nhiều account từ nhiều auth method. * Thực hành: Tạo password auth method, account + user, login thử bằng CLI. ### Ngày 4: Access Management - Actions, Grants, Roles * **Mục tiêu:** Hiểu RBAC 3 tầng của Boundary. * **Nội dung:** * Lý thuyết: **Action** là hành vi trên resource. **Grant** = action(s) + resource(s) được phép (grant string `id=...;type=...;actions=...`). **Role** = tập hợp grant, gán cho principal, thuộc 1 scope duy nhất. * Thực hành: Viết grant string giới hạn 1 group chỉ `read,list` target trong 1 project, gán vào role, verify. ### Ngày 5: Host Resources - Host, Host Catalog, Host Set * **Mục tiêu:** Hiểu cách Boundary tổ chức và khám phá tài nguyên mạng. * **Nội dung:** * Lý thuyết: **Host** = computing element có network address. **Host catalog** chứa host + host set - loại `static` hoặc `plugin`\-based (dynamic). **Host set** = nhóm host tương đương cho access control. * Thực hành: Tạo static host catalog + host set với 2-3 host demo. ### Ngày 6: Targets - address-based vs host-sources-based * **Mục tiêu:** Hiểu cách user "thấy" và kết nối tới resource. * **Nội dung:** * Lý thuyết: **Target with address** (đơn giản, host đơn lẻ) vs **target with host sources** (linh hoạt, khuyến nghị khi nhiều host/host động). * Thực hành: Tạo 1 target address-based, 1 target host-set-based, so sánh. ### Ngày 7: Credentials - Store, Library, Brokering vs Injection * **Mục tiêu:** Hiểu cách Boundary cấp credential mà user không cần thấy secret. * **Nội dung:** * Lý thuyết: **Credential store** lưu/lấy/sinh credential. **Credential library** cấp credential cùng loại/access level từ 1 store. **Brokering** (trả credential về client) vs **injection** (Boundary tự inject, user không thấy secret). * Thực hành: Tạo static credential store, gắn vào target, connect và quan sát brokering vs injection. ### Ngày 8: Aliases & Sessions (khái niệm) * **Mục tiêu:** Hiểu 2 resource còn lại trong domain model. * **Nội dung:** * Lý thuyết: **Alias** là chuỗi DNS-like trỏ tới resource đích. **Session** = tập hợp connection giữa user và host, có thể mang credential, có thời hạn. * Thực hành: Tạo alias cho target ở Ngày 6, connect bằng alias. ### Ngày 9: Ôn tập Tuần 1 * **Mini-Project:** Dựng 1 cây scope (1 org, 2 project) + RBAC (2 role khác quyền) + 1 target host-set + 1 credential store injection + 1 alias, verify bằng 2 user khác quyền. # TUẦN 2 - Kiến trúc & Internals: Controller, Worker, State ### Ngày 10: Kiến trúc tổng thể - Control plane vs Data plane * **Mục tiêu:** Phân biệt Controller và Worker. * **Nội dung:** * Lý thuyết: **Controller** = control plane - API, state (Postgres), auth/authorization. **Worker** = data plane - proxy traffic thực tế, không lưu state lâu dài. * Thực hành: Setup 1 controller + 1 worker local, quan sát log giao tiếp. ### Ngày 11: Controller Internals - Repository Layer & State Model * **Mục tiêu:** Hiểu cách Controller thực sự đọc/ghi state, đủ để debug các lỗi liên quan tới data. * **Nội dung:** * Lý thuyết: Luồng nội bộ `Controller → Repository Layer → Postgres` - Repository layer đóng vai trò domain logic + validate trước khi chạm DB; transaction model đảm bảo mỗi thay đổi resource (vd tạo target + gắn host set) atomic; optimistic locking (version field) tránh ghi đè khi 2 request sửa cùng resource đồng thời; resource hierarchy trong DB phản chiếu đúng cây scope đã học ở Tuần 1. * Thực hành: Kết nối Postgres backend (dev mode), xem schema bảng chính, thử tạo 2 request sửa cùng 1 resource gần như đồng thời để quan sát version conflict. ### Ngày 12: Worker Lifecycle Internals * **Mục tiêu:** Hiểu đầy đủ vòng đời 1 worker và source code liên quan. * **Nội dung:** * Lý thuyết: Vòng đời `Register → Authorize → Session Receive → Proxy → Terminate`; worker định kỳ gửi status về controller (giống fingerprint ở các sản phẩm khác) để controller biết worker nào khả dụng cho session mới; source code tham khảo `internal/worker/handlers` (xử lý request/status) và `internal/worker/proxy` (logic proxy traffic thực tế). * Thực hành: Theo dõi log worker qua từng giai đoạn lifecycle khi mở 1 session mới, đối chiếu với sơ đồ lý thuyết. ### Ngày 13: PKI-based Worker Registration * **Mục tiêu:** Hiểu cách worker tự đăng ký an toàn với controller. * **Nội dung:** * Lý thuyết: Worker dùng PKI-based auth - tự sinh keypair, gửi registration request, controller xác nhận; giúp scale worker mà không cần phân phối secret tĩnh (khác cơ chế KMS-based auth cũ). * Thực hành: Đăng ký thêm 1 worker mới bằng PKI-based auth, verify qua `boundary workers list`. ### Ngày 14: Multi-hop Sessions & Ingress/Egress Workers * **Mục tiêu:** Hiểu cách Boundary kết nối tới target nằm sâu trong mạng private. * **Nội dung:** * Lý thuyết: **Multi-hop session** cho phép chuỗi worker (ingress → intermediate → egress) relay traffic qua nhiều network zone không cần mở firewall inbound; **worker tags/filters** chọn đúng worker qua `worker_filter`/`egress_worker_filter`/`ingress_worker_filter`. * Thực hành: Giả lập 2 mạng tách biệt, dùng multi-hop worker để connect tới target ở mạng "sâu" hơn. ### Ngày 15: Network Internals - Proxy Flow * **Mục tiêu:** Hiểu Boundary xử lý traffic ở tầng network/TLS, đủ để trả lời "ai thấy gì" trong 1 session. * **Nội dung:** * Lý thuyết: Luồng proxy đầy đủ `Client TCP connection → TLS tới worker → Session tunnel (worker xác thực session token) → Worker mở connection riêng tới target → Connection multiplexing khi có nhiều connection trong cùng 1 session`; điểm mấu chốt: Controller cấp session credential nhưng **không nằm trên đường truyền traffic**; Worker là nơi duy nhất thấy traffic thực tế (và có thể decrypt nếu TLS terminate tại đó); target có thể yêu cầu TLS riêng (double-hop TLS) tuỳ giao thức. * Thực hành: Dùng `tcpdump`/`ss` trên máy worker khi 1 session đang chạy để quan sát kết nối thực tế, đối chiếu với sơ đồ lý thuyết. ### Ngày 16: Session Authorization Flow - toàn bộ chuỗi * **Mục tiêu:** Nắm được flow quan trọng nhất của Boundary từ đầu đến cuối trong 1 bức tranh duy nhất. * **Nội dung:** * Lý thuyết: Chuỗi đầy đủ `User → OIDC (hoặc auth method khác) → Account → (Managed Group nếu có) → Role → Grant → Target → Session`; ở mỗi bước, Controller kiểm tra 1 điều kiện khác nhau (xác thực danh tính → map principal → resolve permission → tìm target hợp lệ → cấp session); hiểu rõ chuỗi này giúp debug cực nhanh khi user báo "không connect được" (lỗi có thể nằm ở bất kỳ mắt xích nào). * Thực hành: Vẽ lại sơ đồ flow này cho chính hệ thống đã dựng ở Ngày 9, đánh dấu từng bước tương ứng resource nào trong Boundary; cố tình phá 1 mắt xích (vd xoá grant) và xác định lỗi trả về tương ứng bước nào. ### Ngày 17: Deployment Topologies & HA Architecture * **Mục tiêu:** So sánh hướng triển khai và hiểu Boundary chịu tải/chịu lỗi ra sao. * **Nội dung:** * Lý thuyết: **HCP Boundary** (managed control plane, tự chạy private worker, có auto-update/DR/push-button deploy) vs **Enterprise self-managed** (full parity, tự vận hành controller + Postgres + worker) - tóm tắt nhanh khác biệt chủ yếu ở mức độ tự động hoá vận hành, không phải năng lực bảo mật cốt lõi. HA: nhiều controller sau load balancer cùng trỏ 1 Postgres HA, nhiều worker theo network zone; controller stateless về session nên scale ngang dễ. * Thực hành: Vẽ sơ đồ kiến trúc HA (2 controller + Postgres HA + 3 worker theo 3 zone) cho 1 hệ thống giả định. ### Ngày 18: Source Code Reading có định hướng * **Mục tiêu:** Có lộ trình đọc code Boundary hiệu quả cho ai muốn đi sâu hơn mức vận hành. * **Nội dung:** Thứ tự đọc: `internal/iam` (domain model: scope, user, role, grant) → `internal/auth` (auth method, OIDC/LDAP/password logic) → `internal/session` (session lifecycle, authorization) → `internal/worker` (lifecycle, proxy) → `internal/controller` (API handlers, gRPC giữa controller-worker). * **Mini-Project:** Đọc `internal/iam` và `internal/session`, viết note đối chiếu với sơ đồ Session Authorization Flow ở Ngày 16. ### Ngày 19: Ôn tập Tuần 2 * **Mini-Project:** Từ hệ thống Ngày 9, thêm 1 worker multi-hop, verify toàn bộ Session Authorization Flow qua log thực tế của cả Controller lẫn Worker. # TUẦN 3 - Authentication & Identity ### Ngày 20: Auth Methods Deep-dive * **Mục tiêu:** Nắm chi tiết từng loại auth method. * **Nội dung:** * Lý thuyết: `password` (native, bootstrap/demo); `oidc` (delegate IDP ngoài); `ldap` (Active Directory truyền thống). So sánh use case và giới hạn. * Thực hành: Cấu hình thêm 1 LDAP auth method trỏ tới LDAP server demo (hoặc mock). ### Ngày 21: OIDC Integration với IDP thực tế * **Mục tiêu:** Setup SSO thực chiến. * **Nội dung:** * Lý thuyết: Luồng OIDC: redirect → IDP xác thực → callback với ID token → Boundary map claim thành account/user. * Thực hành: Tích hợp OIDC với 1 IDP miễn phí (Okta dev/Auth0/Keycloak), login qua SSO. ### Ngày 22: Managed Groups * **Mục tiêu:** Tự động hoá gán quyền theo nhóm từ IDP. * **Nội dung:** * Lý thuyết: Managed group gom account dựa trên claim từ auth method backend - dùng trực tiếp làm principal trong role. * Thực hành: Tạo managed group filter theo claim, gán role, verify user trong nhóm IDP tự động có quyền. ### Ngày 23: Multi-account Users & SSO nâng cao * **Mục tiêu:** Xử lý tình huống 1 người có nhiều danh tính. * **Nội dung:** Lý thuyết: 1 user có thể liên kết account từ nhiều auth method - hữu ích khi migrate IDP hoặc có tài khoản service riêng. ### Ngày 24: Ôn tập Tuần 3 * **Mini-Project:** OIDC SSO đầy đủ + managed group tự động cấp quyền theo team, không thao tác thủ công nào ở Boundary sau setup. # TUẦN 4 - Cấu hình Access nâng cao ### Ngày 25: Configure Hosts - Dynamic Host Catalogs * **Mục tiêu:** Tự động hoá discovery tài nguyên cloud. * **Nội dung:** * Lý thuyết: Plugin-based host catalog (AWS/Azure/GCP) tự động quét/đồng bộ instance theo filter (tag, region...). * Thực hành: Cấu hình dynamic host catalog AWS (sandbox), filter theo tag, verify host tự xuất hiện. ### Ngày 26: Configure Targets - đa loại giao thức * **Mục tiêu:** Mở rộng ra ngoài SSH/TCP đơn giản. * **Nội dung:** * Lý thuyết: Target hỗ trợ TCP, SSH, RDP, database, Kubernetes; mỗi loại xử lý credential/injection khác nhau. * Thực hành: Tạo target RDP và database, thử connect với credential injection. ### Ngày 27: Kubernetes Access Patterns * **Mục tiêu:** Áp dụng Boundary cho use case ngày càng phổ biến - truy cập Kubernetes API riêng tư. * **Nội dung:** * Lý thuyết: Pattern `Developer → Boundary → Private Kubernetes API` giúp không cần expose K8s API server ra internet hay quản lý kubeconfig tĩnh; Boundary proxy traffic tới K8s API endpoint (EKS/RKE/OpenShift private endpoint), kết hợp Vault để cấp short-lived K8s token thay vì static kubeconfig. * Thực hành: Tạo target trỏ tới 1 private K8s API endpoint (hoặc mô phỏng bằng cluster local qua worker riêng), verify `kubectl` hoạt động qua Boundary session. ### Ngày 28: Vault Integration cho Credentials * **Mục tiêu:** Đạt true passwordless bằng dynamic secret. * **Nội dung:** * Lý thuyết: Boundary dùng Vault làm credential store, lấy dynamic credential (vd DB credential từ Vault Database Secrets Engine) cho từng session, tự thu hồi khi session kết thúc. * Thực hành: Cấu hình Vault credential store + credential library, gắn vào target, verify credential sinh mới mỗi session. ### Ngày 29: Credential Injection vs Brokering * **Mục tiêu:** Chọn đúng cơ chế theo yêu cầu bảo mật. * **Nội dung:** Lý thuyết: Injection phù hợp khi cần user tuyệt đối không thấy secret; brokering phù hợp khi ứng dụng/tool phía client cần tự cầm credential. * Thực hành: So sánh trải nghiệm 2 chế độ trên cùng target. ### Ngày 30: Transparent Sessions & Client Agent * **Mục tiêu:** Hiểu trải nghiệm "không cần biết đang dùng Boundary". * **Nội dung:** * Lý thuyết: Client Agent chạy nền, tự intercept kết nối tới alias/target quen thuộc và route qua Boundary session dựa trên client cache. * Thực hành: Cài Client Agent, connect tới alias qua công cụ quen thuộc (vd `ssh` thẳng). ### Ngày 31: Ôn tập Tuần 4 * **Mini-Project:** Target database + Vault dynamic credential + injection, thêm 1 dynamic host catalog AWS và 1 target Kubernetes, verify toàn chuỗi tự động. # TUẦN 5 - Sessions, Performance, Monitoring & Compliance ### Ngày 32: Session Lifecycle & Session Connections * **Mục tiêu:** Hiểu chi tiết vòng đời 1 session. * **Nội dung:** * Lý thuyết: Session có trạng thái pending → active → cancelling → terminated; 1 session có thể chứa nhiều connection; admin có thể cancel session để thu hồi quyền ngay lập tức. * Thực hành: Mở session, dùng `boundary sessions cancel` từ admin, quan sát client bị ngắt. ### Ngày 33: Session Recording Architecture * **Mục tiêu:** Hiểu kiến trúc ghi session, không chỉ cách bật tính năng. * **Nội dung:** * Lý thuyết: Session recording lưu dưới dạng cấu trúc thư mục trong **storage bucket** (external object store); **storage policy** định nghĩa retention/lifecycle; kiến trúc ghi diễn ra ở tầng Worker (nơi thấy traffic thực) rồi đẩy asynchronously lên storage bucket, không làm chậm session đang chạy; đây là tính năng chỉ có ở HCP Plus/Enterprise Plus. * Thực hành (nếu có tier phù hợp): Cấu hình storage bucket, bật recording cho 1 target, review lại session đã ghi. ### Ngày 34: Performance & Scale Planning * **Mục tiêu:** Trả lời câu hỏi production rất hay gặp: "cụm cần bao nhiêu controller/worker cho X user?" * **Nội dung:** * Lý thuyết: Các yếu tố cần cân nhắc khi scale từ 100 → 1,000 → 10,000 user: controller sizing (CPU/memory theo số request API đồng thời, chủ yếu bottleneck ở Postgres connection pool), worker sizing (băng thông + số session đồng thời proxy qua, bottleneck ở network throughput chứ không phải CPU), Postgres là điểm nghẽn chung nhất ở quy mô lớn (connection limit, transaction throughput) nên cần connection pooling (PgBouncer) và theo dõi sát; concurrent sessions ảnh hưởng trực tiếp tới số worker cần thiết theo network zone. * Thực hành: Ước lượng sizing cho 1 kịch bản giả định (vd 2,000 user, 500 session đồng thời cao điểm), đề xuất số controller/worker + cấu hình Postgres tương ứng. ### Ngày 35: Monitor Access - Audit Logs & Event Streaming * **Mục tiêu:** Giám sát truy cập theo thời gian thực. * **Nội dung:** * Lý thuyết: Audit log ghi mọi request API; event streaming đẩy log ra SIEM ngoài (Splunk, Datadog...) để cảnh báo real-time. * Thực hành: Bật audit logging, thử vài action, review log sinh ra. ### Ngày 36: Audit & Compliance sâu hơn * **Mục tiêu:** Hiểu Boundary hỗ trợ các khung compliance phổ biến thế nào. * **Nội dung:** Lý thuyết: Ánh xạ tính năng Boundary vào yêu cầu compliance thường gặp - **PCI-DSS** (least-privileged access, session logging cho hệ thống chứa dữ liệu thẻ), **SOC2** (audit trail đầy đủ ai truy cập gì khi nào, access review định kỳ qua role/grant), **ISO27001** (quản lý access lifecycle, thu hồi quyền tức thời qua session cancel); session recording (nếu có tier) là bằng chứng mạnh nhất cho auditor. ### Ngày 37: Cloud-native Access Patterns * **Mục tiêu:** Áp dụng Boundary đúng cách trong kiến trúc cloud thực tế. * **Nội dung:** Lý thuyết: Pattern phổ biến theo từng cloud - **AWS**: `Boundary → Vault (dynamic secret) → RDS/EC2` kết hợp dynamic host catalog theo tag; **Azure**: tương tự với Azure AD làm OIDC provider + dynamic host catalog Azure; **GCP**: kết hợp Workload Identity của GCP với Vault; điểm chung: Boundary luôn đứng giữa user và resource, Vault luôn đứng giữa Boundary và credential thực. ### Ngày 38: Ôn tập Tuần 5 * **Mini-Project:** Bản sizing + kiến trúc giám sát/compliance hoàn chỉnh cho 1 hệ thống giả định 2,000 user, kèm mapping tính năng Boundary vào ít nhất 1 khung compliance cụ thể. # TUẦN 6 - Security & Operations ### Ngày 39: Secure Boundary - TLS & KMS * **Mục tiêu:** Bảo mật giao tiếp và encryption-at-rest. * **Nội dung:** * Lý thuyết: TLS giữa client-controller và controller-worker; KMS (Vault Transit hoặc cloud KMS) mã hoá dữ liệu nhạy cảm trong Postgres. * Thực hành: Cấu hình KMS block trỏ Vault Transit/AWS KMS, verify controller khởi động thành công. ### Ngày 40: Deploy Boundary - Self-managed HA Setup * **Mục tiêu:** Triển khai thực tế cụm production tự quản lý. * **Nội dung:** Thực hành: Deploy 2 controller + Postgres HA + 2 worker bằng Terraform/Docker Compose, verify LB phân phối đúng, worker vẫn hoạt động khi 1 controller down. ### Ngày 41: Upgrade Boundary * **Mục tiêu:** Nâng cấp version không downtime. * **Nội dung:** Lý thuyết: Rolling upgrade controller trước (giữ ít nhất 1 controller sống), sau đó worker; kiểm tra compatibility matrix. ### Ngày 42: Disaster Recovery * **Mục tiêu:** Chuẩn bị phương án phục hồi khi có sự cố nghiêm trọng. * **Nội dung:** Lý thuyết: Backup/restore Postgres state, recovery KMS key để phục hồi quyền truy cập dữ liệu mã hoá; ở HCP, DR phần lớn tự động hoá (managed); ở self-managed cần tự xây quy trình backup Postgres định kỳ + test restore + lưu trữ recovery KMS key an toàn tách biệt khỏi cụm chính. * Thực hành: Backup Postgres, giả lập mất cụm, restore và verify Boundary hoạt động lại đầy đủ. ### Ngày 43: Enterprise Features * **Mục tiêu:** Có bức tranh đầy đủ về những gì Enterprise/HCP thêm so với OSS. * **Nội dung:** Lý thuyết: Tổng hợp lại - Session recording architecture (Ngày 33), Worker filtering nâng cao (filter phức tạp hơn theo nhiều tag/attribute kết hợp, ưu tiên worker theo latency), HCP deployment model (control plane managed, chỉ cần vận hành private worker), DR automation (backup/restore tự động, không cần tự script). Giúp ra quyết định đúng giữa OSS/Enterprise/HCP theo nhu cầu tổ chức. ### Ngày 44: Troubleshooting - Common Error Messages * **Mục tiêu:** Debug nhanh các lỗi thường gặp. * **Nội dung:** * Lý thuyết: Lỗi permission denied (grant sai), worker không reachable (network/firewall/PKI registration), session bị treo (credential store lỗi kết nối Vault), lỗi API do version mismatch. * Thực hành: Cố tình gây 2-3 lỗi và tự debug bằng log + tài liệu "Common error messages", đối chiếu với Session Authorization Flow (Ngày 16) để xác định lỗi rơi vào mắt xích nào. ### Ngày 45: Ôn tập Tuần 6 * **Mini-Project:** Runbook upgrade cụm 2-controller không downtime + quy trình backup/restore đã test + checklist xử lý 3 lỗi thường gặp nhất. # TUẦN 7 - Automation & Ecosystem ### Ngày 46: Terraform Boundary Provider * **Mục tiêu:** IaC hoá toàn bộ cấu hình Boundary. * **Nội dung:** * Lý thuyết: Terraform provider quản lý hầu hết resource domain model - version control cấu hình IAM/access thay vì click tay. * Thực hành: Viết Terraform apply toàn bộ setup từ Ngày 9 bằng code. ### Ngày 47: CLI, API & Go SDK Automation * **Mục tiêu:** Tự động hoá vượt ra ngoài Terraform cho tác vụ vận hành/runtime. * **Nội dung:** * Lý thuyết: HTTP API cho phép build tool nội bộ (tự cấp quyền tạm thời khi incident, tự cancel session khi phát hiện bất thường); Go SDK khi cần tích hợp sâu vào hệ thống Go nội bộ. * Thực hành: Viết script gọi API tạo role tạm thời, gán quyền, tự thu hồi sau X phút - mô phỏng just-in-time access elevation. ### Ngày 48: CI/CD Integration Patterns * **Mục tiêu:** Đưa Boundary vào pipeline tự động. * **Nội dung:** Thực hành: Pipeline CI/CD dùng Boundary connect tới môi trường private khi cần migration/deploy, request session ngắn hạn qua CLI/API trong job, tự hết hạn sau khi job xong. ### Ngày 49: Ôn tập Tuần 7 * **Mini-Project:** Toàn bộ hạ tầng Boundary quản lý bằng Terraform trong 1 repo, kèm 1 script just-in-time access elevation qua API. # TUẦN 8 - Capstone ### Ngày 50: Capstone Project - Triển khai Boundary Production hoàn chỉnh **Yêu cầu:** 1. Kiến trúc HA: 2+ controller sau load balancer, Postgres HA (có connection pooling), worker triển khai theo tối thiểu 2 network zone với ít nhất 1 chuỗi multi-hop. 2. IAM đầy đủ: cây scope, SSO qua OIDC với 1 IDP thực, managed group tự động cấp quyền theo team. 3. Access resources: dynamic host catalog cloud, target đa giao thức (SSH + database + Kubernetes), ít nhất 1 target address-based. 4. Credential: Vault credential store với dynamic secret + injection cho true passwordless. 5. Bảo mật: TLS toàn bộ, KMS ngoài, worker PKI-based auth. 6. Giám sát & Compliance: audit logging + event streaming ra hệ thống ngoài; mapping tính năng đã dùng vào ít nhất 1 khung compliance (SOC2/PCI-DSS/ISO27001); (nếu có tier) session recording cho 1 target nhạy cảm. 7. Vận hành: runbook upgrade không downtime, backup/restore Postgres đã test, bản sizing ước lượng cho quy mô mục tiêu (vd 2,000 user). 8. Automation: toàn bộ cấu hình bằng Terraform, có script just-in-time access elevation qua API. 9. Internals: tài liệu hoá Session Authorization Flow của chính hệ thống capstone (sơ đồ tự vẽ, không copy lý thuyết), kèm ghi chú đã đọc qua source `internal/iam`, `internal/session`. 10. Troubleshooting: tài liệu hoá 3 sự cố phổ biến nhất đã tự tạo và tự xử lý được.