Mỗi cụm Kubernetes đều có một đối tượng Secret tích hợp sẵn. Có vẻ như an ninh. Nó có cảm giác như an ninh. Đó không phải là bảo mật.

Theo mặc định, Kubernetes Secret chỉ là một chuỗi được mã hóa base64 được lưu trữ trong etcd — bất kỳ ai có quyền truy cập cụm đều có thể đọc được và có thể giải mã được một cách đơn giản bằng một dòng: echo "c2VjcmV0" | cơ sở64 -d. Trừ khi bạn đã bật mã hóa một cách rõ ràng ở trạng thái nghỉ (và hầu hết các nhóm đều không bật), mật khẩu cơ sở dữ liệu, mã thông báo API và khóa riêng TLS của bạn sẽ không được mã hóa trong kho dữ liệu mặt phẳng điều khiển của cụm của bạn. Cam kết một bảng kê khai Kubernetes có chứa Bí mật cho Git và thông tin xác thực đó sẽ tồn tại mãi mãi trong lịch sử kho lưu trữ của bạn.

Đây là vấn đề mà một thế hệ công cụ quản lý bí mật mới đã ra đời để giải quyết — và vào năm 2026, hệ sinh thái đã trưởng thành đáng kể. Hướng dẫn này đề cập đến sáu công cụ quan trọng nhất để quản lý bí mật trong môi trường Kubernetes: những gì chúng làm, những gì chúng không làm và công cụ nào phù hợp với mức độ trưởng thành của nhóm bạn.

Bài đọc liên quan: Nếu bạn lo ngại về bí mật rò rỉ qua đường dẫn CI/CD của mình, hãy xem tổng hợp các công cụ đường ống CI/CD tốt nhất của chúng tôi. Để có bức tranh toàn cảnh hơn về bảo mật vùng chứa, hãy xem [hướng dẫn về công cụ quét lỗ hổng bảo mật](/posts/vulnerability-scanning-tools-devops-2026/ của chúng tôi).

Tại sao bí mật mặc định của Kubernetes lại thiếu

Trước khi đi sâu vào các công cụ, bạn nên tìm hiểu chính xác những gì Bí mật Kubernetes thiếu - bởi vì hiểu được lỗ hổng là điều cho phép bạn chọn giải pháp phù hợp.

Mặc định không mã hóa. etcd lưu trữ Bí mật Kubernetes dưới dạng base64, không được mã hóa. Kích hoạt Mã hóa khi lưu trữ là một bước cấu hình cấp cụm mà các nhà cung cấp Kubernetes (EKS, GKE, AKE) được quản lý sẽ xử lý theo cách khác nhau và nhiều cụm tự quản lý hoàn toàn bỏ qua bước này.

Không xoay vòng bí mật. Không có cơ chế tích hợp nào để Kubernetes Secret biết rằng thông tin xác thực hỗ trợ của nó đã thay đổi. Bạn xoay mật khẩu cơ sở dữ liệu ra bên ngoài và các nhóm của bạn tiếp tục sử dụng mật khẩu cũ cho đến khi bạn cập nhật Bí mật theo cách thủ công và khởi động lại các nhóm bị ảnh hưởng.

Không có nhật ký kiểm tra cho quyền truy cập bí mật. Bản ghi nhật ký kiểm tra Kubernetes tiêu chuẩn Sửa đổi đối tượng bí mật, nhưng hầu hết các cấu hình không ghi nhật ký các lần đọc riêng lẻ - nghĩa là bạn không thể trả lời “dịch vụ nào đã truy cập mã thông báo này và khi nào?”

Git có tính thù địch theo thiết kế. Lời khuyên tiêu chuẩn là “không bao giờ giao Bí mật cho Git.” Nhưng trong thế giới GitOps nơi mọi thứ đều dưới dạng mã là mục tiêu, đó là một ngoại lệ khó duy trì.

RBAC như một công cụ cùn. Kubernetes RBAC cho phép bạn cấp hoặc từ chối quyền truy cập vào các Đối tượng bí mật ở cấp không gian tên. Nó không thể diễn đạt “Dịch vụ A có thể đọc bí mật X nhưng không thể đọc bí mật Y” hoặc “Bí mật này sẽ hết hạn sau 24 giờ”.

