Azure-webapp, database en Key Vault op STACKIT

De run in cijfers

Een kleine omgeving die voor deze pagina is opgesteld en offline is beoordeeld. De cijfers komen uit de consolesamenvatting, assessment.json en het uitvoeringspakket van de run.

Het migratiepakket is gedeeltelijk uitvoerbaar en niet goedgekeurd: de run geeft zelf aan dat geen enkele OpenTofu-stap kan draaien zoals die er staat, omdat waarden zoals project_id en de toegangslijst van de database nog ontbreken.

De database: een private server wordt een toegangslijst

Links: de PostgreSQL Flexible Server van de invoer, privé via een gedelegeerd subnet. Rechts: het instanceblok dat de engine schreef. De beoordelingsopmerkingen boven het blok zijn hier weggelaten.

resource "azurerm_postgresql_flexible_server" "shop" {
  name                          = "psql-shop-gwc"
  resource_group_name           = azurerm_resource_group.shop.name
  location                      = azurerm_resource_group.shop.location
  version                       = "16"
  sku_name                      = "GP_Standard_D4s_v3"
  storage_mb                    = 131072
  backup_retention_days         = 14
  administrator_login           = "shopadmin"
  administrator_password        = var.db_admin_password
  delegated_subnet_id           = azurerm_subnet.data.id
  public_network_access_enabled = false
  zone                          = "1"
}

resource "stackit_postgresflex_instance" "shop" {
  project_id = var.project_id
  name       = "psql-shop-gwc"
  version    = "16"
  flavor_id  = "4.32"
  storage = {
    class = var.postgresflex_storage_class
    size  = 128
  }
  backup_schedule = "0 2 * * *"
  network = {
    acl = var.shop_allowed_cidrs
  }
  retention_days = 32
}

• Flavor op basis van de brongrootte

  De bron-SKU heeft 4 vCPU en 16 GiB. Het concept neemt flavor 4.32, de kleinste single-node PostgreSQL Flex-flavor in eu01 die daaraan voldoet, met 4 vCPU en 32 GiB. Dimensioneer opnieuw op gemeten belasting als het geheugen voor de kosten van belang is.

• Back-ups

  De bron bewaart back-ups 14 dagen. Het concept stelt retention_days in op 32, wat de run als TRANSFORMED vastlegt, en een dagelijkse back-up om 02:00 als standaard om te bevestigen.

• Privé wordt een toegangslijst

  Het gedelegeerde subnet, de schakelaar voor publiek netwerk, de zone en de beheerderslogin worden niet overgenomen. Clients bereiken de instance via de ACL, opgegeven in de variabele shop_allowed_cidrs, die geen standaardwaarde heeft. De netwerkblootstelling is een REVIEW-punt: beslis over de endpointscope voordat u toepast.

De vault: secrets verhuizen, het toegangsmodel verandert

Links: de Key Vault en zijn secret. Rechts: de Secrets Manager-instance die de engine schreef. Het secret zelf staat niet in het concept.

resource "azurerm_key_vault" "shop" {
  name                       = "kv-shop-gwc"
  location                   = azurerm_resource_group.shop.location
  resource_group_name        = azurerm_resource_group.shop.name
  tenant_id                  = var.tenant_id
  sku_name                   = "standard"
  rbac_authorization_enabled = true
  purge_protection_enabled   = true
  soft_delete_retention_days = 30
}

resource "azurerm_key_vault_secret" "db_password" {
  name         = "db-password"
  value        = var.db_admin_password
  key_vault_id = azurerm_key_vault.shop.id
}

resource "stackit_secretsmanager_instance" "migrated_secrets" {
  project_id = var.project_id
  name       = "migrated-secrets"
}

• Eén instance bevat alle secrets

  U maakt elk secret opnieuw aan als key in de instance. Naam, tenant, SKU, toegangsbeleid, netwerkregels en bewaartermijn van de vault worden niet gegenereerd.

• Elke afnemer krijgt nieuwe inloggegevens

  Key Vault verleent toegang aan Microsoft Entra-principals via toegangsbeleid of Azure RBAC. Op STACKIT gaat toegang naar Secrets Manager-gebruikers of service accounts, dus de webapp heeft nieuwe inloggegevens en een codewijziging nodig.

