No matter how you like to participate in developer communities, Pulumi wants to meet you there. If you want to meet other Pulumi users to share use-cases and best practices, contribute code or documentation, see us at an event, or just tell a story about something cool you did with Pulumi, you are part of our community.

Pulumi Community

<@U03BBNY7KEX> that's coming from the `kubectl` configuration that gets created. When an EKS cluster is created, it also creates a kubeconfig and a provider.

I would export the `kubeconfig` from the EKS cluster and verify your AWS credentials have adequate access. The `roleMappings` are usually to blame

ah.. I had the key/secret configured in the stack config, but I realize now that kubectl won’t be using these.. I must also set the env vars for the key/secret - which makes the config vars redundant

you think it’s worth having the eks provider add the aws key/secret from the stack config to the environment? I don’t mind opening a PR with that

that's not really a practice we see all that often tbh. Most people configure the provider using AWS profiles or externally to Pulumi, or use IAM roles

right, so configuring AWS profiles is essentially the same as setting the env vars

this means I cannot rely solely on the pulumi stack config for credentials

the benefit of the pulumi stack config is the encrypted secrets, where as with env vars I don’t have that

understood, would be best to file an issue with your use case I think

<https://github.com/pulumi/pulumi-eks/issues/694> I hope this is clear enough