Không có lý do nào trong số này là lý do để từ bỏ Kubernetes - chúng là lý do để sử dụng công cụ quản lý bí mật chuyên dụng.

TL;DR — So sánh tính năng

Dụng cụMã hóa ở phần còn lạiBí mật độngNhật ký kiểm traBản địa K8Nhiều đám mâyĐịnh giá
HashiCorp Vault✅✅✅⚠️ (thông qua đại lý)✅OSS miễn phí / HCP trả phí
Người điều hành bí mật bên ngoài✅ (thông qua phụ trợ)✅ (thông qua phụ trợ)✅ (thông qua phụ trợ)✅✅Miễn phí / OSS
Bí mật bị phong ấn✅❌❌✅❌Miễn phí / OSS
Trình quản lý bí mật AWS✅✅✅⚠️ (thông qua ESO/CSI)❌ (chỉ dành cho AWS)Định giá bí mật
Doppler✅❌✅✅ (người điều hành)✅Cấp độ miễn phí → trả phí
Vô hình✅✅✅✅ (người điều hành)✅OSS / đám mây trả phí

⚠️ = yêu cầu các thành phần bổ sung

1. HashiCorp Vault — Tiêu chuẩn vàng cho bí mật doanh nghiệp

HashiCorp Vault là chuẩn mực để đo lường mọi công cụ quản lý bí mật khác. Nó đã được thử nghiệm trong môi trường doanh nghiệp trong gần một thập kỷ và bộ tính năng của nó phản ánh chiều sâu đó.

Khả năng cốt lõi của Vault là bí mật động — thông tin xác thực được tạo theo yêu cầu và tự động hết hạn. Thay vì lưu trữ mật khẩu PostgreSQL tĩnh, Vault tạo một cặp tên người dùng/mật khẩu duy nhất cho mỗi dịch vụ yêu cầu, hợp lệ trong khoảng thời gian thuê có thể định cấu hình (ví dụ: một giờ). Khi hợp đồng thuê hết hạn, thông tin xác thực sẽ bị thu hồi. Điều này giúp loại bỏ toàn bộ các loại thông tin xác thực mở rộng và giúp việc ngăn chặn vi phạm trở nên dễ dàng hơn đáng kể.

Đối với Kubernetes, Vault Agent Injector hoặc Vault Secrets Operator là các đường dẫn tích hợp. Bộ tiêm chạy như một webhook đột biến tự động chuyển tác nhân Vault vào nhóm của bạn, tác nhân này sẽ xác thực với Vault bằng tài khoản dịch vụ Kubernetes của nhóm và ghi bí mật vào ổ đĩa chung trong bộ nhớ. Vault Secrets Operator (VSO), cách tiếp cận mới hơn, đồng bộ hóa các bí mật của Vault thành các đối tượng Kubernetes Secret gốc — quen thuộc hơn với các nhà khai thác, với cái giá phải trả là các bí mật tồn tại trong thời gian ngắn trong etcd.

Động cơ bí mật của Vault có phạm vi ấn tượng:

  • Thông tin xác thực cơ sở dữ liệu (PostgreSQL, MySQL, MongoDB, v.v.)
  • Thông tin xác thực động AWS, GCP, Azure
  • Tạo chứng chỉ PKI và TLS
  • Ký chứng chỉ SSH
  • Mã thông báo tài khoản dịch vụ Kubernetes

Những gì Vault làm tốt: Thông tin xác thực động, chính sách truy cập chi tiết, nhật ký kiểm tra toàn diện và hệ sinh thái plugin hoàn thiện. Nếu bạn cần quản lý bí mật ở cấp độ tuân thủ với đầy đủ thông tin về ai truy cập vào thời điểm nào thì Vault thường là lựa chọn hợp lý duy nhất.

