Audit Logging, Security Posture & Hardening Checklist

Vì sao "phát hiện" là lớp phòng thủ cuối cùng — và quan trọng nhất

Chín file trước của chương này đều nói về phòng ngừa: dựng tường, đóng cổng, thu hẹp quyền. Nhưng có một sự thật mà mọi security engineer trưởng thành đều thừa nhận: phòng ngừa sẽ thất bại. Không phải vì kỹ thuật kém, mà vì hệ thống production luôn vận động — một RBAC binding được nới lỏng lúc 2 giờ sáng để fix sự cố và không bao giờ thu hồi, một Network Policy bị xóa nhầm khi refactor, một image cũ với CVE nghiêm trọng vẫn chạy vì không ai để ý. Khi phòng ngừa thất bại, câu hỏi không còn là "liệu có ai vào được không" mà là "khi họ vào, tôi có biết không, và tôi tái dựng được chuỗi sự kiện không?"

Đây là lý do audit logging và security posture không phải là phần phụ lục cuối chương — chúng là điều kiện để mọi lớp phòng thủ khác có ý nghĩa. Một enforcement chặt mà không có log thì không thể kiểm chứng là nó thực sự đang chạy; một cluster hardening tốt hôm nay nhưng không được quét posture định kỳ thì sẽ trượt khỏi chuẩn (configuration drift) mà không ai hay. Lớp này biến bảo mật từ một trạng thái tĩnh ("tôi đã cấu hình đúng") thành một quá trình động ("tôi liên tục biết mình đang ở đâu so với chuẩn, và tôi thấy được khi có gì bất thường").

File này khép lại chương theo hai hướng. Thứ nhất là khả năng quan sát bảo mật: bạn ghi lại gì, ở đâu, và truy vấn nó thế nào khi điều tra sự cố. Thứ hai là tổng hợp: một checklist hardening đi qua cả bảy lớp phòng thủ đã trình bày, để bạn có một artifact vận hành duy nhất dùng được trong review kiến trúc, trong audit compliance, hoặc khi onboard một cluster mới.

Mô hình phân tầng của audit logging trên GKE

Trước khi nói về cấu hình, cần một mental model rõ ràng: trên GKE, có hai nguồn audit log tách biệt nhau về bản chất, và nhầm lẫn giữa chúng là nguyên nhân phổ biến khiến điều tra sự cố đi vào ngõ cụt.

Nguồn thứ nhất là Cloud Audit Logs ở tầng GCP. Đây là log của API Google Cloud: ai đã gọi container.googleapis.com để tạo cluster, ai sửa node pool, ai gán IAM role. Đối tượng (subject) ở đây là Google identity (user, service account) và đối tượng tác động là tài nguyên GCP (cluster, node pool, IAM policy). Log này do GCP control plane sinh ra, bạn không cần làm gì để có Admin Activity log.

Nguồn thứ hai là Kubernetes audit log ở tầng cluster. Đây là log của Kubernetes API server: ai đã kubectl create pod, ai sửa Secret, ai gọi exec vào một container. Đối tượng ở đây là Kubernetes identity (đã được phân giải qua hai cổng IAM→RBAC ở file 2 và 3) và đối tượng tác động là Kubernetes object (Pod, Secret, RoleBinding). Trên GKE, log này được control plane do Google quản lý sinh ra và tự động chuyển tiếp vào Cloud Logging — bạn không tự dựng audit policy cho API server như khi tự host Kubernetes, vì control plane là managed.

Sự phân tầng này phản chiếu đúng mô hình hai cổng ở file 2: GCP API là cổng để quản lý cluster, Kubernetes API là cổng để hành động bên trong cluster. Một cuộc tấn công thực tế thường để lại dấu vết ở cả hai tầng, và năng lực điều tra của bạn phụ thuộc vào việc bạn có cả hai. Ví dụ: kẻ tấn công gán cho mình container.admin (dấu vết ở Cloud Audit Logs / Admin Activity) rồi dùng quyền đó lấy credential cluster và tạo một privileged Pod (dấu vết ở Kubernetes audit log). Nếu chỉ bật một tầng, bạn chỉ thấy nửa câu chuyện.

