部署K8s应用时无法创建secretObjects并关联AWS SSM参数的问题求助

Let's dig into why your dbsecret isn't being created and fix that deployment error. The core issue here is that the secretObjects defined in your SecretProviderClass aren't being synced to a Kubernetes Secret as expected. Here are the key checks and fixes to apply:

1. Make sure the Secrets Store CSI Driver and AWS Provider are properly deployed #

The Secret Store CSI Driver doesn't handle AWS secrets out of the box—you need the AWS Provider add-on, and you must have the secret sync feature enabled for the driver.

• Verify the AWS Provider is running:

  kubectl get pods -n kube-system | grep secrets-store-csi-driver-provider-aws
  

  If you get no results, install it first:

  kubectl apply -f https://raw.githubusercontent.com/aws/secrets-store-csi-driver-provider-aws/main/deployment/aws-provider-installer.yaml
  

• Check if secret sync is enabled on the CSI Driver:
  Look for the --enable-secret-sync flag in the driver's daemonset:

  kubectl get ds secrets-store-csi-driver -n kube-system -o yaml | grep enable-secret-sync
  

  If it's missing, you'll need to update the daemonset to add this flag (or redeploy the driver with sync enabled).

2. Validate your SecretProviderClass configuration #

A few details in your SSM parameter setup could be breaking the sync:

• The objectName: "secure-store" must match the exact name of an existing JSON-formatted SSM Parameter in your account. For example, the parameter's value should look like {"username":"my-db-user","password":"my-db-pass"}—since you're using jmesPath to extract fields from it.
• Double-check your jmesPath entries: They look correct, but ensure the JSON in your SSM parameter actually has username and password keys.

Also, confirm the SecretProviderClass itself was created successfully:

kubectl get secretproviderclass aws-secrets -n default

3. Confirm your ServiceAccount has the right IAM permissions #

The test-oidc role linked to your csi-provider-user ServiceAccount needs explicit permissions to access the secure-store SSM parameter. Make sure its attached policy includes:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ssm:GetParameter",
        "ssm:GetParameters"
      ],
      "Resource": "arn:aws:ssm:<your-region>:123456789078:parameter/secure-store"
    }
  ]
}

Don't forget to verify the role's trust policy allows your EKS OIDC provider to assume it for the default:csi-provider-user ServiceAccount.

4. Check CSI Driver logs for sync errors #

When your pod starts, the CSI Driver attempts to pull the SSM parameter and create the secret. Logs will tell you exactly where it's failing:

• Find the running CSI Driver pods:

  kubectl get pods -n kube-system -l app=secrets-store-csi-driver
  

• View logs for the driver (search for aws-secrets or dbsecret):

  kubectl logs <csi-driver-pod-name> -n kube-system
  

• Also check the AWS Provider pod logs for AWS-specific errors:

  kubectl logs <aws-provider-pod-name> -n kube-system
  

  Common issues here: permission denied, missing SSM parameter, or invalid JSON in the parameter.

5. Force a sync by restarting the pod #

If all configs look correct but the secret still isn't there, delete your existing pod to trigger a fresh sync attempt:

kubectl delete pod -l app=new-app

When the new pod spins up, the CSI Driver will retry fetching the SSM parameter and creating dbsecret.

Most of the time, this error boils down to missing the AWS Provider, disabled secret sync, insufficient IAM permissions, or a mismatched SSM parameter name/format. Work through these checks and you'll get that deployment up and running.

内容的提问来源于stack exchange，提问作者Dev Jiro