pulumi-azure icon indicating copy to clipboard operation
pulumi-azure copied to clipboard

pulumi destroy does not give any warnings when executed against the wrong Azure subscription

Open asizikov opened this issue 4 years ago • 0 comments

Context

In my scenario I have two Azure subscriptions (let's call them Sub1 and Sub2)

I'm going to provision resources in Sub1, then switch to Sub2 and try to destroy my resources (which is a mistake for sure, but my point is that pulumi's behavior is misleading here).

Tools used

➜   pulumi version
v2.16.2
➜  az version
{
  "azure-cli": "2.14.2",
  "azure-cli-core": "2.14.2",
  "azure-cli-telemetry": "1.0.6",
  "extensions": {
    "account": "0.2.1"
  }
}
➜  terraform version
Terraform v0.13.5

Pulumi setup

As a minimal reproducible example I'm using this C# code:

using Pulumi;
using Pulumi.Azure.Core;

class MyStack : Stack{
    public MyStack(){
        var resourceGroup = new ResourceGroup("resourceGroup");
    }
}
# select Sub1 subscription

➜  az account set -s Sub1
➜  pulumi up -f --yes
Updating (dev)

View Live: https://app.pulumi.com/asizikov/pulumi-test/dev/updates/3

     Type                         Name             Status
 +   pulumi:pulumi:Stack          pulumi-test-dev  created
 +   └─ azure:core:ResourceGroup  resourceGroup    created

Resources:
    + 2 created

Duration: 15s
➜  pulumi stack -i
Current stack is dev:
    Owner: asizikov
    Last updated: 38 seconds ago (2021-01-03 19:21:31.5237129 +0100 CET)
    Pulumi version: v2.16.2
Current stack resources (3):
    TYPE                                           NAME
    pulumi:pulumi:Stack                            pulumi-test-dev
    ├─ azure:core/resourceGroup:ResourceGroup      resourceGroup
    │     ID: /subscriptions/Sub1/resourceGroups/resourcegroupc1a51a81
    └─ pulumi:providers:azure                      default_3_41_0
          ID: 940791e7-2d8e-407f-9142-752de197e5e8

# now switch to another subscription

➜  az account set -s Sub2

# and run the destroy action

➜   pulumi destroy --yes
Previewing destroy (dev)

View Live: https://app.pulumi.com/asizikov/pulumi-test/dev/previews/96e20244-92ae-4873-8bca-8cda9b5af553

     Type                         Name             Plan
 -   pulumi:pulumi:Stack          pulumi-test-dev  delete
 -   └─ azure:core:ResourceGroup  resourceGroup    delete

Resources:
    - 2 to delete

Destroying (dev)

View Live: https://app.pulumi.com/asizikov/pulumi-test/dev/updates/4

     Type                         Name             Status
 -   pulumi:pulumi:Stack          pulumi-test-dev  deleted
 -   └─ azure:core:ResourceGroup  resourceGroup    deleted

Resources:
    - 2 deleted

Duration: 11s

# Pulumi reported my resources as deleted and cleaned up the state

# the stack is empty
➜  pulumi stack -i
Current stack is dev:
    Owner: asizikov
    Last updated: 1 minute ago (2021-01-03 19:25:03.1858428 +0100 CET)
    Pulumi version: v2.16.2
Current stack resources (0):
    No resources currently in this stack

More information at: https://app.pulumi.com/asizikov/pulumi-test/dev
# now switch back and check my resources
➜  az account set -s Sub1
➜  az group show -n resourcegroupc1a51a81
{
  "id": "/subscriptions/Sub1/resourceGroups/resourcegroupc1a51a81",
  "location": "westus",
  "managedBy": null,
  "name": "resourcegroupc1a51a81",
  "properties": {
    "provisioningState": "Succeeded"
  },
  "tags": {},
  "type": "Microsoft.Resources/resourceGroups"
}

As you can see I've been told that my resources were good to be destroyed and the process has been successful ( as Resources: - 2 deleted). Which is not quite right. And now I have an orphaned resource group without any good way to link it back to a stack.

Comparing to Terraform

Terraform behaves slightly differently in this scenario. I'm going to use this tf file:

terraform {
  required_providers {
    azurerm = {
      source  = "hashicorp/azurerm"
      version = "=2.25.0"
    }
  }
}

provider "azurerm" {
  features {}
}

resource "azurerm_resource_group" "main" {
  name     = "rg-terraform-test"
  location = "West Europe"
}

The same-ish steps sequence performed:

➜  az account set -s Sub1
➜  terraform apply -auto-approve
azurerm_resource_group.main: Creating...
azurerm_resource_group.main: Creation complete after 0s [id=/subscriptions/Sub1/resourceGroups/rg-terraform-test]

Apply complete! Resources: 1 added, 0 changed, 0 destroyed.
➜ az account set -s Sub2
➜  terraform destroy
azurerm_resource_group.main: Refreshing state... [id=/subscriptions/Sub1/resourceGroups/rg-terraform-test]
Do you really want to destroy all resources?
  Terraform will destroy all your managed infrastructure, as shown above.
  There is no undo. Only 'yes' will be accepted to confirm.

  Enter a value: yes


Destroy complete! Resources: 0 destroyed.
➜  terraform destroy
Do you really want to destroy all resources?
  Terraform will destroy all your managed infrastructure, as shown above.
  There is no undo. Only 'yes' will be accepted to confirm.

  Enter a value: yes


Destroy complete! Resources: 0 destroyed.

Terraform hints that I have no resources provisioned and tells the truth after (0 destroyed). Which is good enough. At least I have some sort of warning.

asizikov avatar Jan 03 '21 18:01 asizikov