Bốn loại Cloud Audit Logs — và bẫy chi phí của Data Access

Cloud Audit Logs phân thành bốn loại, và hiểu sự khác biệt giữa chúng là bắt buộc vì nó quyết định cả khả năng forensics lẫn hóa đơn của bạn.

Loại	Ghi lại gì	Mặc định	Chi phí	Tắt được không
Admin Activity	Mọi thao tác ghi (write) làm thay đổi cấu hình hoặc metadata: tạo cluster, sửa node pool, gán IAM	Luôn bật	Miễn phí	Không
Data Access	Thao tác đọc cấu hình và đọc/ghi dữ liệu người dùng do API thực hiện	Tắt (trừ BigQuery)	Tốn phí (theo dung lượng log)	Có
System Event	Hành động do hệ thống Google Cloud thực hiện, không phải do người dùng (ví dụ live migration của VM)	Luôn bật	Miễn phí	Không
Policy Denied	Khi một request bị từ chối bởi vi phạm chính sách bảo mật (ví dụ VPC Service Controls)	Bật khi service phát sinh	Tốn phí	Lọc được nhưng không tắt hẳn

Hai điểm cốt tử về vận hành:

Admin Activity là nền tảng compliance — và nó miễn phí, không tắt được. Đây là tin tốt: mọi thao tác thay đổi cấu hình cluster, mọi lần sửa IAM, đều được ghi mặc định và bạn không phải trả tiền cho nó. Với phần lớn yêu cầu compliance (SOC 2, ISO 27001, PCI-DSS) về "ai đã thay đổi gì", Admin Activity log đã đáp ứng. Hệ quả thiết kế: đừng bao giờ dựa vào việc tắt log để tiết kiệm tiền ở đây — bạn không thể, và bạn cũng không nên muốn.

Data Access là con dao hai lưỡi về chi phí. Trên một cluster GKE bận rộn, kube-apiserver và các controller liên tục thực hiện thao tác đọc (list/watch/get) với khối lượng khổng lồ. Nếu bật Data Access log toàn diện một cách ngây thơ, bạn có thể tạo ra hàng trăm GB log mỗi ngày và một hóa đơn Cloud Logging gây sốc — phần lớn là tiếng ồn từ các thao tác đọc tự động của hệ thống. Đây là một anti-pattern kinh điển. Cách làm đúng: bật Data Access có chọn lọc, chỉ cho các service và loại thao tác thực sự cần (ví dụ chỉ DATA_READ trên các API nhạy cảm liên quan tới quản lý cluster), và dùng exclusion filter ở Cloud Logging để loại bỏ tiếng ồn từ service account hệ thống trước khi log bị tính phí lưu trữ.

Cấu hình Data Access được kiểm soát qua IAM audit config trong policy của project/organization:

# Trích đoạn IAM policy: bật DATA_READ cho GKE nhưng loại trừ một SA hệ thống ồn ào
auditConfigs:
- service: container.googleapis.com
  auditLogConfigs:
  - logType: ADMIN_READ
  - logType: DATA_READ
    exemptedMembers:
    - serviceAccount:system-noise@PROJECT_ID.iam.gserviceaccount.com

Trade-off cốt lõi: Data Access log là thứ cho bạn biết ai đã đọc cái gì — cực kỳ giá trị khi điều tra rò rỉ dữ liệu (data exfiltration). Nhưng nó cũng là nguồn chi phí lớn nhất. Quyết định đúng không phải "bật hay tắt" mà là "bật ở đâu, lọc cái gì". Một tổ chức tài chính bị ràng buộc compliance sẽ bật rộng và chấp nhận chi phí; một startup có thể chỉ bật cho các API quản lý nhạy cảm.

Kubernetes audit log trên GKE và forensics điển hình