Những điều cần chú ý: Vault có hoạt động phức tạp. Việc chạy nó ở chế độ sẵn sàng cao đòi hỏi phải chú ý cẩn thận đến các phần phụ trợ lưu trữ (Raft hiện là lựa chọn được đề xuất), quy trình hủy niêm phong và đường dẫn nâng cấp. Đường cong học tập là có thật. Ngân sách dành cho thời gian kỹ thuật nền tảng.

Giá cả: Phiên bản nguồn mở miễn phí và đáp ứng hầu hết các nhu cầu. HashiCorp Cloud Platform (HCP) Vault là sản phẩm được quản lý với mức giá dựa trên số giờ hoạt động bí mật của cụm. Thay đổi giấy phép BSL từ năm 2023 đã dẫn đến phân nhánh OpenTofu cho Terraform, nhưng phân nhánh tương đương của Vault (OpenBao) vẫn đang hoàn thiện.

📚 Nên đọc: Hacking Kubernetes của Andrew Martin và Michael Hausenblas — đưa tin tuyệt vời về các bề mặt tấn công Kubernetes bao gồm các kịch bản tấn công bí mật.

2. Toán tử bí mật bên ngoài (ESO) — Lớp tích hợp gốc K8s

External Secrets Operator có quan điểm kiến ​​trúc khác về cơ bản: thay vì là một kho lưu trữ bí mật, nó là cầu nối giữa Kubernetes và bất kỳ kho lưu trữ bên ngoài nào mà bạn đã có. ESO đồng bộ hóa các bí mật từ AWS Secrets Manager, GCP Secret Manager, Azure Key Vault, HashiCorp Vault, 1Password, Doppler và danh sách ngày càng tăng các chương trình phụ trợ khác vào các đối tượng Kubernetes Secret gốc.

Sự trừu tượng hóa cốt lõi là tài nguyên tùy chỉnh ExternalSecret:

apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: database-credentials
spec:
  refreshInterval: 1h
  secretStoreRef:
    name: aws-secrets-manager
    kind: ClusterSecretStore
  target:
    name: db-creds
  data:
    - secretKey: password
      remoteRef:
        key: production/db/password

ESO theo dõi tài nguyên này, tìm nạp bí mật từ AWS Secrets Manager (hoặc bất cứ nơi nào) và tạo Bí mật Kubernetes tiêu chuẩn. Ứng dụng của bạn đọc db-creds giống như mọi Bí mật Kubernetes khác — không cần thay đổi mã. Khi dấu tích refreshInterval, ESO sẽ tự động tìm nạp lại và cập nhật Bí mật.

Tại sao ESO lại phổ biến vào năm 2026: Nó hoạt động tốt với các khoản đầu tư hiện có. Tổ chức của bạn đã có AWS Secrets Manager (hoặc Vault hoặc GCP Secret Manager) — ESO chỉ làm cho những bí mật đó có thể sử dụng được trong Kubernetes mà không cần thay đổi mã ứng dụng hoặc quy trình luân chuyển bí mật hiện có của bạn.

ESO hay Vault Secrets Operator? Nếu bạn đang chạy Vault, VSO có khả năng tích hợp dành riêng cho Vault chặt chẽ hơn (Bí mật động của Vault, Vault PKI). Nếu bạn đang sử dụng kho lưu trữ bí mật riêng của nhà cung cấp dịch vụ đám mây thì ESO là lựa chọn hợp lý hơn. Nhiều nhóm chạy cả hai — ESO cho các bí mật tĩnh được lưu trữ trên đám mây, VSO cho thông tin xác thực động do Vault quản lý.

Giá cả: ESO là nguồn mở và miễn phí (Apache 2.0), được duy trì bởi dự án hộp cát CNCF với sự hỗ trợ mạnh mẽ của cộng đồng.

3. Bí mật được niêm phong — Bí mật được mã hóa thân thiện với GitOps

Bí mật bị niêm phong của Bitnami giải quyết một vấn đề cụ thể: làm cách nào để bạn lưu trữ các bảng kê khai Kubernetes Secret trong Git mà không lưu trữ bản rõ thực tế? Câu trả lời là mã hóa bất đối xứng.

