Ga naar inhoud

Upgradehandleidingen voor het platform (v4.4.0 tot en met v4.12.x)

Versiespecifieke stappen om een configuratierepository van een klant te upgraden. Gebruik ze samen met de generieke procedure in Wat te doen als een nieuwe versie wordt gereleased.

Hoe je deze handleidingen gebruikt

  • De handleidingen zijn cumulatief. Lees en doe de handleiding van elke versie tussen je huidige versie en je doelversie, de oudste eerst. Een versie die niet in de lijst staat (bijvoorbeeld v4.8 of v4.10) heeft geen speciale stappen nodig.
  • Doe de opruiming in de portal voordat je met latere stappen verdergaat. Voor het verwijderen van een policy assignment of initiative is een recht op de management group nodig. Vraag eerst verhoogde toegang (PIM) aan als je proces dat vereist.
  • Paden zijn relatief aan de root van de configuratierepository. Oudere versies gebruikten een parameters repository met dezelfde indeling. <env> staat voor elke map van een platformomgeving (canary, prod) onder environments/. Doe elke bestandsstap in elke omgeving.
  • Sommige handleidingen beschrijven de oudere indeling met één pipeline (pipelines/main.yaml). In de huidige indeling zijn de entry pipelines hub, spoke, infrastructure en container (Pipelines en workflows). Als een stap niet voor jouw indeling geldt, zegt de handleiding dat.
  • Upgrade je over meerdere versies, plan dan één keer aan het einde in plaats van na elke handleiding. Lees de plan op onverwachte destroys of replacements (De spoke plans lezen).
Versie Van Samenvatting
v4.4.0 v4.3.x Policybestanden verwijderen, overrides voor state storage instellen, twee policy-objecten in de portal verwijderen
v4.5.0 v4.4.x Entry pipeline: de configuratierepository als resource toevoegen en publiceren
v4.5.1 v4.5.x Custom alerting assignments, initiatives en Deploy_*-definities verwijderen
v4.6.0 en v4.6.1 v4.5.x ghrunners.auto.tfvars toevoegen
v4.7.0 v4.6.x Drie Defender for Cloud-assignments verwijderen
v4.9.0 v4.7.x tfvars-paden inkorten, een firewallvariabele toevoegen, de parameter environment verwijderen
v4.11.x v4.9.x Oude DNS- en BIO-policybestanden verwijderen, twee assignments en twee initiatives verwijderen
v4.12.x v4.11.x De assignment en initiative voor private DNS-zones verwijderen, firewall_policy_id controleren

Versie 4.4.0

Vanaf v4.3.x. De configuratie van policies en monitoring is verhuisd naar de coderepository, dus de kopieën in de configuratierepository moeten weg (geschiedenis).

Bestanden uit de configuratierepository verwijderen

Doe dit voor zowel environments/prod/ als environments/canary/.

Pad onder environments/<env>/policies/ Verwijderen
policy_assignments/01_management_groups/ policy_set_assignment_compliance_asc.json, policy_set_assignment_compliance_cis.json, policy_set_assignment_compliance_iso.json, policy_set_assignment_defender.json, policy_set_assignment_diagnostics.json
definitions/general/ Elk policy_definition_es_deploy_diagnostics_*.json, en policy_definition_es_deploy_asc_securitycontacts.json
set_definitions/general/ policy_set_definition_defender_for_cloud.json, policy_set_definition_es_deploy_diagnostics_loganalytics.json, policy_set_definition_es_deploy_mdfc_config.json

De locatie van de state storage instellen als die niet de default is

Het platform moet nu weten waar het storage account met de Terraform state staat. Komt het jouwe overeen met alle onderstaande defaults, dan hoef je niets te doen.

Onderdeel Default
Naam van het storage account stlz<company short name>state001
Resource group rg-<company short name>-tfstate-<location short name>-001
Subscription De management subscription

Wijkt een waarde af, voeg dan deze variabelen toe aan environments/prod/global.tfvars (en het canary-equivalent):

Variabele Waarde
overwrite_state_storage_subscription_id De subscription-ID van het state storage account
overwrite_state_storage_rg_name De naam van de resource group van het state storage account
overwrite_state_storage_name De naam van het state storage account

Twee policy-objecten in de Azure portal verwijderen

  1. Open Azure Policy en daarna Authoring > Definitions.
  2. Zoek Deploy-MDFC-Config en open de initiative. Verwijder op het tabblad Assignments elke assignment. Ga terug en verwijder de initiative.
  3. Zoek Deploy Microsoft Defender for Cloud Security Contacts en open de policy. Verwijder elke assignment op het tabblad Assignments en verwijder daarna de definitie.

