การจัดการ Secrets ใน Kubernetes 2026: External Secrets, Vault และคำถามสัมภาษณ์

การจัดการ secrets ใน Kubernetes ยังคงเป็นหนึ่งในความท้าทายด้านความปลอดภัยที่สำคัญที่สุดในการจัดการ container Native Kubernetes Secrets จัดเก็บข้อมูลที่เป็นความลับเป็นค่า base64-encoded ซึ่งไม่มีการเข้ารหัสโดยค่าเริ่มต้นและสร้างความเสี่ยงด้านความปลอดภัยที่มักถูกถามในกระบวนการสัมภาษณ์ DevOps

ทำไม Native Kubernetes Secrets ถึงไม่เพียงพอ

Resource Secret ในตัวจัดเก็บข้อมูลใน etcd ด้วย base64 encoding การเข้ารหัสนี้สามารถย้อนกลับได้ด้วยคำสั่งเดียว:

# decoding-secret.sh
# ถอดรหัสค่า Kubernetes secret ได้อย่างง่ายดาย
kubectl get secret db-credentials -o jsonpath='{.data.password}' | base64 -d

Base64 ไม่ใช่การเข้ารหัส ใครก็ตามที่มีสิทธิ์เข้าถึง cluster สามารถอ่านค่า secret ได้ เอกสาร Kubernetes เตือนอย่างชัดเจนว่า Secrets "ไม่ได้เข้ารหัสโดยค่าเริ่มต้น" และแนะนำให้เปิดใช้งานการเข้ารหัส at rest

ข้อจำกัดหลักสามประการที่ส่งผลกระทบต่อ deployment ใน production:

1. ไม่มี audit trail: Native Secrets ไม่มีการ logging ว่าใครเข้าถึงค่าใดและเมื่อใด
2. ไม่มีกลไกการหมุนเวียน: การเปลี่ยน secret ต้องการการแทรกแซงด้วยตนเองและ restart pod
3. ไม่เข้ากันกับ GitOps: การจัดเก็บ secrets ที่เข้ารหัสใน Git ยังคงเปิดเผยปัญหาการจัดการ encryption key

สถาปัตยกรรม External Secrets Operator

External Secrets Operator (ESO) เชื่อมต่อ Kubernetes กับระบบจัดการ secrets ภายนอก ถูกเปิดตัวเป็นโปรเจค CNCF Sandbox ในปี 2023 และเวอร์ชัน v0.10 ในปี 2026 ESO รองรับ AWS Secrets Manager, HashiCorp Vault, Google Secret Manager, Azure Key Vault และ backend อื่นๆ อีก 15 รายการ

สถาปัตยกรรมประกอบด้วย custom resources สามตัว:

# secret-store.yaml
# ClusterSecretStore กำหนดการเชื่อมต่อกับ Vault
apiVersion: external-secrets.io/v1beta1
kind: ClusterSecretStore
metadata:
  name: vault-backend
spec:
  provider:
    vault:
      server: "https://vault.internal:8200"
      path: "secret"
      version: "v2"
      auth:
        kubernetes:
          mountPath: "kubernetes"
          role: "external-secrets"
          serviceAccountRef:
            name: "external-secrets"
            namespace: "external-secrets"

ClusterSecretStore นี้กำหนดค่า ESO เพื่อยืนยันตัวตนกับ Vault โดยใช้ token ของ service account Kubernetes วิธี auth kubernetes ตรวจสอบ JWT ของ service account กับ TokenReview API ของ cluster

# external-secret.yaml
# ExternalSecret ดึงและซิงโครไนซ์ข้อมูล secret
apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: database-credentials
  namespace: production
spec:
  refreshInterval: 1h
  secretStoreRef:
    name: vault-backend
    kind: ClusterSecretStore
  target:
    name: db-credentials
    creationPolicy: Owner
  data:
    - secretKey: username
      remoteRef:
        key: secret/data/production/database
        property: username
    - secretKey: password
      remoteRef:
        key: secret/data/production/database
        property: password

ESO สร้าง native Kubernetes Secret จากข้อมูล Vault โดยอัปเดตอัตโนมัติตาม refreshInterval แอปพลิเคชันใช้ Secret มาตรฐานโดยไม่รู้แหล่งที่มา

การผสาน HashiCorp Vault กับ Kubernetes

HashiCorp Vault ให้การจัดการ secrets แบบรวมศูนย์พร้อมการเข้ารหัส การควบคุมการเข้าถึง และ audit logging การผสาน Vault กับ Kubernetes ต้องการการกำหนดค่าบนทั้งสองระบบ

เปิดใช้งาน Kubernetes Auth ใน Vault

# vault-k8s-auth.sh
# กำหนดค่าวิธียืนยันตัวตน Kubernetes ใน Vault
vault auth enable kubernetes

vault write auth/kubernetes/config \
    kubernetes_host="https://kubernetes.default.svc:443" \
    kubernetes_ca_cert=@/var/run/secrets/kubernetes.io/serviceaccount/ca.crt \
    token_reviewer_jwt=@/var/run/secrets/kubernetes.io/serviceaccount/token