Bộ điều khiển Bí mật kín chạy trong cụm của bạn và giữ khóa riêng. kubeseal CLI mã hóa bảng kê khai Kubernetes Secret bằng khóa chung của cụm, tạo ra CRD SealedSecret. Tệp kê khai được mã hóa này có thể được cam kết với Git một cách an toàn — chỉ khóa riêng của cụm mới có thể giải mã nó và nó chỉ có thể được giải mã trong cụm cụ thể đó (theo mặc định, văn bản mã hóa được liên kết với không gian tên + tên).

# Encrypt a secret for Git storage
kubectl create secret generic db-creds \
  --from-literal=password=s3cr3t \
  --dry-run=client -o yaml | \
  kubeseal --format=yaml > db-creds-sealed.yaml

# This file is safe to commit
git add db-creds-sealed.yaml

Khi bạn áp dụng SealedSecret cho cụm, bộ điều khiển sẽ giải mã nó và tạo đối tượng Secret tương ứng.

Những gì Bí mật kín làm tốt: Quy trình làm việc của GitOps. Nếu bạn đang sử dụng Argo CD hoặc Flux và muốn mọi tài nguyên cụm (bao gồm cả bí mật) được lưu trữ khai báo trong Git thì Bí mật kín hoàn toàn phù hợp với mô hình đó. Nó không yêu cầu sự phụ thuộc bên ngoài nào ngoài bộ điều khiển trong cụm.

Những gì nó không làm: Xoay vòng, thông tin xác thực động hoặc ghi nhật ký kiểm tra ngoài các sự kiện Kubernetes tiêu chuẩn. Bí mật kín là giải pháp lưu trữ Git, không phải là nền tảng quản lý bí mật đầy đủ. Nếu mật khẩu của bạn thay đổi, bạn mã hóa lại và xác nhận lại.

Sao lưu khóa riêng là rất quan trọng. Nếu bạn mất khóa riêng của bộ điều khiển, bạn sẽ mất khả năng giải mã các bí mật đã được niêm phong của mình. Sao lưu bí mật sealed-secrets-key ở một vị trí riêng biệt, an toàn.

Giá cả: Hoàn toàn miễn phí và mã nguồn mở (Apache 2.0).

4. AWS Secrets Manager với Kubernetes

Nếu khối lượng công việc của bạn chạy chủ yếu trên EKS (hoặc kết nối nhiều với các dịch vụ AWS), AWS Secrets Manager được ghép nối với Secrets Store CSI Driver hoặc Bên ngoài Secrets Operator là phù hợp. Bạn giữ bí mật trong kho lưu trữ được quản lý, mã hóa, ghi nhật ký kiểm tra của AWS và đưa chúng vào Kubernetes khi cần.

Trình điều khiển CSI của Cửa hàng Bí mật (SSCSID) là phương pháp được CNCF duy trì: các bí mật được gắn trực tiếp vào các nhóm dưới dạng tệp thông qua ổ đĩa CSI, không bao giờ được ghi vào etcd dưới dạng đối tượng Bí mật của Kubernetes. Đây là con đường có mức độ bảo mật cao nhất — bí mật tồn tại trong bộ nhớ nhóm nhưng không có trong kho Kubernetes Secret.

volumes:
  - name: secrets-store
    csi:
      driver: secrets-store.csi.k8s.io
      readOnly: true
      volumeAttributes:
        secretProviderClass: aws-secrets

Các khả năng gốc của AWS Secrets Manager bao gồm xoay vòng tự động cho các dịch vụ được hỗ trợ (RDS, Redshift, DocumentDB và thông qua Lambda để xoay vòng tùy chỉnh), truy cập nhiều tài khoản và tích hợp sâu CloudTrail cho các quy trình kiểm tra tuân thủ.

Cân nhắc chi phí: AWS Secrets Manager tính phí cho mỗi bí mật mỗi tháng và mỗi lệnh gọi API. Đối với những đội tàu lớn có nhiều bí mật nhỏ, chi phí có thể tăng lên. Xem hướng dẫn tối ưu hóa chi phí đám mây của chúng tôi để biết các chiến lược quản lý chi tiêu AWS liên quan đến bí mật.