Vì control plane GKE là managed, bạn không tự định nghĩa Kubernetes audit policy (như Metadata/Request/RequestResponse level khi tự host). Thay vào đó, GKE sinh audit log của API server theo chính sách của Google và đẩy vào Cloud Logging dưới hai resource type quan trọng:

• k8s_cluster — sự kiện audit ở cấp Kubernetes API server (tạo Pod, sửa Secret, RBAC change…)
• k8s_container, k8s_pod, k8s_node — log vận hành/ứng dụng ở các cấp tương ứng

Điều quan trọng với điều tra là các bản ghi audit của Kubernetes API server xuất hiện trong Cloud Logging với protoPayload mang đầy đủ ngữ cảnh: ai (authenticationInfo.principalEmail), làm gì (methodName, ví dụ io.k8s.core.v1.pods.create), trên đối tượng nào (resourceName), và từ đâu (requestMetadata.callerIp). Đây chính là dữ liệu cho phép tái dựng chuỗi tấn công.

Một vài query forensics điển hình (Logs Explorer, ngôn ngữ Logging query):

Ai đã tạo privileged Pod hoặc Pod có hostPath nhạy cảm?

resource.type="k8s_cluster"
protoPayload.methodName="io.k8s.core.v1.pods.create"
protoPayload.request.spec.containers.securityContext.privileged=true

Ai đã exec vào container (một dấu hiệu kinh điển của lateral movement / hands-on-keyboard)?

resource.type="k8s_cluster"
protoPayload.methodName="io.k8s.core.v1.pods.exec.create"

Mọi thay đổi RBAC — nguồn của leo thang đặc quyền (xem file 3):

resource.type="k8s_cluster"
protoPayload.methodName=~"rbac.authorization.k8s.io.*(create|update|delete)"

Mọi truy cập tới Secret — nơi credential bị đánh cắp:

resource.type="k8s_cluster"
protoPayload.resourceName=~"secrets/"
protoPayload.methodName=~"io.k8s.core.v1.secrets.(get|list|watch)"

Các quyết định Binary Authorization bị từ chối (liên kết file 9):

resource.type="k8s_cluster"
logName=~"binaryauthorization.googleapis.com"
protoPayload.status.code!=0

Mô hình tư duy khi điều tra: bắt đầu từ một chỉ dấu (một image lạ chạy, một Secret bị truy cập bất thường), dùng principalEmail của bản ghi đó làm trục, rồi pivot — truy mọi hành động khác của cùng principal trong cửa sổ thời gian, và bắc cầu sang Cloud Audit Logs ở tầng GCP để xem principal đó có được cấp quyền bất thường ngay trước đó không. Năng lực pivot xuyên hai tầng này là toàn bộ giá trị của việc bật đầy đủ audit log.

Một anti-pattern cần tránh: giữ log forensics chung quyền truy cập với người vận hành cluster. Nếu kẻ tấn công chiếm được quyền cluster-admin và quyền đó cũng cho phép xóa/sửa log, họ sẽ xóa dấu vết. Hãy export log sang một sink riêng (Cloud Storage bucket hoặc BigQuery dataset trong một project tách biệt, với IAM riêng và bucket lock/retention) để bản ghi audit là bất biến và nằm ngoài tầm với của quyền vận hành thường nhật. Đây là nguyên tắc tách biệt nhiệm vụ (separation of duties) áp dụng cho chính hệ thống log.

GKE Security Posture — biến hardening tĩnh thành giám sát liên tục

Hardening một lần là chưa đủ vì cluster trôi khỏi chuẩn theo thời gian. GKE Security Posture dashboard là cơ chế native của GKE để liên tục đánh giá và báo cáo tình trạng bảo mật, hiển thị tập trung trong Google Cloud console cho mọi cluster trong project/fleet. Nó gồm vài năng lực tách biệt mà bạn nên hiểu rõ ranh giới:

