Configuration, identity, RBAC và admission security

Kubernetes security không nằm ở một object duy nhất. Config/Secret, workload identity, RBAC, Pod hardening, admission policy và tenant isolation phải tạo thành nhiều lớp bảo vệ; một namespace hoặc một Secret object riêng lẻ không tự tạo ra security boundary mạnh.

1. ConfigMap and Secret

ConfigMap dành cho cấu hình không nhạy cảm; Secret dành cho dữ liệu như password, token hoặc key. Secret là Kubernetes API object — không phải secret manager hoàn chỉnh. Giá trị Secret thường được biểu diễn bằng base64 nhưng base64 chỉ là encoding, không phải encryption; dữ liệu Secret trong etcd cần được cấu hình encryption at rest và quyền đọc phải được giới hạn bằng RBAC.

Config và Secret cần có version/ownership rõ ràng. Khi thay đổi cấu hình có ảnh hưởng behavior, dùng immutable artifact hoặc checksum/version annotation để rollout workload có kiểm soát thay vì hy vọng process tự nhận cấu hình mới.

• Không commit Secret plaintext vào source repository, image layer hoặc manifest history.
• Hạn chế get, đặc biệt list/watch trên Secrets; quyền tạo Pod/Deployment trong namespace cũng cần được xem xét vì có thể dẫn đến việc mount Secret của namespace đó.
• Tránh log secret, dump toàn bộ environment hoặc trả secret trong error payload.
• Thiết kế rotation: phát hành credential mới → workload nhận credential mới → verify → revoke credential cũ → audit.

2. Identity and RBAC

Workload thường gọi Kubernetes API bằng ServiceAccount. Không cần API access thì tắt automount token ở Pod hoặc ServiceAccount. Human identity và workload identity nên tách riêng để audit, rotation và blast radius rõ ràng.

RBAC gồm Role/ClusterRole mô tả quyền và RoleBinding/ClusterRoleBinding gán quyền cho subject. Least privilege phải xét đồng thời verbs, resources, API groups, namespace và phạm vi cluster.

# Ví dụ: workload không cần Kubernetes API token
apiVersion: v1
kind: ServiceAccount
metadata:
  name: web
  namespace: app
automountServiceAccountToken: false

Operational signals: theo dõi denied API requests tăng đột biến, creation/change của RoleBinding và ClusterRoleBinding, impersonation, Secret reads bất thường và workload dùng ServiceAccount ngoài ownership mong đợi. Sau incident hoặc credential exposure, revoke/rotate token, review bindings và đối chiếu audit log.

3. Pod security

SecurityContext giảm khả năng container chuyển từ application compromise thành node compromise. Với Linux workload thông thường, baseline hardening thường gồm chạy non-root với UID/GID cố định phù hợp ownership, không privilege escalation, filesystem root read-only khi khả thi, drop capabilities không cần thiết và dùng seccomp profile phù hợp.

securityContext:
  runAsNonRoot: true
  seccompProfile:
    type: RuntimeDefault
containers:
- name: app
  image: registry.example/app@sha256:...
  securityContext:
    allowPrivilegeEscalation: false
    readOnlyRootFilesystem: true
    capabilities:
      drop: ["ALL"]

Tránh hostPID, hostIPC, hostNetwork, privileged container, hostPath/socket mount và quyền truy cập host khác trừ workload hạ tầng đã được review. Các quyền này có thể làm mờ container boundary.

Kubernetes Pod Security Standards định nghĩa ba profile: Privileged, Baseline và Restricted. Built-in Pod Security Admission áp policy ở namespace level và hỗ trợ ba mode enforce, audit, warn; có thể pin policy version để upgrade cluster không bất ngờ thay đổi enforcement.

apiVersion: v1
kind: Namespace
metadata:
  name: payments
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/warn: restricted

4. Admission and supply chain

Admission chạy trên API write path sau authentication/authorization và trước khi object được persist. Đây là nơi phù hợp để enforce policy như image registry, digest/signature/provenance, resource requests/limits, security context và field invariants.

Nếu policy chỉ cần validation declarative, ưu tiên cơ chế in-process như ValidatingAdmissionPolicy khi phù hợp để giảm network dependency. Webhook vẫn hữu ích cho logic phức tạp nhưng trở thành dependency trực tiếp của API write availability.

5. Multi-tenancy

Namespace là organizational và policy scope quan trọng nhưng không phải hard isolation boundary một mình. Namespace multi-tenancy cần phối hợp RBAC + NetworkPolicy + ResourceQuota/LimitRange + Pod Security/admission + storage/runtime controls.

• Control-plane isolation: tenant chỉ được đọc/sửa object thuộc phạm vi cần thiết; tránh cluster-scoped permissions ngoài nhu cầu.
• Network isolation: default-deny và allow-list traffic cần thiết; nhớ rằng NetworkPolicy phụ thuộc CNI implementation.
• Resource isolation: quotas/limits ngăn một tenant tiêu thụ hết CPU, memory, object count hoặc storage.
• Runtime/node isolation: tenant không đáng tin cậy có thể cần node pool riêng, sandboxed runtime hoặc cluster riêng.
• Cloud boundary: chặn truy cập instance metadata / node credentials không cần thiết và dùng workload identity phù hợp cloud provider.

Nếu threat model có hostile tenants, yêu cầu kernel-level isolation hoặc compliance boundary độc lập, namespace sharing có thể không đủ. Khi đó separate cluster/node/runtime sandbox là lựa chọn cần đánh giá rõ về security guarantee và operational cost.

6. Production checklist và recovery