Tốt nhất cho: Các nhóm gốc EKS đã đầu tư vào hệ sinh thái AWS muốn tích hợp chặt chẽ IAM và luân chuyển thông tin xác thực RDS gốc.

5. Doppler — Nền tảng bí mật SaaS đầu tiên dành cho nhà phát triển

Doppler sử dụng phương pháp tiếp cận SaaS ưu tiên trải nghiệm của nhà phát triển hơn là độ phức tạp trong vận hành. Bạn xác định các bí mật trong giao diện người dùng của Doppler (hoặc thông qua CLI/API), sắp xếp chúng theo môi trường (nhà phát triển, dàn dựng, sản xuất) và toán tử Doppler Kubernetes tự động đồng bộ hóa chúng vào Kubernetes Secrets.

Người vận hành thăm dò Doppler để tìm các thay đổi và cập nhật Bí mật Kubernetes tương ứng, tùy ý kích hoạt khởi động lại nhóm khi bí mật thay đổi. Thiết lập là một cài đặt biểu đồ Helm duy nhất:

helm repo add doppler https://helm.doppler.com
helm install --generate-name doppler/doppler-kubernetes-operator

Nơi Doppler tỏa sáng: Phát triển cục bộ và tích hợp CI/CD cùng với Kubernetes. Doppler CLI thay thế hoàn toàn các tệp môi trường (doppler run -- your-command), đưa ra các bí mật giống nhau trên các môi trường cục bộ, CI và sản xuất. Đối với đường dẫn CI/CD, khả năng tích hợp gốc của Doppler với GitHub Actions, CircleCI và các tính năng khác giúp loại bỏ nhu cầu sao chép bí mật vào các biến môi trường đường ống.

Những gì Doppler không bao gồm: Thông tin xác thực cơ sở dữ liệu động. Doppler là một kho lưu trữ bí mật tĩnh có lịch sử phiên bản và ghi nhật ký kiểm tra — đây không phải là công cụ tạo bí mật như Vault.

Giá cả: Doppler cung cấp cấp độ miễn phí cho các nhóm nhỏ. Gói trả phí bổ sung SSO, yêu cầu truy cập và tính năng tuân thủ. Kiểm tra trang định giá của Doppler để biết các cấp độ hiện tại (thay đổi về giá; xác minh trước khi lập ngân sách).

6. Infisical — Giải pháp thay thế Vault nguồn mở

Infisical là đối thủ mã nguồn mở mạnh nhất đối với sự độc quyền của Vault/Doppler. Nó cung cấp giao diện người dùng web, CLI, SDK và toán tử Kubernetes - có thể tự triển khai hoặc sử dụng dưới dạng dịch vụ đám mây.

Infisical đã bổ sung hỗ trợ bí mật động vào năm 2024, nhắm mục tiêu tạo thông tin xác thực cơ sở dữ liệu tương tự như công cụ bí mật cơ sở dữ liệu của Vault. Toán tử Infisical Kubernetes đồng bộ hóa CRD InfisicalSecret với Kubernetes Secrets gốc, với các khoảng thời gian làm mới có thể định cấu hình.

Đối với các nhóm muốn UX cấp SaaS (bảng điều khiển web, quy trình yêu cầu truy cập, nhật ký kiểm tra) nhưng không thể sử dụng SaaS bên ngoài do yêu cầu tuân thủ, tính năng tự lưu trữ của Infisical rất hấp dẫn. Nó dễ vận hành hơn đáng kể so với Vault và có trải nghiệm làm quen thân thiện với nhà phát triển hơn.

Giá cả: Lõi nguồn mở là miễn phí. Phiên bản được lưu trữ trên đám mây có gói miễn phí và gói trả phí cho các tính năng nâng cao. Giấy phép doanh nghiệp tự lưu trữ có sẵn cho các môi trường tuân thủ nghiêm ngặt.

📚 Để tìm hiểu sâu hơn về kiến ​​trúc bảo mật Kubernetes: Kubernetes Security and Observability trên Amazon bao gồm các bí mật, RBAC, chính sách mạng và bảo mật thời gian chạy trong một khuôn khổ gắn kết.