Configuration scanning (quét cấu hình workload). Posture liên tục so cấu hình workload đang chạy với một bộ best practice (chủ yếu dựa trên Pod Security Standards và các khuyến nghị hardening của GKE) và phát hiện các lệch chuẩn: container chạy privileged, không đặt runAsNonRoot, mount hostPath nhạy cảm, capability dư thừa. Đây chính là phiên bản quan sát của những gì file 6 enforce bằng Pod Security Admission — posture phát hiện và báo cáo, PSA chặn. Hai thứ bổ trợ: PSA chặn cái mới sai, posture phát hiện cái cũ đã lọt hoặc nằm ngoài phạm vi enforce.

Workload vulnerability scanning (quét lỗ hổng workload). Posture tích hợp với Artifact Analysis để quét lỗ hổng trong image của các workload đang chạy — không chỉ image trong registry (scan lúc build) mà chính những gì đang chạy ngay bây giờ. Đây là điểm mấu chốt: một image sạch lúc build có thể trở thành lỗ hổng tuần sau khi một CVE mới được công bố cho một package nó chứa. Quét workload đang chạy bắt đúng khoảng trống này — nó là phiên bản runtime của Continuous Validation mà file 9 mô tả cho Binary Authorization, nhưng nhìn ở góc CVE thay vì attestation. Tùy gói, nó còn mở rộng tới lỗ hổng ở lớp ngôn ngữ/OS và security bulletin của chính GKE.

Security bulletins. Posture surface các bản tin bảo mật áp dụng cho phiên bản GKE cụ thể của cluster — ví dụ một CVE ở kubelet hoặc control plane cần nâng cấp. Điều này nối thẳng vào kỷ luật patching/upgrade của node và control plane trong checklist bên dưới.

Mọi phát hiện (finding) của Posture đều có mức nghiêm trọng và được ghi vào Cloud Logging, từ đó có thể chuyển thành cảnh báo (alerting) qua Cloud Monitoring. Đây là cách bạn đóng vòng lặp: posture phát hiện → log → alert → người chịu trách nhiệm xử lý. Một dashboard không ai nhìn thì vô dụng; giá trị nằm ở việc nối finding nghiêm trọng vào một kênh cảnh báo có người trực.

Vị trí của Security Command Center

GKE Security Posture là cánh cửa native ở cấp GKE, nhưng trong một tổ chức lớn nó là một nguồn finding chảy vào Security Command Center (SCC) — mặt phẳng quản lý bảo mật cấp organization của Google Cloud. SCC tổng hợp finding từ GKE Security Posture, Artifact Analysis, Event Threat Detection, Container Threat Detection và nhiều nguồn khác thành một khung nhìn rủi ro thống nhất cho toàn tổ chức.

Ranh giới đáng nhớ:

• GKE Security Posture: tập trung vào một (hoặc một fleet) cluster GKE, miễn phí ở tier cơ bản cho config scanning, là nơi platform engineer GKE làm việc hằng ngày.
• Container Threat Detection (thuộc SCC tier cao): phát hiện runtime threat — ví dụ một binary lạ được thực thi trong container, một reverse shell, sửa đổi nhị phân bất thường. Đây là phát hiện hành vi đang diễn ra, khác với quét cấu hình/lỗ hổng tĩnh.
• Security Command Center: lớp tổng hợp cấp organization, nơi CISO/security team nhìn rủi ro xuyên mọi project, và là nơi cắm các finding GKE vào quy trình response chung.

Quyết định kiến trúc thực tế: với một đội nhỏ vận hành vài cluster, GKE Security Posture (config scanning miễn phí) + Artifact Analysis là đủ để có vòng lặp posture lành mạnh. Khi tổ chức mở rộng tới hàng chục project và cần phát hiện threat runtime cùng một mặt phẳng response thống nhất, đầu tư vào SCC tier cao (kèm Container Threat Detection) trở nên xứng đáng. Đừng mua SCC Premium chỉ để có thứ mà config scanning miễn phí của Posture đã cung cấp.

