Good morning, I am running into a weird issue with...
# aws
m
Good morning, I am running into a weird issue with which I hope someone here can help me: When attempting to run a Github Action across 2 AWS accounts, I get an access denied on opening the S3 cloud_url. We have a centralised build account that deploys resources into 2 other AWS accounts: production and non-production. The Github Runners are deployed in the build account using ARC, and leverage OIDC to get an STS token attached to an IAM role. When running the Pulumi preview action, it fails to access the S3 bucket in the non-production account. The worklow runs as a container on EKS in the build account, and the runner has the necessary permissions to access the S3 bucket in the non-production account. We are using OIDC to get an STS token attached to an IAM role. Then we assume a role in the non-production account. Access to S3 using this method was tested outside of the Pulumi action and works as expected, we can download the meta.yaml file from the S3 bucket in the other account. This works fine when running this action within the build account, but fails when running in the other account. The exact error message we get is:
Copy code
`
sink.go:178] defaultSink::Error(error: problem logging in: read ".pulumi/meta.yaml": blob (key ".pulumi/meta.yaml") (code=Unknown): AccessDenied: Access Denied
    status code: 403, request id: <OBFUSCATED>, host id: <OBFUSCATED>)
Pulumi configs tried: -
aws:region
set to the region of the non-production account -
aws:assumeRole
set to the ARN of the role in the non-production account -
aws:profile
set to the name of the profile in the build account that has the necessary permissions, including exporting AWS_DEFAULT_PROFILE to the profile name used - combinations of the above None of these have worked as expected. Am I doing something wrong, or is this scenario not supported?
l
The Pulumi
aws:*
config is for the default provider, which is used to connect to AWS during the run/deployment phases. It is not related to the backend: you need to use the normal credentials for this. Set up the appropriate environment variables like AWS_PROFILE, AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_SESSION_TOKEN, etc.
This way, if you changed your backend, you wouldn't change your code or configuration at all. Only environment variables would change.
m
That makes sense, thanks. Will give that a go and see if it works, however i have tried setting the AWS_PROFILE but will triple-check.
l
Does the GitHub action override the env var when calling Pulumi? It's been a while since I used the action.
It looks like you should use
with: env: AWS_PROFILE: ...
m
I don't think so, If I connect to the S3 bucket outside of the pulumi action from with in the same action, it works
l
Which implies that it does change the env vars.
m
ah, good one
l
Since it would work if it didn't.
m
yes, that makes a lot of sense actually
l
You may want to try something like
Copy code
- uses: pulumi/actions@v6
        with:
          command: preview
          stack-name: org-name/stack-name
        env:
          AWS_PROFILE: ${{ secrets.AWS_PROFILE }}
m
got a packed couple of days coming up but I will see if I can squeeze this in - will double back here once I have
Thanks!
ok I could not resist and just tried it - it works after setting
env: AWS_DEFAULT_PROFILE: <profile_name>
AND after renaming the global env from
AWS_WEB_IDENTITY_TOKEN_FILE
to
WEB_IDENTITY_TOKEN_FILE
which It think confused the CLI into giving the web_identity token var preference over AWS_DEFAULT_PROFILE
thanks very much for getting me into the right direction, much appreciated!