如何从EKS/KOPS集群的Pod访问AWS与DynamoDB？Helm配置咨询

Hey there! Let's walk through your questions clearly, since they're focused on secure AWS service access from Kubernetes pods—a common scenario for cloud-native workloads.

The recommended, production-grade method for both EKS and KOPS-managed clusters is using IAM Roles for Service Accounts (IRSA). This lets you assign granular, pod-specific IAM permissions instead of giving broad access to all pods on a node. Here's the core workflow:

• Create an IAM role in AWS with exactly the permissions your pod needs (e.g., DynamoDB write access). This role must be configured to trust your cluster's OIDC identity provider.
• Link the IAM role to a Kubernetes ServiceAccount using an annotation (for EKS, it's eks.amazonaws.com/role-arn: arn:aws:iam::YOUR_ACCOUNT_ID:role/YOUR_ROLE_NAME; KOPS uses a similar annotation or cluster-level IAM mappings).
• Configure your pod to use this ServiceAccount. The AWS SDKs in your pod will automatically fetch temporary, short-lived credentials from the Kubernetes metadata service—no hardcoded API keys required.

There's an older, less secure alternative: relying on the node's IAM role. If your cluster nodes have an IAM role with the required AWS permissions, pods will inherit that access by default. But this is risky because every pod on the node gets the same permissions—never use this for production workloads.

Accessing DynamoDB Specifically #

For your DynamoDB use case, you'll follow the IRSA workflow above, but with a tailored IAM policy:

• Create an IAM policy that allows only the actions your pod needs (e.g., dynamodb:PutItem, dynamodb:GetItem) on your target DynamoDB table. Follow the principle of least privilege here—don't use overly broad policies like AmazonDynamoDBFullAccess unless absolutely necessary.
• Attach this policy to the IAM role you create for your ServiceAccount.

Can Helm Handle All Configuration Without Cluster-Level Changes? #

This depends on your cluster's existing setup:

• If your cluster already has an OIDC provider configured (EKS enables this by default; KOPS clusters can have it set up during cluster creation or post-deployment):
  Yes, Helm can handle the pod-level configuration entirely. You can define the ServiceAccount with the IAM role annotation directly in your Helm chart, then reference that ServiceAccount in your pod template. Example snippets:

  # In your Helm chart's templates/serviceaccount.yaml
  apiVersion: v1
  kind: ServiceAccount
  metadata:
    name: {{ .Values.serviceAccount.name }}
    annotations:
      eks.amazonaws.com/role-arn: {{ .Values.aws.iamRoleArn }}
  

  Then in your pod spec:

  serviceAccountName: {{ .Values.serviceAccount.name }}
  

  Note: You still need to create the IAM role and policy in AWS first—Helm can't create AWS IAM resources on its own. But once those exist, Helm can link everything up for your pod seamlessly.

• If your cluster doesn't have an OIDC provider:
  You'll need to configure the OIDC provider at the cluster level first (for EKS, use eksctl utils associate-iam-oidc-provider; for KOPS, update your cluster spec and apply it). This is a one-time cluster operation that Helm can't perform.

Avoid the insecure alternative of injecting AWS access keys as Kubernetes Secrets via Helm—while technically possible, storing or hardcoding keys exposes you to credential leakage risks. Stick with IRSA for production.

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