Versie 4.5.0

Vanaf v4.4.x. Deze handleiding geldt voor de oudere indeling met één pipeline. De pipeline checkt hierdoor de configuratierepository expliciet uit en publiceert hem als artifact. In dezelfde release kwam GitHub erbij als bron voor de platformconfiguratie.

In pipelines/main.yaml van de configuratierepository:

  1. Voeg de configuratierepository als resource toe, naast de coderepository:

    resources:
  repositories:
    - repository: <code repository resource name>
      type: git
      name: <project>/<code repository name>
      ref: refs/tags/<version>

    - repository: <configuration repository resource name>   # new
      type: git
      name: <configuration repository name>
      ref: $(Build.SourceBranch)

    Zorg dat de name van de nieuwe resource de echte naam van de configuratierepository is.

  2. Wijzig de eerste checkout-stap van self naar de nieuwe resource:

    - checkout: <configuration repository resource name>   # was: self
  path: s/customer
  fetchDepth: 0
  persistCredentials: true
  clean: true

- checkout: <code repository resource name>
  path: s/landingzone-core
  clean: true

  3. Voeg na de bestaande firewall-artifacttaak een taak toe die de configuratie als artifact publiceert:

    - task: PublishPipelineArtifact@1
  displayName: Publish Customer Content
  inputs:
    targetPath: '$(System.DefaultWorkingDirectory)/customer/'
    artifact: 'CustomerSource'
    publishLocation: 'pipeline'

De huidige entry pipelines (hub.yaml en de andere) checken de configuratierepository al uit. Voor hen is deze handleiding niet nodig.

Versie 4.5.1

Vanaf v4.5.x. De alerting policies zijn vervangen door Azure Monitor Baseline Alerts, dus de oude custom alerting-objecten moeten worden verwijderd (Hoe alerting werkt). Vraag eerst via PIM Owner-toegang aan op het canary- en prod- platform. Doe de stappen voor zowel canary als prod.

  1. Verwijder de alerting policy assignments. Verwijder in Azure Policy > Assignments alle vijf assignments met de naam Xebia Custom - Alerting - *.
  2. Verwijder de alerting policy initiatives. Verwijder in Azure Policy > Definitions alle vijf definities met de naam Alerting-*.

  3. Verwijder de Deploy_* policydefinities. Open een Azure PowerShell-sessie (lokaal of in Cloud Shell) en voer onderstaande opdracht uit voor elke omgeving, met de management group-ID van het platform van die omgeving:

    $managementGroupId = "<management group id of the platform>"
Get-AzPolicyDefinition -ManagementGroupName $managementGroupId | Where-Object {$_.Name -Like "Deploy_*"} | Remove-AzPolicyDefinition -Force

Controleer eerst wat het filter selecteert

Het filter verwijdert elke custom policydefinitie op die management group waarvan de naam met Deploy_ begint. Draai eerst het eerste deel van de opdracht zonder Remove-AzPolicyDefinition en lees de lijst. Verwijder alleen definities die het platform heeft aangemaakt.

Versie 4.6.0 en 4.6.1

Vanaf v4.5.x. Versie 4.6.0 voegde een layer toe met het netwerk voor door GitHub gehoste runners. De layer heeft een variabelenbestand nodig, ook als hij niet wordt gebruikt.

Voeg voor elke omgeving en regio die je deployt environments/<env>/<region>/ghrunners.auto.tfvars toe:

# General
deploy_github_runners = false
location              = "northeurope"
location_short_name   = "neu"

# Virtual Network
virtual_network_address_space = null
virtual_network_dns_servers   = null

# Subnets
subnets = null

Zet location en location_short_name op de regio van de map waarin je zit. Laat deploy_github_runners = false staan tenzij de klant door GitHub gehoste runners gebruikt.

Huidige pipelines

De ghrunners layer bestaat in de code, maar is geen onderdeel van de huidige hubpipeline. Het bestand heeft daar geen effect (Deployment layers). Alleen oudere pipelines draaien hem.

Versie 4.7.0

Vanaf v4.6.x. Open in de Azure portal Azure Policy > Authoring > Assignments, zoek deze assignments en verwijder ze:

  • Xebia Default - Defender for Cloud v2 - connectivity
  • Xebia Default - Defender for Cloud v2 - identity
  • Xebia Default - Defender for Cloud v2 - management

Versie 4.9.0