• Verwijderbeveiliging wordt geweigerd

  De vault heeft purge protection en 30 dagen soft delete. De run citeert de uitspraak van STACKIT dat afzonderlijke secrets niet kunnen worden hersteld en legt de instelling vast als geweigerd. Plan uw eigen beveiliging, bijvoorbeeld versiebeheerde secrets en een back-uproutine.

De netwerkregel: alleen toestaan, en open egress

Links: de security group van het datasubnet met één regel. Rechts: de groep en de regel die de engine schreef. De opmerkingen in het bestand noemen wat Azure stilzwijgend toevoegde.

resource "azurerm_network_security_group" "data" {
  name                = "nsg-data"
  location            = azurerm_resource_group.shop.location
  resource_group_name = azurerm_resource_group.shop.name

  security_rule {
    name                       = "allow-postgres-from-app"
    priority                   = 100
    direction                  = "Inbound"
    access                     = "Allow"
    protocol                   = "Tcp"
    source_port_range          = "*"
    destination_port_range     = "5432"
    source_address_prefix      = "10.40.1.0/24"
    destination_address_prefix = "*"
  }
}

resource "stackit_security_group" "data" {
  project_id = var.project_id
  name       = "nsg-data"
}

resource "stackit_security_group_rule" "data_allow_postgres_from_app" {
  project_id        = var.project_id
  security_group_id = stackit_security_group.data.security_group_id
  direction         = "ingress"
  ether_type        = "IPv4"
  ip_range          = "10.40.1.0/24"
  port_range = {
    max = 5432
    min = 5432
  }
  protocol = {
    name = "tcp"
  }
}

• Prioriteiten vervallen

  Security groups van STACKIT staan alleen toe, en de regels worden samen geëvalueerd. De prioriteit van de bronregel wordt niet overgenomen en de run weigert die. Geen deny-regel in de gescande omgeving woog zwaarder dan deze allow, maar een regel buiten de scan zou dat kunnen.

• Standaardregels van Azure zijn expliciet werk

  Azure voegt standaardregels toe voor verkeer binnen het virtuele netwerk, vanaf de load balancer en naar het internet. De run merkt op dat een nieuwe STACKIT-groep geen van die standaardregels heeft, dus elke regel die u nog nodig hebt, schrijft u zelf.

• Egress is ruimer dan de bron

  STACKIT maakt op elke nieuwe groep een allow-all IPv4-egressregel aan, en het concept beheert die niet. De Security Architect beslist of die na de apply wordt verwijderd. Dit is de enige beslissing die stappen van het plan blokkeert.

De webapp: een Cloud Foundry-organisatie

Links: de Linux-webapp met system-assigned identity, een Key Vault-verwijzing en VNet-integratie. Rechts: het organisatieblok. De app zelf wordt met cf push uitgerold.

resource "azurerm_linux_web_app" "shop" {
  name                      = "app-shop-gwc"
  resource_group_name       = azurerm_resource_group.shop.name
  location                  = azurerm_resource_group.shop.location
  service_plan_id           = azurerm_service_plan.shop.id
  https_only                = true
  virtual_network_subnet_id = azurerm_subnet.app.id

  identity {
    type = "SystemAssigned"
  }

  site_config {
    always_on = true

    application_stack {
      node_version = "20-lts"
    }
  }

  app_settings = {
    "DB_HOST"     = azurerm_postgresql_flexible_server.shop.fqdn
    "DB_NAME"     = "shop"
    "DB_PASSWORD" = "@Microsoft.KeyVault(SecretUri=https://kv-shop-gwc.vault.azure.net/secrets/db-password/)"
  }
}

resource "stackit_scf_organization" "migrated_apps" {
  project_id = var.project_id
  name       = "migrated-apps"
}

• Instellingen worden manifest en bindings

  App-instellingen, alleen HTTPS, de runtimeversie en het plan worden niet gegenereerd. Ze verhuizen naar het Cloud Foundry-manifest en de service bindings die u schrijft.