Checklist hardening đầy đủ — tổng hợp bảy lớp

Phần này là artifact vận hành cô đọng của cả chương: một checklist đi qua bảy lớp phòng thủ. Mỗi mục dẫn chiếu file đã giải thích "vì sao". Dùng nó khi review một cluster mới, khi audit compliance, hoặc như định nghĩa "đủ điều kiện lên production".

Lớp 1 — Control plane

• [ ] Private cluster: control plane endpoint không phơi ra Internet công cộng; node không có public IP (file 1). Dùng private endpoint, truy cập qua mạng nội bộ/VPN/IAP.
• [ ] Authorized networks: nếu phải để lộ control plane endpoint, giới hạn bằng danh sách CIDR được phép; không bao giờ 0.0.0.0/0 (file 1, 2).
• [ ] Tắt legacy authentication: tắt client certificate tĩnh, tắt basic auth (đã loại bỏ), không dùng ABAC — chỉ dựa vào IAM + RBAC (file 2).
• [ ] VPC Service Controls quanh các API nhạy cảm để chống exfiltration nếu credential rò rỉ (file 1).
• [ ] Control plane auto-upgrade bật, theo release channel phù hợp (regular/stable) để vá CVE control plane kịp thời (file 5, và security bulletin ở trên).

Lớp 2 — Identity & access (hai cổng IAM ↔ RBAC)

• [ ] Least privilege ở IAM: không cấp container.admin/Owner rộng rãi; dùng predefined role hẹp nhất phù hợp (container.developer, container.viewer) (file 3).
• [ ] Least privilege ở RBAC: không bind cluster-admin cho ServiceAccount hay nhóm rộng; ưu tiên Role có namespace thay vì ClusterRole; tránh wildcard verb/resource (file 3).
• [ ] Không bind quyền cho system:authenticated/system:anonymous — một anti-pattern phơi cluster cho mọi danh tính đã xác thực (file 3).
• [ ] Bound ServiceAccount token (projected, audience-bound, hết hạn) thay vì legacy Secret-based token; đặt automountServiceAccountToken: false khi workload không gọi API server (file 2).
• [ ] Audit định kỳ RBAC bằng kubectl auth can-i --list và rà các binding tới role mạnh.

Lớp 3 — Workload Identity

• [ ] Workload Identity Federation for GKE bật trên cluster và node pool (GKE_METADATA); không gắn key service account dạng JSON vào Pod (file 4).
• [ ] Metadata concealment / chặn truy cập metadata server thô để Pod không lấy được node service account token (file 4, 5).
• [ ] Node service account tối thiểu: không dùng Compute Engine default service account; tạo SA riêng chỉ với quyền cần thiết (logging, monitoring, pull image) (file 5).

Lớp 4 — Node

• [ ] Shielded GKE Nodes bật (Secure Boot, vTPM, Integrity Monitoring) (file 5).
• [ ] Container-Optimized OS (COS) làm node image — rootfs read-only, bề mặt tấn công tối thiểu (file 5).
• [ ] Node auto-upgrade & auto-repair bật để vá kịp và giữ node lành mạnh (file 5).
• [ ] Cân nhắc Confidential GKE Nodes (mã hóa bộ nhớ, AMD SEV) cho workload xử lý dữ liệu cực nhạy cảm (file 5).
• [ ] Cân nhắc gVisor (runtimeClassName: gvisor) cho workload đa thuê bao hoặc chạy code không tin cậy (file 5).

Lớp 5 — Pod / workload

• [ ] Pod Security Admission bật ở mức Restricted cho namespace ứng dụng (enforce), dùng audit/warn để rollout an toàn (file 6).
• [ ] securityContext chuẩn: runAsNonRoot: true, allowPrivilegeEscalation: false, readOnlyRootFilesystem: true, capabilities.drop: ["ALL"], seccompProfile.type: RuntimeDefault (file 6).
• [ ] Không privileged container, không hostNetwork/hostPID/hostIPC, không hostPath nhạy cảm trừ khi có lý do được phê duyệt (file 6).
• [ ] Resource limits đặt đầy đủ — phòng thủ chống một Pod làm cạn tài nguyên node (liên quan reliability/security).

