we’ve recently migrated from an in environment whe...
# aws
c
we’ve recently migrated from an in environment where we’d run
AWS_PROFILE=admin pulumi up -s <org>/<stack>
(locally) to an environment where the instances we run on have the permissions the admin profile had as part of their instance profile. Now when we run
pulumi up -s <org>/<stack>
we get the following printed to our terminal:
The config profile (admin) could not be found
. At no point have we done
pulumi config set aws:profile admin -s <org>/<stack>
- so I’m pretty confused as to why this is showing up in the terminal. The message itself is definitely from the AWS SDK (this is well documented on the web). What’s not clear to me what part of pulumi is informing the SDK that the profile
admin
(specifically) is the correct profile. I’ve run
pulumi config get -s <org>/<stack>
for all of our stacks that use the AWS provider and I can confirm
aws:profile
is not present in any of them. Is anyone able to point me in the right direction to either silence this message, or determine whether it is a problem?
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.
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 👍🏼
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.