Consider external secret storage

Как проверяется

Метод проверки: Ручная проверка

Эту рекомендацию нельзя проверить автоматически. Сканирование выводит её вместе с этими инструкциями при указании флага --include-manual.

Review the EKS cluster’s secrets architecture and verify that required workloads use an external secrets store such as AWS Secrets Manager instead of relying only on native Kubernetes Secret objects. The audit should confirm both the integration path and the workload-level access model, because external secret storage in EKS typically depends on the AWS Secrets and Configuration Provider, the Secrets Store CSI Driver, and Pod-scoped IAM through EKS Pod Identity or IRSA.

Как исправляется

Метод исправления: Рекомендация или патч инфраструктуры

Move high-value application secrets out of native Kubernetes Secret objects and into an external store such as AWS Secrets Manager. Then update EKS workloads to retrieve those secrets through the AWS Secrets and Configuration Provider with the Secrets Store CSI Driver, using Pod-scoped IAM through EKS Pod Identity or IRSA. This shifts encryption, access control, rotation, and auditing to AWS instead of leaving those functions primarily in cluster-resident Secret objects. • Create the required secrets in AWS Secrets Manager and define workload access with least-privilege IAM policies. • Install and configure the AWS Secrets and Configuration Provider and the Secrets Store CSI Driver for EKS. • Update workload manifests to mount external secrets through a SecretProviderClass instead of reading only native Kubernetes Secret objects.