Do not set AWS_PROFILE env in generated kubeconfig

[rquitales]

Proposed changes

AWS_PROFILE values can vary between users despite variations providing the same level of access to the AWS resources. Always setting the profile name in the kubeconfig will mean that other users of the Pulumi program will need to ensure that their profile names also match, which isn't ideal.

This change would enable users to switch profiles, without needing to regenerate a Kubeconfig as the underlying eks get-token command will use the ambient AWS_PROFILE env var to determine the best profile.

I have manually validated that this change works locally by explicitly specifying a custom profile on the first pulumi up, changing the profile to another name and creating an on cluster deployment to see if the generated kubeconfig can handle the profile name change.

Related issues (optional)

Fixes: #868

[github-actions]

Does the PR have any schema changes?

Looking good! No breaking changes found.
No new resources/functions.

[github-actions]

Does the PR have any schema changes?

Looking good! No breaking changes found.
No new resources/functions.

[github-actions]

Does the PR have any schema changes?

Looking good! No breaking changes found.
No new resources/functions.

[github-actions]

Does the PR have any schema changes?

Looking good! No breaking changes found.
No new resources/functions.

[github-actions]

Does the PR have any schema changes?

Looking good! No breaking changes found.
No new resources/functions.

[github-actions]

Does the PR have any schema changes?

Looking good! No breaking changes found.
No new resources/functions.

[thomas11]

Sadly, the upgrade tests are failing again due to a new AMI id :(

[github-actions]

Does the PR have any schema changes?

Looking good! No breaking changes found.
No new resources/functions.

[fernandocarletti]

Hello! Just a suggestion for the future. This is a breaking change, since it does not offer backward compatibility with the old behavior (I know this the hard way :), it sounds this should be released as 3.0 instead as 2.3, since minor versions should keep backward compatibility.

I'm assuming Pulumi does use semver, based on this, which made me overlook it before merging the dependabot PR (and yes, I know I should have checked the changelog more careful, there's a caution note there, that's why it is a friendly suggestion and not a rant hahaha).

[gunzy83]

This absolutely is a breaking change. Took me a while to track down how to deal with this on upgrade (given I am already applying transformations to overcome deficiencies).

To me it makes little sense that you can create the cluster with an AWS profile like this:

providerCredentialOpts: {
  profileName: awsProfile,
},

The profile is saved into the Kubeconfig for the initial deploy of the cluster resources, but then immediately creates a provider (${name}-provider) inside the Cluster resource without the profile included in its Kubeconfig (which then throws Unable to locate credentials. You can configure credentials by running "aws configure". even if it is not used in the program). I would assume in the same stack you would still need the profile used to create the cluster which would need to remain consistent between machines?

Even though we are using an unconventional way of accessing AWS config (using AWS_CONFIG_FILE to a project local dir with local and CI config files in them), I find it baffling that an org trying to deal with things at any scale would not at least opt for consistent profile names for environments to reduce confusion and doesn't work on my machine problems. Anyway...

[rquitales]

Thanks for your feedback on this change. We've previously received comments on the previous behavior from a number of customers and how it affects their user journeys in a multi-user setup. This coupled with the discussions in #868 and pulumi/pulumi-aws#1906 (comment) led us to revisit the behavior of the generated kubeconfig and its behavior.
I do apologize for any pain this may have caused and I'll be sure to surface this with the rest of the team such that impacts like this are minimized in the future.