docs(aws): document access key env vars for AWS provider

[mjfxjas]

Summary

This PR documents AWS credential environment variable support that is currently functional but under-documented.

Changes

• Added explicit mention of:
  • AWS_ACCESS_KEY_ID
  • AWS_SECRET_ACCESS_KEY
  • AWS_SESSION_TOKEN (optional)
  • AWS_REGION / AWS_DEFAULT_REGION
• Added a short Kubernetes env snippet using a Secret.

Why

Issue #5265 reports this as missing from docs. This makes AWS auth paths clearer for users running external-dns in non-IRSA contexts.

Closes #5265

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign raffo for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: mjfxjas / name: Jonathan Schimpf (5264b23)

[k8s-ci-robot]

Welcome @mjfxjas!

It looks like this is your first PR to kubernetes-sigs/external-dns 🎉. Please refer to our pull request process documentation to help your PR have a smooth ride to approval.

You will be prompted by a bot to use commands during the review process. Do not be afraid to follow the prompts! It is okay to experiment. Here is the bot commands documentation.

You can also check if kubernetes-sigs/external-dns has its own contribution guidelines.

You may want to refer to our testing guide if you run into trouble with your tests not passing.

If you are having difficulty getting your pull request seen, please follow the recommended escalation practices. Also, for tips and tricks in the contribution process you may want to read the Kubernetes contributor cheat sheet. We want to make sure your contribution gets all the attention it needs!

Thank you, and welcome to Kubernetes. 😃

[k8s-ci-robot]

Hi @mjfxjas. Thanks for your PR.

I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[mjfxjas]

Thanks for the guidance. This is a docs-only change for AWS credential env var guidance.\n\nCould a maintainer please review and run ?

[mjfxjas]

Correction: could a maintainer please run /ok-to-test on this PR? Thanks!

[ivankatliarchuk]

Hi. Thanks for a pull request. I'm not sure if this is something I could recommend doing. Hence w8 for other revewers.

[mjfxjas]

Daily check-in (2026-02-19): docs change is ready from my side. EasyCLA is green; tide is still pending and the ok-to-test approvals show skipped. Is there any maintainer action I should take (or anything to adjust) to help this move forward?

[mjfxjas]

Thanks for the feedback. My intent is strictly to document currently supported AWS credential env vars (not to recommend any insecure flow). If you’d like, I can narrow wording further to emphasize standard provider behavior and avoid implying preferred auth patterns.

[mjfxjas]

Friendly follow-up. Checking if any additional changes are needed from my side.

CLA is green and I am happy to make wording or placement adjustments if maintainers prefer a different approach for documenting AWS env vars.

[ivankatliarchuk]

We are w8 for other reviewers, this has no ETA. The approach provided here is least secure. We potentially could add it to docs, but we need to provide best practice/recomendation in such case.

Current approach (this is missing, maybe worh adding)

env:
  - name: AWS_SHARED_CREDENTIALS_FILE
    value: /etc/aws/credentials/credentials
extraVolumes:
  - name: aws-credentials
    secret:
      secretName: external-dns
extraVolumeMounts:
  - name: aws-credentials
    mountPath: /etc/aws/credentials
    readOnly: true

In the proposed approach when secret is mounted in the way env.valueFrom.secretKeyRef

The secret is still visible to:

• kubectl describe pod
• Anyone who can exec into the container and run env
• Env vars can leak into logs, crash dumps, or child processes
• No way to make it visible to a specific user

For AWS specifically, best practice and recomended hierarchy:

• 1. IRSA (preferred): Map an AWS IAM role to a Kubernetes service account; no static credentials in the pod
• 2. EKS Pod Identity: Native EKS alternative to IRSA; associates IAM role with a service account via the Pod Identity Agent
• 3. Node IAM Role: Attach policy to the node instance profile; not recommended beyond tests because all pods on the node inherit the permissions. Tolerated, not recommended.
• 4. Mount credentials file. minimize privileges and avoid long-lived keys where possible
• 5. Environment variables. minimize privileges and avoid long-lived keys where possible

Env (5) vars vs mounted (4) files doesn’t really matter — they’re both:

• Long-lived
• Easy to leak
• Hard to rotate
• Easy to accidentally commit or log

When to use

• Limits usage to non-AWS clusters
• Minimal privileges still must have
• Acknowledges reality (sometimes you have to)

[ivankatliarchuk]

Asked AI to create table

Option	When to use	Security	Setup complexity	Blast radius	Notes
IRSA	Production clusters on Amazon EKS requiring least-privilege IAM access	Very high	Medium	Pod / ServiceAccount	Preferred approach; no static credentials; uses short-lived STS tokens
EKS Pod Identity	EKS clusters wanting simpler IAM integration than IRSA	Very high	Low–Medium	Pod / ServiceAccount	Newer EKS-native alternative; requires Pod Identity Agent
Node IAM Role	Dev, test, or single-tenant node setups	Low	Low	Node	All pods on the node share permissions; avoid in multi-tenant production
Static credentials (env vars or mounted files)	Non-AWS clusters or no IAM integration available	Very low	Low	Pod (credentials reusable elsewhere)	Last resort; use minimal privileges, short-lived keys, and frequent rotation

[mloiseleur]

@mjfxjas Do you think you can rework your PR to explain to the user the risk outlined by @ivankatliarchuk?