prehistoric-london-9917
06/23/2021, 1:06 AMdestroy
operation?
Context: Suppose I create a stack with this snippet of provider configuration:
config:
aws:assumeRole:
externalId: some/value
roleArn: arn:aws:iam::123456789012:role/my_deployment_role
This gets stored in the state file:
"type": "pulumi:providers:aws",
"inputs": {
"assumeRole": "{\"externalId\":\"some\/value\",\"roleArn\":\"arn:aws:iam::123456789012:role/my_deployment_role\"}",
Let’s say that role has a limited set of permissions that doesn’t allow removing resources.
At some point I want to destroy that stack. So I assume an administrator
role that can do anything and run pulumi destroy
.
The current behaviour is that Pulumi assumes the role stored in state (even if I’ve removed it from the stack configuration) and try to delete the stack’s resources, which fails.
I can work around this by removing the assumeRole
from the stack config, run pulumi up
, which removes the role assumption from the state file. Then I can run pulumi destroy
.
It would be nice if destroy
had a ignore_state_role
option so that admins can destroy resources regardless of the role assumed to create them.
Is there a reason for the current behaviour that I’m not thinking of? Should I raise a bug or feature request for this?
NB: If I rely on environment variables for AWS authentication (which are picked up by the underlying Go AWS SDK), I don’t have this problem at all. It’s only when I define the role assumption in the stack configuration.@pulumi/pulumi
github issues for something like this, but didn’t find anything that quite matched my issue.little-cartoon-10569
06/23/2021, 1:43 AMpulumi up
, pulumi destroy
. The protection is there almost all the time, and "easily" removed when needed.gentle-diamond-70147
06/23/2021, 5:15 AMprehistoric-london-9917
06/23/2021, 10:29 PMpulumi/pulumi
the right repo? Or should it be pulumi/aws
since this (afaik) is provider specific?little-cartoon-10569
06/23/2021, 10:43 PMprehistoric-london-9917
06/24/2021, 1:31 AM