Skip to main content

How to Ensure Compliant Deletion of Environments

What is this guide about?

This guide explains how to design and implement a secure, compliant, and auditable tenant deletion process using meshStack. It covers the full lifecycle, configuration options, and operational safeguards for deleting environments.

Why Compliant Deletion Matters​

Deleting cloud environments (tenants) is a sensitive operation. Risks include accidental data loss, compliance violations, and orphaned resources that may continue to incur costs. Organizations need a process that balances operational agility with control and auditability.

meshStack provides a flexible, multi-stage tenant deletion workflow that can be tailored to your needs—whether for sandbox experimentation or production workloads.

The Tenant Deletion Lifecycle​

Tenant deletion in meshStack follows a clear, auditable process:

1. Request​

Application teams initiate deletion by removing a tenant from their project workspace. This action places the tenant in the deletion queue.

  • Access Impact: Until deletion is approved, meshStack disables all assigned project roles for the tenant. Teams lose access to the tenant in the cloud platform, but the tenant itself is still replicated.

2. Approval​

Tenants in the deletion queue receive the status Requires approval.

  • Manual Approval: By default, an operator must approve deletion from the Tenants view in the admin area, or through the meshObject API.
  • Auto-Approval: You can configure meshStack to auto-approve deletion requests per landing zone. This is useful for sandbox environments, while production zones may require stricter controls.
  • Marketplace Tenants: If the Open Service Broker marketplace is enabled, OSB tenants are automatically approved and deleted.

Once a tenant deletion is approved, it cannot be aborted.

3. Building Block Deletion​

Before deletion replication begins, meshStack automatically queues all tenant building blocks for deletion.

  • All tenant building blocks are listed directly on the deletion page.
  • All tenant building blocks are automatically deleted before the tenant deletion proceeds.
  • While this happens, the tenant's deletion state is Deleting Building Blocks.

4. Deletion Replication​

Once its building blocks are deleted, the tenant's deletion state changes to Deleting in Platform, or to Awaiting Deletion in Platform if an operator has to delete the tenant in the cloud platform.

  • meshStack verifies the tenant's existence and deletes any IAM groups, permissions, and artifacts it manages for the tenant.
  • Cloud Tenant Deletion: By default, operators must manually delete the tenant in the cloud platform. Optionally, meshStack can be configured to perform this automatically.

Once meshStack confirms deletion (or the tenant enters a Suspended/Disabled state), the status updates to Deleted.

Warning: Automated tenant deletion will remove all workloads in the tenant. This can cause irrecoverable data loss. Some platforms (AWS, Azure, GCP) offer limited recovery windows—review your provider's documentation. meshStack does not delete or touch resources inside the tenant. Billing may not stop immediately after tenant deletion, depending on the platform. This is distinct from deleting the whole platform, where meshStack stops collecting billing data and removes the platform's metering data immediately.

Operator Experience: Managing the Deletion Queue​

Operators manage tenant deletion from the Administration Area:

  1. Navigate to Tenants under Platforms.
  2. View tenants in the deletion queue and those already deleted alongside all other tenants.
  3. Filter by status (e.g., Deletion in Progress, Deleted) or by the pending action Deletion Approval Pending.

Approving or Rejecting Deletion​

  • Approve or decline requests, optionally adding a comment (max 255 characters).
  • If declined, the tenant is reinstated in its project and project role bindings are re-enabled—restoring access for application teams.
  • When a project is marked for deletion, it is automatically deleted once all its tenants are successfully deleted.

Approving or Rejecting Deletion via the API​

You can also approve or decline a deletion with an API key, for example from a script that cleans up the cloud side after meshStack is done:

  1. Create an API key with the Approve deletion permission for tenants. The Admin variant covers every tenant. The Platform Builder variant covers the tenants on a platform your workspace owns, and the tenants on a landing zone your workspace owns if your workspace is a contributor of that platform.
  2. Approve the deletion with POST /api/meshobjects/meshtenants/{uuid}/approve-deletion, or decline it with an optional reason with POST /api/meshobjects/meshtenants/{uuid}/decline-deletion.
  3. Poll the tenant to follow the deletion. meshStack deletes the tenant's building blocks first, so this can take a while. status.pendingDeletionState says how far the deletion has got: DELETING_BUILDING_BLOCKS while meshStack deletes the building blocks, then DELETING_IN_PLATFORM while meshStack deletes the tenant in the cloud platform, or AWAITING_PLATFORM_DELETION while it waits for an operator to delete the tenant there. Once fetching the tenant answers 404 Not Found, meshStack has deleted it. Fetching the tenant needs a permission to list tenants as well, as the Approve deletion permission alone does not allow it. For a Platform Builder key, that is the Admin variant of the tenant List permission.

To find the tenants whose deletion is at a certain step, list the tenants with the pendingDeletionState filter. For example, GET /api/meshobjects/meshtenants?pendingDeletionState=AWAITING_PLATFORM_DELETION returns every tenant an operator has to delete in the cloud platform. Repeat the parameter to ask for several steps. If you add state, it must include MARKED_FOR_DELETION.

Repeating an approval is safe: approving a deletion that is already approved changes nothing and succeeds again, until the tenant is deleted. Declining only works while the deletion awaits approval. Declining for a tenant that is not marked for deletion answers with 409 Conflict, and so does a repeated decline, because the tenant is active again after the first one. While a deletion awaits approval, the meshTenant carries approveDeletion and declineDeletion links if your API key may approve and decline it.

Configuring Deletion Behavior​

meshStack lets you tailor the deletion workflow per landing zone:

  • Deletion after Approval: Enforce an approval flow before deletion.
  • Automatic Deletion: meshStack deletes tenants in the cloud platform automatically.
  • Manual Deletion: Operators manually delete tenants in the cloud platform; meshStack only removes its own artifacts.

How to Configure in Platform Builder​

Automatic Tenant Deletion​

  1. Go to Platform Builder.
  2. Select your platform.
  3. Open the Landing Zones section.
  4. Choose the relevant landing zone.
  5. Enable Automatically perform approved tenant deletions via replication.
  6. (Optional) Disable Automatically Approve Tenant Deletion to require manual approval.
  7. Save.

Manual Tenant Deletion​

  1. Go to Platform Builder.
  2. Select your platform.
  3. Open the Landing Zones section.
  4. Choose the relevant landing zone.
  5. Disable Automatically perform approved tenant deletions via replication.
  6. (Optional) Disable Automatically Approve Tenant Deletion to require manual approval.
  7. Save.

Summary​

meshStack's tenant deletion process is designed for compliance, auditability, and operational flexibility. By configuring landing zones appropriately, you can ensure that environments are deleted securely and in line with your organization's policies.

Concepts​

Guides​