Mẹo triển khai

Bắt đầu với mã hóa ở trạng thái lưu trữ. Trước khi thêm bất kỳ công cụ bổ sung nào, hãy bật mã hóa Kubernetes etcd ở trạng thái lưu trữ. Đối với các cụm được quản lý, đây thường là một hộp kiểm duy nhất. Đối với các cụm tự quản lý, hãy làm theo hướng dẫn chính thức. Điều này ngay lập tức nâng cao tình trạng bảo mật cơ bản của bạn.

Áp dụng RBAC có đặc quyền tối thiểu cho Bí mật. Kiểm tra tài khoản dịch vụ nào có quyền get, list hoặc watch trên các đối tượng Bí mật. Các tài khoản dịch vụ mặc định trong nhiều biểu đồ Helm được cung cấp quá mức. Siết chặt RBAC trước khi chuyển sang kho lưu trữ bên ngoài.

Lên kế hoạch sớm cho các quy ước đặt tên bí mật của bạn. Bí mật sinh sôi nảy nở nhanh chóng. Hệ thống phân cấp nhất quán ({env}/{service}/{credential-type}) giúp tự động hóa, chính sách RBAC và quy trình luân chuyển đơn giản hơn đáng kể trên tất cả các công cụ.

Đừng bỏ qua thử nghiệm xoay bí mật. Cho dù bạn chọn công cụ nào, hãy chạy khoan xoay trước khi bạn cần. Xác minh rằng ứng dụng của bạn nhận được thông tin xác thực mới mà không có thời gian ngừng hoạt động. Bí mật động với Vault hoặc ESO giúp việc này dễ dàng hơn đáng kể so với bí mật tĩnh được cập nhật thủ công.

Theo dõi sự phát tán bí mật. Khi nền tảng của bạn phát triển, bí mật sẽ tích lũy. Tích hợp báo cáo quản lý bí mật vào bảng thông tin kỹ thuật nền tảng của bạn. Xem hướng dẫn về công cụ giám sát Kubernetes của chúng tôi để biết công cụ quan sát có thể theo dõi các mẫu truy cập bí mật.

Công cụ nào dành cho đội nào?

Nhóm nhỏ, dựa trên nền tảng đám mây (AWS/GCP/Azure): Bắt đầu với Người vận hành bí mật bên ngoài kết nối với kho bí mật gốc của nhà cung cấp đám mây của bạn. Chi phí hoạt động tối thiểu, tích hợp kiểm toán vững chắc, miễn phí.

Nhóm GitOps-first (Argo CD / Flux): Bí mật được niêm phong cho cấu hình được lưu trữ trên GitOps, kết hợp với ESO để có thông tin xác thực thời gian chạy nhạy cảm thậm chí không được mã hóa trong Git.

Doanh nghiệp có yêu cầu tuân thủ (SOC 2, PCI, HIPAA): HashiCorp Vault — cụm Raft tự lưu trữ hoặc HCP Vault được quản lý. Nhật ký kiểm tra, thông tin xác thực động và công cụ chính sách chi tiết khó có thể sao chép ở nơi khác.

Môi trường hỗn hợp, tập trung vào trải nghiệm của nhà phát triển (K8s + local + CI/CD): Doppler cho DX hợp nhất trên các môi trường hoặc Infisical tự lưu trữ nếu nơi lưu trữ dữ liệu có vấn đề.

Nhóm nền tảng lớn quản lý môi trường nhiều cụm: Người vận hành bí mật bên ngoài đóng vai trò là lớp trừu tượng phía K8, được hỗ trợ bởi Vault hoặc cửa hàng gốc trên nền tảng đám mây. Tập trung nguồn thông tin chính xác vào một cửa hàng trong khi sử dụng ESO làm bộ chuyển đổi chung giữa các cụm là một mô hình đã được chứng minh rõ ràng vào năm 2026.

Liên quan: Để biết các rủi ro bảo mật do công cụ mã hóa AI gây ra trong bảng kê khai Kubernetes và quy trình CI/CD, hãy xem hướng dẫn của chúng tôi về rủi ro bảo mật mã hóa Vibe vào năm 2026.

