Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

OIDC Accounts being ignored in deployments when having 2 AWS accounts in a variable, one AWS account unscoped and one OIDC account scoped. #9120

Open
Clare-Octopus opened this issue Nov 8, 2024 · 0 comments
Assignees
Labels
kind/bug This issue represents a verified problem we are committed to solving

Comments

@Clare-Octopus
Copy link

Clare-Octopus commented Nov 8, 2024

Severity

Blocking customers from using OIDC accounts in a specific deployment unless all AWS account variable values are scoped.

Version

2024.4.6608

Latest Version

I could reproduce the problem in the latest build

What happened?

When a project has different AWS account values within a variable, one scoped and one unscoped, one being an OIDC account, the deployment will always pick up the unscoped variable value even when deploying to the scoped environment.

This is how the deployment should work based on the way Octopus prioritizes variables. (Please see the Reproduction section for an example of how to produce this bug with an OIDC account).

I have used two AWS accounts in my testing.

Account details for the full reproduction including OIDC:

Clare AWS - AccountID = Accounts-1361 and username = clare.martin
Clare AWS 2 - Account ID = Accounts-2161 and username = clare.martin2
Clare AWS OIDC - Account ID = Accounts-2162

Project variable values:

image

A deployment to my test environment produces the expected account to be used:

image

A deployment to any other environment will used the unscoped variable:

image

However, as you can see from the reproduction below this is not the case when it comes to having an OIDC account in the mix.

Reproduction

  1. Ensure you have an AWS account and an AWS OIDC Account.

  2. Create a project and have a project variable which has 2 values, one for a normal AWS account using an access key and one with an AWS OIDC account. Scope the OIDC Account to an environment:

image

  1. Add a Run a Script step with a script of Write-Host "$Accounts" (accounts being the variable name of the project variable from step 2).

  2. Add a Run an AWS CLI Script step and ensure you use a worker with the required AWS CLI modules on it. In the script have aws sts get-caller-identity as the script and ensure you use the same variable we created in step 2 for the Account field in the step.

  3. Save the project, create a release and deploy it to the scoped environment. You will see it picks up the unscoped variable value (account) and ignores the OIDC account:

image

If I then scope the unscoped account so both variable values are scoped then the same deployment (after updating the variable snapshot but I have also tested this bug manifesting when creating a new release too) results in the OIDC account being used:

image

image

Error and Stacktrace

N/A

More Information

Initial ticket (internal) - https://octopus.zendesk.com/agent/tickets/211518
R and D (internal) - https://octopusdeploy.slack.com/archives/CNHBHV2BX/p1731074210710789
Reproduction (internal) - https://octopus-operations.octopus.app/app#/Spaces-422/projects/test-variable-scoping/deployments/process

Workaround

The workaround here would be to scope all of those variable values to environments so the OIDC account does not get ignored.

You could also create a new variable for just the OIDC account and create an additional Run an AWS CLI Script which uses that new variable for its Account field in the step. You can even scope the additional step so it will only run if you create a deployment to the scoped environment.

Both are not ideal but I am unable to find a better workaround at the moment.

@Clare-Octopus Clare-Octopus added the kind/bug This issue represents a verified problem we are committed to solving label Nov 8, 2024
@octopus-hideaki octopus-hideaki self-assigned this Dec 16, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/bug This issue represents a verified problem we are committed to solving
Projects
None yet
Development

No branches or pull requests

2 participants