Lớp 6 — Network

• [ ] Network Policy default-deny cho mọi namespace, rồi mở allowlist tối thiểu cho luồng cần thiết (file 7).
• [ ] Dataplane V2 (eBPF/Cilium) cho hiệu năng và Network Policy logging (file 7).
• [ ] Kiểm soát egress (gồm DNS), cân nhắc FQDNNetworkPolicy cho allowlist theo tên miền (file 7).
• [ ] Network Policy logging bật để quan sát luồng bị chặn/cho phép phục vụ điều tra (file 7).

Lớp 7 — Supply chain

• [ ] Binary Authorization bật, require-attestation cho production, dryRun cho dev trước khi enforce (file 9).
• [ ] Artifact Analysis / vulnerability scanning bật trên registry và trên workload đang chạy (file này, phần Posture).
• [ ] Admission policy (Policy Controller / ValidatingAdmissionPolicy) chặn cấu hình sai ngoài phạm vi PSA (file 8).
• [ ] Cloud Build provenance / SLSA sinh attestation tự động trong CI/CD (file 9).

Lớp xuyên suốt — Observability & posture

• [ ] Admin Activity audit log luôn bật (mặc định) — xác nhận đang chảy vào Cloud Logging.
• [ ] Data Access audit log bật có chọn lọc cho API nhạy cảm, kèm exclusion filter chống chi phí ngoài tầm kiểm soát.
• [ ] Export audit log sang sink bất biến (project/bucket tách biệt, retention lock) — ngoài tầm với của quyền vận hành thường nhật.
• [ ] GKE Security Posture bật (config scanning + workload vulnerability scanning); finding nghiêm trọng nối vào alerting qua Cloud Monitoring.
• [ ] Security bulletins theo dõi và phản ứng bằng upgrade kịp thời.
• [ ] Với tổ chức lớn: tích hợp finding vào Security Command Center, cân nhắc Container Threat Detection cho runtime threat.

Năm sai lầm thường gặp ở lớp quan sát

1. Bật Data Access log toàn diện một cách ngây thơ. Vì sao xảy ra: tưởng "log càng nhiều càng an toàn". Hệ quả: hàng trăm GB log/ngày từ thao tác đọc hệ thống, hóa đơn Cloud Logging tăng vọt, và nghịch lý là tín hiệu quan trọng chìm trong tiếng ồn. Phòng tránh: bật có chọn lọc theo service/loại thao tác, dùng exclusion filter loại SA hệ thống.

2. Để log forensics chung quyền với người vận hành cluster. Vì sao xảy ra: tiện, không tách project/sink. Hệ quả: kẻ tấn công chiếm quyền cao xóa luôn dấu vết, điều tra bất khả thi. Phòng tránh: export sang sink bất biến ở project tách biệt với IAM riêng và retention lock.

3. Coi dashboard Security Posture là "đã xong". Vì sao xảy ra: bật posture rồi không nối vào quy trình. Hệ quả: finding nghiêm trọng nằm im trong console, không ai xử lý — bảo mật trên giấy. Phòng tránh: nối finding nghiêm trọng vào alerting có người trực và SLA xử lý.

4. Chỉ quét image lúc build, bỏ quên workload đang chạy. Vì sao xảy ra: tin "image đã scan sạch lúc build là an toàn mãi mãi". Hệ quả: CVE mới công bố sau build không bao giờ được phát hiện trên Pod đang chạy. Phòng tránh: bật workload vulnerability scanning của Posture (runtime), không chỉ scan registry.