การกำหนดค่านี้ช่วยให้ Vault ตรวจสอบ token ของ service account Kubernetes Cluster API server ตรวจสอบ token และส่งกลับตัวตนของ service account

สร้าง Vault Policy และ Role

# vault-policy.hcl
# Policy จำกัดการเข้าถึงเฉพาะ path ของ secrets
path "secret/data/production/*" {
  capabilities = ["read"]
}

path "secret/metadata/production/*" {
  capabilities = ["list"]
}

# create-vault-role.sh
# สร้าง role ที่เชื่อมกับ service account Kubernetes
vault policy write production-secrets vault-policy.hcl

vault write auth/kubernetes/role/external-secrets \
    bound_service_account_names=external-secrets \
    bound_service_account_namespaces=external-secrets \
    policies=production-secrets \
    ttl=1h

Role เชื่อม service account Kubernetes เฉพาะกับ Vault policies โดยใช้การเข้าถึงแบบ least-privilege

การหมุนเวียน Secret อัตโนมัติ

การหมุนเวียน secret ป้องกันการเปิดเผยระยะยาวของ credentials ที่ถูกบุกรุก ESO รองรับการหมุนเวียนอัตโนมัติผ่านการตั้งค่า refreshInterval แต่การหมุนเวียน database ต้องการการประสานงานเพิ่มเติม

# rotating-secret.yaml
# ExternalSecret ที่มี refresh interval สั้นสำหรับการหมุนเวียน
apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: rotating-api-key
  namespace: production
spec:
  refreshInterval: 15m
  secretStoreRef:
    name: vault-backend
    kind: ClusterSecretStore
  target:
    name: api-credentials
    creationPolicy: Owner
    template:
      type: Opaque
      metadata:
        annotations:
          reloader.stakater.com/match: "true"
  data:
    - secretKey: api-key
      remoteRef:
        key: secret/data/production/api
        property: current-key

Annotation Reloader กระตุ้น restart deployment เมื่อ secret เปลี่ยนแปลง ทำให้มั่นใจว่าแอปพลิเคชันรับ credentials ใหม่

Database Dynamic Secrets กับ Vault

# vault-database-config.sh
# กำหนดค่า dynamic secrets สำหรับ PostgreSQL
vault secrets enable database

vault write database/config/production-postgres \
    plugin_name=postgresql-database-plugin \
    allowed_roles="app-readonly,app-readwrite" \
    connection_url="postgresql://{{username}}:{{password}}@postgres.production:5432/app" \
    username="vault-admin" \
    password="vault-admin-password"

vault write database/roles/app-readonly \
    db_name=production-postgres \
    creation_statements="CREATE ROLE \"{{name}}\" WITH LOGIN PASSWORD '{{password}}' VALID UNTIL '{{expiration}}'; GRANT SELECT ON ALL TABLES IN SCHEMA public TO \"{{name}}\";" \
    default_ttl="1h" \
    max_ttl="24h"

Vault สร้าง credentials database ชั่วคราวตามความต้องการ โดยเพิกถอนอัตโนมัติหลังจาก TTL หมดอายุ

การใช้งาน Secrets แบบ Multi-Cluster

องค์กรที่รันหลาย cluster Kubernetes ต้องการการจัดการ secrets แบบรวมศูนย์ ESO รองรับการกำหนดค่า multi-tenant ด้วย namespaced SecretStores

# multi-cluster-setup.yaml
# SecretStore สำหรับแต่ละ cluster พร้อม isolation
apiVersion: external-secrets.io/v1beta1
kind: SecretStore
metadata:
  name: cluster-a-secrets
  namespace: team-alpha
spec:
  provider:
    vault:
      server: "https://vault.internal:8200"
      path: "secret"
      namespace: "cluster-a"
      auth:
        kubernetes:
          mountPath: "kubernetes-cluster-a"
          role: "team-alpha"

แต่ละ cluster ยืนยันตัวตนกับ Vault mount path ของตัวเอง ทำให้สามารถกำหนด policy แบบละเอียดสำหรับแต่ละสภาพแวดล้อม

คำถามสัมภาษณ์ DevOps ที่พบบ่อย

คำถามสัมภาษณ์เกี่ยวกับ secrets ใน Kubernetes ทดสอบความเข้าใจเชิงปฏิบัติเกี่ยวกับความปลอดภัยและการดำเนินงาน

คำถาม: จะรักษาความปลอดภัย Kubernetes Secrets at rest ได้อย่างไร?

เปิดใช้งานการเข้ารหัสในระดับ etcd โดยใช้ EncryptionConfiguration:

# encryption-config.yaml
# การกำหนดค่าการเข้ารหัสสำหรับ secrets ใน etcd
apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
  - resources:
      - secrets
    providers:
      - aescbc:
          keys:
            - name: key1
              secret: <BASE64_ENCODED_32_BYTE_KEY>
      - identity: {}

Provider aescbc เข้ารหัส secrets ก่อนเขียนลง etcd Provider identity อนุญาตให้อ่าน secrets ที่ไม่เข้ารหัสที่มีอยู่ระหว่างการ migration

