https://pulumi.com
Join Slack
This message was deleted.
# aws
s
This message was deleted.
c
Running locally in this new environment I can certainly 
pulumi up
and 
pulumi down
, without error - so in that regard this seems to be spurious. However the message is also popping up in our github actions CI/CD flow (using pulumi/actions@v4) and there we’re seeing more permissions related issues - so I’m trying to nail down what the cause may be.
l
The provider saved in your stack knows which profile it was created with. It won't use another one.
If you run 
pulumi up
with no profile set, it'll presumably use the AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY, and if they're available in multiple environments, it'll work.
Even if their values are different
c
@little-cartoon-10569 in our case the values are coming from the AWS instance metadata api
which is what the SDK should fall back to
l
When you first run 
up
, Pulumi will create an AWS provider object and serialize that in your stack. That will include the credentials or auth method. If there's no details saved in there, it'll fall back to no-creds each time, which seems to be what you're expecting. But if there are creds saved in there (such as the value of the AWS profile), then it'll keep using them.
You can export your Pulumi stack and see what the values in your AWS provider are.
pulumi stack export --file stack.json
will create an export, then you can view it in your favourite JSON viewer and look for the AWS provider.
c
which seems to be what you’re expecting
correct. Is there a way to change this?
l
Here a redacted version of one of mine.
Untitled
You can see the profile is saved in there
The correct way to ensure that default credentials are used is to explicitly create the AWS provider with no profile or key properties, so that the SDK has to do its thing.
Then you need to use that provider everywhere.
If you're able to, I'd recommend running 
pulumi down
first, then making the changes. This will be easiest.
If you need to resources to remain in the cloud, then you'll probably have to edit the stack manually. There may be another way to do it, but I don't know.
c
looking through the stack output I do not see inputs.profile or output.profile
l
That said, I recommend not falling back to letting the SDK do its thing. This is risky.
c
Copy code
{
                "urn": "urn:pulumi:software::eks::pulumi:providers:aws::default_5_35_0",
                "custom": true,
                "id": "a5516725-ff11-4fed-a721-770cbb09b1ab",
                "type": "pulumi:providers:aws",
                "inputs": {
                    "region": "us-east-1",
                    "version": "5.35.0"
                },
                "outputs": {
                    "region": "us-east-1",
                    "version": "5.35.0"
                },
// ... snip ...
            {
                "urn": "urn:pulumi:software::eks::pulumi:providers:aws::default_5_16_2",
                "custom": true,
                "id": "383a4162-ae02-4537-8e19-4a46bd2baaf3",
                "type": "pulumi:providers:aws",
                "inputs": {
                    "region": "us-east-1",
                    "version": "5.16.2"
                },
                "outputs": {
                    "region": "us-east-1",
                    "version": "5.16.2"
                },
                "created": "2023-04-03T17:01:29.852016463Z",
                "modified": "2023-04-03T17:01:29.852016463Z"
            },
l
Ah. That looks correct for what you want.
So I don't know why it's looking for the admin profile. Are you in the right project and stack when you run the stack export?
c
there is one place where “admin” shows up - let me grab that snippet
oh, interesting
it shows up in a kubernetes related context; where the kubernetes provider has been told to use AWS_PROFILE=admin
l
Aha. Looks like you've got a winner.
c
it looks as though 
@pulumi/eks
(typescript) does this on our behalf 😕
l
You can probably create the EKS provider explicitly to do what you need it to. Let me check the API.
c
I think it has just recorded the environment in which it was run
l
Nope. Zero parameters in the EKS provider.
Weird.
c
as opposed to it being a provider arg explicitly
l
Sorry, the "nope" was a response to "You can probably create..."
c
I understood your context 👍🏼
👍 1
I’m going to run an up, and I feel like that’ll make this problem go away.
“problem”; as I said, it seems spurious
l
Good. But if that doesn't work, this will be a bit tough to sort. You can rework your code to use AWS instead of EKS...
c
OK, confirmed
The 
@pulumi/eks
package has an output of kubeconfig; it will record any environment variables that pulumi is called with. So by re-running it without 
AWS_PROFILE=admin
the output no longer records that env var.
👍 1
Open in Slack
PreviousNext
Powered by

Pulumi Community

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.

Powered by