##Câu hỏi thường gặp

Bí mật Kubernetes có được mã hóa theo mặc định không?

Không. Bí mật Kubernetes được mã hóa base64 theo mặc định — mã hóa chứ không phải mã hóa. Dữ liệu được lưu trữ trong etcd mà không cần mã hóa trừ khi bạn bật Mã hóa ở phần còn lại một cách rõ ràng. Luôn xác minh cấu hình cụm của bạn và xem xét công cụ quản lý bí mật bên ngoài cho khối lượng công việc sản xuất.

Sự khác biệt giữa Bí mật được niêm phong và Người vận hành Bí mật bên ngoài là gì?

Bí mật bị niêm phong mã hóa các bản kê khai Bí mật để lưu trữ Git an toàn — đó là giải pháp GitOps. Người vận hành bí mật bên ngoài tìm nạp bí mật trực tiếp từ các cửa hàng bên ngoài (Vault, AWS Secrets Manager, v.v.) và tạo Bí mật Kubernetes gốc từ chúng. Chúng giải quyết các vấn đề khác nhau và thường được sử dụng cùng nhau.

Bí mật động là gì và tại sao chúng lại quan trọng?

Bí mật động là thông tin xác thực được tạo theo yêu cầu và tự động hết hạn — thay vì mật khẩu tĩnh được lưu trữ vô thời hạn. HashiCorp Vault là nguồn bí mật động chính của Kubernetes. Nếu thông tin xác thực động bị xâm phạm, thông tin đó sẽ hết hạn theo lịch trình riêng. Điều này hạn chế đáng kể bán kính vụ nổ vi phạm so với các bí mật tĩnh tồn tại lâu dài.

Tôi nên sử dụng Doppler hay HashiCorp Vault cho Kubernetes?

Doppler thắng nhờ trải nghiệm của nhà phát triển và khả năng áp dụng nhanh chóng. Vault giành chiến thắng nhờ sự tuân thủ của doanh nghiệp — thông tin xác thực động, nhật ký kiểm tra chi tiết và chính sách chi tiết. Đối với các nhóm quy mô vừa và nhỏ, Doppler thường là con đường nhanh hơn. Đối với môi trường SOC 2, PCI DSS hoặc HIPAA, Vault thường là lựa chọn có khả năng phòng thủ cao hơn.

Làm cách nào để ngăn bí mật rò rỉ vào nhật ký vùng chứa?

Gắn các bí mật dưới dạng tệp thay vì biến môi trường (các biến môi trường có thể được hiển thị thông qua /proc và các điểm cuối gỡ lỗi). Sử dụng Trình điều khiển CSI của Secrets Store để bỏ qua hoàn toàn etcd. Quét các cam kết bí mật vô tình trong quy trình CI/CD của bạn bằng các công cụ như trình quét bí mật của Trivy — xem hướng dẫn về công cụ quét lỗ hổng của chúng tôi để biết chi tiết thiết lập.

Công cụ quản lý bí mật tốt nhất cho nhóm Kubernetes nhỏ là gì?

Bắt đầu với Toán tử bí mật bên ngoài được hỗ trợ bởi kho bí mật gốc của nhà cung cấp đám mây của bạn. Chi phí hoạt động tối thiểu, ghi nhật ký kiểm tra chắc chắn, miễn phí. Thêm bậc miễn phí của Doppler nếu bạn cũng muốn có trải nghiệm bí mật nhà phát triển/CI/sản xuất thống nhất.

Làm cách nào để tích hợp AWS Secrets Manager với Kubernetes?

Sử dụng Toán tử bí mật bên ngoài với ClusterSecretStore trỏ vào AWS Secrets Manager. Trên EKS, sử dụng IRSA (Vai trò IAM dành cho tài khoản dịch vụ) để xác thực IAM cấp nhóm — không cần thông tin xác thực tĩnh. Trên các cụm không phải EKS, hãy sử dụng người dùng IAM với secretmanager:GetSecretValue trong phạm vi ARN bí mật cụ thể của bạn.