Vanaf v4.7.x. Drie wijzigingen in de configuratierepository.

De bestandspaden in elk tfvars-bestand inkorten

Zoek elk pad dat met ../../../../customer/ begint en verwijder dat deel. Doe dit in alle *.tfvars-bestanden.

Old: ../../../../customer/environments/prod/firewall_rule_configuration
New: environments/prod/firewall_rule_configuration

Een variabele toevoegen aan elk firewall-tfvars-bestand

Voeg in elk firewall.auto.tfvars (één per regio) de onderstaande variabele toe. Gebruik prod of canary, passend bij de omgevingsmap van het bestand.

firewall_rule_collection_global_file_location = "environments/prod/firewall_rule_configuration"

De parameter environment uit de entry pipeline verwijderen

In pipelines/main.yaml (indeling met één pipeline):

  • Verwijder bij de templateverwijzing voor de canary-omgeving (environment_canary) de parameter environment: canary.
  • Verwijder bij de templateverwijzing voor de productieomgeving (environment_prod) de parameter environment: prod.

Versie 4.11.x

Vanaf v4.9.x. Het platform levert nu zijn eigen private DNS-policies mee en de custom BIO-initiative is vervallen.

Oude DNS-policybestanden verwijderen

Verwijder in zowel environments/canary/ als environments/prod/:

  • de mappen policies/policy_set_definitions/private_dns_zones en policies/policy_definitions/private_dns_zones;
  • de bestanden policies/policy_set_definitions/general/policy_set_definition_es_deploy_private_dns_zones.json en policies/policy_set_definitions/general/policy_set_definition_es_enforce_encrypttransit.json;
  • het bestand policies/policy_assignments/01_management_groups/policy_set_assignment_xms_private_dns_zones.json.

De oude BIO-initiative verwijderen

Verwijder in beide omgevingen de map policies/policy_set_definitions/bio_custom.

Policy-objecten in de Azure portal verwijderen

  1. Open Azure Policy > Assignments. Zet de scope op de management group Landing Zones en verwijder de assignment Alerting-LandingZone.
  2. Zet de scope op de management group platform root (de groep cloudplatform) en verwijder de assignment XMS-Deploy-DNS-Zones.
  3. Open Definitions. Zet de scope op Landing Zones en verwijder de initiative Alerting-LandingZone.
  4. Zet de scope op de platform root en verwijder de initiative XMS-Deploy-DNS-Zones.

Namen en scopes

De initiative Alerting-LandingZone is ook de naam van een initiative in het huidige alertingontwerp (Monitoringregels). De handleiding verwijdert het oude object, dat de vorige versie heeft gedeployd. Controleer de scope en de naam van de assignment voordat je iets verwijdert.

Versie 4.12.x

Vanaf v4.11.x. Twee stappen.

De oude objecten voor private DNS-zones in de Azure portal verwijderen

  1. Open Azure Policy > Assignments. Zet de scope op Landing Zones en verwijder de assignment XMMS-Private-DNS-Zones.
  2. Open Definitions. Zet de scope op de management group platform root en verwijder de initiative XMMS-Private-DNS-Zones.

De WAF-policy-ID van de Application Gateway controleren

Elk JSON-bestand van een Application Gateway heeft een geldige firewall_policy_id nodig.

  1. Open elk environments/*/*/application_gateways/*.json in de configuratierepository.
  2. Bevat firewall_policy_id een geldige resource-ID van een WAF-policy, bijvoorbeeld /subscriptions/<subscription-id>/resourceGroups/<resource-group>/providers/Microsoft.Network/applicationGatewayWebApplicationFirewallPolicies/<waf-policy-name>, dan ben je klaar met dit bestand.
  3. Is het null of een lege string, zoek dan de Application Gateway in de Azure portal op met de name uit het bestand en open hem.
  4. Open JSON View, kies de laatste API-versie, zoek "firewallPolicy" en kopieer de waarde van id naar het bestand.
  5. Wijzig in de geplakte waarde ApplicationGatewayWebApplicationFirewallPolicies in applicationGatewayWebApplicationFirewallPolicies (een kleine a aan het begin).
  6. Herhaal dit voor elk bestand, commit en push daarna.

Zie Application Gateway voor de rest van het bestand.

Na de handleidingen

  • Draai hub in Plan-modus en lees elke layer (stap 6).
  • Leg de handleidingen die je hebt gevolgd vast op het work item.
  • Werkte een stap niet zoals beschreven, of ontbreekt er een handleiding, meld dat dan zodat de handleiding kan worden gecorrigeerd (Releasen).