• Identiteit is een beslissing

  De managed identity die de vault las, wordt expliciete inloggegevens. De run vraagt de Identity Architect hoe de app aan een identiteit komt; het concept koppelt geen service account.

• De database bereiken

  De VNet-integratie bereikte de privédatabase. Op STACKIT bereikt de app de PostgreSQL-instance via de ACL of, waar ingeschakeld, via een Network Area, en u beslist welke.

Hoe de omgeving wordt gekoppeld

Klassen zoals de run ze heeft bepaald. De run plaatst Key Vault, opslag en het virtuele netwerk in golf 1, de subnets in golf 2, de security group en de database in golf 3 en de webapp in golf 4.

Wat een ontbrekende variabele doet

De eerste run liet terraform.tfvars weg, dus var.tenant_id van de Key Vault had geen waarde. De tweede run bevatte die wel. Beide consolesamenvattingen zijn uit de runs overgenomen.

Source        15 resources · 8 units · visibility: Required input missing
Migration     6 drafted · 1 need no resource · 1 has no draft because an input the source needs is not in the package (of 8 units: 7 the draft considered, 1 has no draft)
Attention     1 variable without a value (var.tenant_id) · 7 decisions to make (1 of the 7 holds plan steps) · 8 units to review · 8 open requests (3 block the draft, marked in inputs-template.yaml)

Source        15 resources · 8 units · visibility: Variable unresolved
Migration     7 drafted · 1 need no resource (of 8 units the draft considered)
Attention     7 decisions to make (1 of the 7 holds plan steps) · 8 units to review · 7 open requests (2 block the draft, marked in inputs-template.yaml)

• De run noemt wat hij nodig heeft

  Zonder de waarde had de Key Vault geen concept en meldde de samenvatting dat een invoer die de bron nodig heeft niet in het pakket zat. Mét de waarde werden 7 eenheden opgesteld.

• Eén variabele blijft bewust open

  De tweede run meldt nog steeds “Variable unresolved”. Het architectenrapport noemt de variabele: db_admin_password, die gevoelig is en geen standaardwaarde heeft; de terraform.tfvars van de demo levert alleen tenant_id. Dat blokkeert hier geen concept; lever de variabele aan met --var-file als de eenheden die de variabele lezen volledig beoordeeld moeten worden.

• Lever de variabelenbestanden aan

  De tweede run las terraform.tfvars uit de invoermap zonder enige optie; verdere bestanden geeft u mee met --var-file. Geef de engine dezelfde variabelenbestanden als uw pipeline gebruikt, zodat geen enkele eenheid zonder concept blijft bij gebrek aan een waarde.

De beslissingen die bij de architecten liggen

1. 01

   Security Architect: standaard egress

   Verwijder de allow-all IPv4-egressregel van de security group na de apply, of accepteer die. Deze beslissing blokkeert stappen van het plan.

2. 02

   Network Architect: blootstelling van de database

   Kies de endpointscope en geef de clientprefixen op in shop_allowed_cidrs. Blijft die leeg, dan maakt de STACKIT-API het endpoint publiek.

3. 03

   Identity Architect: identiteiten

   Beslis hoe de webapp zich bij Secrets Manager authenticeert en hoe de databasegebruikers met stackit_postgresflex_user worden aangemaakt.

4. 04

   Platform Architect: data en cutover

   Kies een mechanisme voor dataverplaatsing voor de database en de bucket. De run noemt beide met het mechanisme UNKNOWN en zonder grootte, snelheid of toegestane downtime, omdat de bron die niet vermeldt. Voor de database zijn pg_dump met pg_restore of logische replicatie de gebruikelijke routes.

5. 05

   Iedereen: eigenaarschap van de open instellingen

   Sluit of accepteer de 33 openstaande instellingen via het beoordelingsbestand, één record per eigenaarsrol.

Vragen van architecten over deze omgeving

Bronnen

• STACKIT Secrets Manager
• STACKIT Cloud Foundry
• STACKIT security groups: concepten
• STACKIT Network Area: concepten
• Microsoft Learn: overzicht van Azure Key Vault
• STACKIT-documentatie: PostgreSQL Flex-flavors en prestatieklassen