คำถาม: ความแตกต่างระหว่าง SecretStore และ ClusterSecretStore คืออะไร?

SecretStore เป็น namespaced สามารถอ้างอิงได้โดย ExternalSecrets ใน namespace เดียวกันเท่านั้น ClusterSecretStore เป็น cluster-scoped สามารถเข้าถึงได้จาก namespace ใดก็ได้ ใช้ ClusterSecretStore สำหรับ shared secret backends และ SecretStore สำหรับการแยก tenant

คำถาม: จะจัดการการหมุนเวียน secrets โดยไม่มี downtime ได้อย่างไร?

ใช้การหมุนเวียนสามขั้นตอน:

1. Dual-write: เขียน credentials ใหม่ในขณะที่เก็บ credentials เก่า
2. Transition: อัปเดตแอปพลิเคชันให้ใช้ credentials ใหม่
3. Cleanup: ลบ credentials เก่าหลังจากแอปพลิเคชันทั้งหมด migrate แล้ว

# dual-credential-secret.yaml
# รองรับการหมุนเวียน dual-credential
apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: rotating-credentials
spec:
  refreshInterval: 5m
  secretStoreRef:
    name: vault-backend
    kind: ClusterSecretStore
  target:
    name: app-credentials
  data:
    - secretKey: current-password
      remoteRef:
        key: secret/data/app/credentials
        property: current
    - secretKey: previous-password
      remoteRef:
        key: secret/data/app/credentials
        property: previous

คำถาม: จะตรวจสอบการเข้าถึง secrets ใน Kubernetes ได้อย่างไร?

เปิดใช้งาน audit logging ใน API server ด้วย policy ที่จับการดำเนินการ secrets:

# audit-policy.yaml
# Audit policy สำหรับการดำเนินการ secrets
apiVersion: audit.k8s.io/v1
kind: Policy
rules:
  - level: RequestResponse
    resources:
      - group: ""
        resources: ["secrets"]
    verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]

Vault มี audit logging ในตัวที่บันทึกทุกการดำเนินการ secret พร้อม timestamp และตัวตน

การแก้ไขปัญหาที่พบบ่อย

ปัญหาการ deployment ESO มักเกิดจากข้อผิดพลาดในการยืนยันตัวตนหรือการกำหนดค่า

# debug-external-secret.sh
# ตรวจสอบสถานะการซิงโครไนซ์ ExternalSecret
kubectl get externalsecret -A

# ดู conditions โดยละเอียด
kubectl describe externalsecret database-credentials -n production

# ตรวจสอบ log ของ ESO controller
kubectl logs -n external-secrets -l app.kubernetes.io/name=external-secrets

ข้อผิดพลาดการยืนยันตัวตนที่พบบ่อย:

• Service account ไม่มีอยู่: ตรวจสอบให้แน่ใจว่า service account ที่อ้างอิงมีอยู่ใน namespace ESO
• Role binding ไม่ถูกต้อง: ตรวจสอบว่า role Vault เชื่อมกับ service account และ namespace ที่ถูกต้อง
• Cluster connectivity: ตรวจสอบว่า ESO สามารถเข้าถึง endpoint Vault ได้

แนวปฏิบัติที่ดีที่สุดด้านความปลอดภัย

ปฏิบัติตามแนวทางเหล่านี้สำหรับการ deployment secrets ใน production:

1. ไม่เคย commit secrets ลง Git: ใช้ ESO หรือ sealed-secrets สำหรับ GitOps workflows
2. ใช้ least privilege: ให้สิทธิ์เข้าถึงเฉพาะ secrets ที่จำเป็น
3. เปิดใช้งาน audit logging: ติดตามการเข้าถึง secrets ทั้งหมดสำหรับ compliance และ forensics
4. ใช้ TTL สั้น: Dynamic secrets พร้อม auto-expiration ลดผลกระทบของการรั่วไหล
5. เข้ารหัส etcd: เปิดใช้งานการเข้ารหัส at rest สำหรับ Kubernetes secrets
6. Network segmentation: จำกัดการเข้าถึง endpoints การจัดการ secret

สรุป

การจัดการ secrets ใน Kubernetes อย่างมีประสิทธิภาพต้องการมากกว่า native Secrets External Secrets Operator เชื่อมช่องว่างระหว่างแพลตฟอร์มจัดการ secret ระดับ enterprise และ Kubernetes workloads โดยให้การซิงโครไนซ์อัตโนมัติ การหมุนเวียน และความสามารถในการตรวจสอบ การเข้าใจสถาปัตยกรรมและขั้นตอนการดำเนินงานเหล่านี้เตรียมผู้สมัครสำหรับคำถามสัมภาษณ์ DevOps และสถานการณ์ production จริง การผสาน HashiCorp Vault กับ Kubernetes ผ่าน ESO สร้างโซลูชัน secrets ที่ปลอดภัยและปรับขนาดได้ที่ตรงตามมาตรฐานความสอดคล้องระดับ enterprise ในขณะที่รักษาความเร็วของนักพัฒนา