5. Hardening một lần rồi không quét drift. Vì sao xảy ra: coi hardening là sự kiện, không phải quá trình. Hệ quả: một thay đổi khẩn cấp nới lỏng cấu hình không bao giờ được phát hiện, cluster trôi khỏi chuẩn âm thầm. Phòng tránh: config scanning liên tục của Posture + audit RBAC định kỳ + checklist review theo lịch.

GCP-native implementation guidance

# Bật GKE Security Posture (config scanning + vulnerability scanning) trên cluster hiện có
gcloud container clusters update CLUSTER --region REGION \
  --security-posture=standard \
  --workload-vulnerability-scanning=standard

# Tạo log sink bất biến để export audit log sang bucket riêng (forensics chống giả mạo)
gcloud logging sinks create audit-archive \
  storage.googleapis.com/projects/SECURITY_PROJECT/buckets/audit-archive \
  --log-filter='logName=~"cloudaudit.googleapis.com" OR resource.type="k8s_cluster"'

# Truy vấn forensics: ai đã tạo privileged Pod trong 24h qua
gcloud logging read \
  'resource.type="k8s_cluster"
   protoPayload.methodName="io.k8s.core.v1.pods.create"
   protoPayload.request.spec.containers.securityContext.privileged=true' \
  --freshness=1d --format=json

# Truy vấn forensics: mọi thay đổi RBAC (nguồn leo thang đặc quyền)
gcloud logging read \
  'resource.type="k8s_cluster"
   protoPayload.methodName=~"rbac.authorization.k8s.io"' \
  --freshness=7d --limit=50

Để alert trên finding posture nghiêm trọng, tạo một log-based metric rồi gắn alerting policy của Cloud Monitoring vào đó:

# Đếm finding posture mức HIGH/CRITICAL làm cơ sở cho alert
gcloud logging metrics create posture-critical-findings \
  --description="GKE Security Posture findings nghiêm trọng" \
  --log-filter='logName=~"gkesecurityposture" AND
    jsonPayload.finding.severity=("HIGH" OR "CRITICAL")'

Operational implications

Lớp quan sát đảo ngược một giả định ngầm của chín file trước. Phòng ngừa hỏi "làm sao chặn"; quan sát hỏi "làm sao biết khi không chặn được" — và đây là sự trưởng thành phân biệt một cluster "được cấu hình bảo mật" với một hệ thống thực sự được vận hành an toàn. Hệ quả vận hành quan trọng nhất: bảo mật không phải trạng thái mà là vòng lặp. Bạn hardening (chín file trước), bạn quan sát drift và threat (file này), bạn phản ứng, rồi bạn siết lại chuẩn. Cluster nào dừng ở bước hardening mà không có vòng lặp quan sát sẽ trượt chuẩn trong vài tuần đầu vận hành mà không ai hay.

Hệ quả thứ hai gắn với chủ đề chi phí/giá trị xuyên suốt chương: quan sát có giá — về tiền (log storage, SCC tier) và về công sức (xử lý finding, điều tra). Quyết định kỹ thuật đúng không phải "log mọi thứ" hay "mua mọi tier" mà là đầu tư observability tương xứng với failure domain: Admin Activity (miễn phí) là sàn không thương lượng; Data Access bật có chọn lọc; Posture config scanning (miễn phí) nên luôn bật; SCC/Container Threat Detection xứng đáng khi quy mô và rủi ro đủ lớn. Cuối cùng, checklist hardening ở trên không phải để "tick một lần rồi quên" — nó là hợp đồng giữa platform team và mọi cluster lên production, được tái kiểm bằng chính các cơ chế quan sát mà file này mô tả. Đó là cách defense-in-depth chuyển từ một sơ đồ bảy lớp đẹp trên slide thành một thực hành kỹ thuật sống động, tự kiểm chứng theo thời gian.

References

• Cloud Audit Logs overview
• GKE audit logging
• Configure Data Access audit logs
• About GKE Security Posture dashboard
• Workload vulnerability scanning
• Security Command Center overview
• Container Threat Detection
• Harden cluster security (GKE checklist)
• GKE security bulletins