Variable Scoping and Dynamic Feeds

Do you know if AWS Accounts can be scoped by Tenant Tags? We found out the hard way that Target Roles don’t work, but Environments do and there doesn’t seem to be any documentation on what works.

Hey Clayton,

Within the AWS account itself you should be able to limit its usage to specific tenants, if that’s what you mean.

You will still need to create a project variable(of Type AWS Account) for the account and scope it to the roles/tenants/environments that you deem necessary. Just curious, which part of target role scoping for aws accounts didnt work? Did you have it as a project variable then scoped to the role? If so, what were you trying to do and what was the result?

Edit: You can also put the feed variable as a variable within the Tenant.

Thanks,
Jeremy

So, creating an AWS Account variable and then scoping it by target role did not get evaluated when we first setup our Octopus deploys; scoping by environments did. We have been using that since, but maybe you guys have changed/fixed something?

Hey Clayton,

I’m not sure about in the past, it is possible there was a bug. I did a quick test on 2020.4.3. I created an AWS account project variable scoped to a role and it evaluated correctly for me on my end. I did an AWS script step that executed on a worker on behalf of a target (role selected).

Please let me know if your testing shows differently.

Thanks,
Jeremy

1 Like

Hey sorry, I’ve been working through this update with the tenant stuff. If that worked for you, I will likely change ours over to use the target roles as that greatly simplifies the way we use accounts. I didn’t look up whether there was a bug logged against that.

Thanks,
Clayton

Hey Clayton,

No worries. If you want to do a quick test before you put a bunch of work in(as we’re on slightly different versions), you could do the same as I did. Create a dummy project with 2 steps (AWS CLI), script: aws iam get-user --user-name putarealusernameinhereyouhaveaccessto. Scope it to a role in the variables, then in the 2 steps, have the first step be the correct role and have the second step be the incorrect role. You should get good results on the first and the second should fail.

Let me know how it goes.

Best,
Jeremy

Ah, that’s right. The bug is not exactly that AWS Account variables can’t be scoped by roles, it’s that we use one for all nonprod deployments and one for all prod. If you have two account values that don’t both include the environments you’re deploying to, Octopus doesn’t allow the deploy.

Example:

AwsAccount

  • AwsNonProd: NonProd role
  • AwsProd: Prod-NA, Prod-EU roles

Deploy to Joe’s Dev Machine will not execute because it is not added to the account “AwsProd”.

This is why we haven’t been using target roles for the AWS Account variables.

Hi Clayton,

In your example, is Joe’s Dev Machine a target, or an environment? If it’s a target, which roles does it belong to, and which environment is it in? If it’s an environment, it would have to be assigned at the account level, because the account environment area in the account is a method of restricting where it can be used so that behavior lines up.

You can also create an account with no environments scoped, and that can be used in any environment.

Please let me know what you think.

Thanks,
Jeremy

Sorry, it’s an environment. We try to only add nonprod environments to our nonprod AWS account and prod environments to the prod AWS account. If we were to remove all environments from both accounts then it should work as a variable as long as it’s scoped correctly? I would have to think through whether that has side effects. My only concern is making sure no one accidentally runs scripts in prod by accident.

Hi Clayton,

Is “Joe’s Dev Machine” listed in the AwsNonProd AWS account? If not, is there any reason that it couldn’t be added there so it can be used in the case of Joe’s Dev Machine deployments?

Thanks,
Jeremy

It is added to the AwsNonProd account, but not the AwsProd account in my example. Really the point is that we have approximately 30 nonprod environments and 15-20 prod environments that utilize those two AWS Accounts. To have to add all of them to both accounts and every time we add a new one is cumbersome, so we’ve worked around it ever since. I was hoping that there was another way to scope the account variables so that wasn’t the case, but perhaps there’s a good reason for the way it works now.

Thanks,
Clayton

This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.