Azure Application Gateway
Kopiér link til siden “Azure Application Gateway”
Fornyer certifikatet på en valgt Azure Application Gateway-listener via PFX eller Key Vault med TLS-kontrol og rollback.
Sådan forløber det
- Appliancen forbinder til Azure Application Gateway gennem Azure Resource Manager / Key Vault på port 443.
- Angiv AZURE_RESOURCE_ID og vælg application-gateway-listener som AZURE_TARGET_ROLE. Discovery læser listeners, frontend-adresser og nuværende certifikatreferencer. Angiv AZURE_TARGET_NAME, hvis der er flere listeners.
- Certifikatet installeres som et separat PFX-certifikat eller en versionsfast Key Vault-reference. Kun den valgte listener bindes til det nye certifikat; den gamle reference beholdes. Hvis det fejler: Ved fejl forsøger rollback at genskabe det tidligere serverede certifikat på det valgte mål. En fejl i gendannelsen rapporteres med backup_dir til videre håndtering.
- Appliance kontrollerer, at målet serverer den nye leaf og hele mellemkæden, med korrekt værtsnavn og gyldighed.
Tekniske detaljer
- Forbindelse
- Pakken kører på appliancen, som forbinder over HTTPS til Azure Resource Manager / Key Vault, port 443. Der installeres ingen agent.
- I skal bruge
- Service principal med tenant-id, klient-id og secret samt ARM read/write og operation-statusadgang på den valgte gateway. Appliance skal kunne nå Azure OAuth/ARM over HTTPS og listenerens TLS-port. Key Vault kræver certificate import og secret get/list til automationen samt gatewayens user-assigned managed identity med secret get og netværksadgang til vault.
- Platform
- v1/v2 med direkte PFX; Key Vault på v2. Eksisterende HTTPS- og Layer 4 TLS-listeners vælges via discovery.
- Handlinger
- Discovery, Installation, Kontrol, Rollback
- Pakker
-
azure-appgateway-api1.0.0 - Bemærk
-
- AZURE_CERTIFICATE_MODE vælger direct eller key-vault; ellers beholdes den nuværende lagringsform. Key Vault-reference angives i AZURE_KEY_VAULT_SECRET_ID. Tilføres nyt materiale på en eksisterende vault-sti, oprettes et separat certifikatobjekt uden at rotere delte referencer.
- Angiv et konkret AZURE_VERIFY_SNI ved wildcard eller en listener uden værtsnavn. AZURE_VERIFY_HOST og AZURE_VERIFY_PORT vælger den TLS-adresse, appliance kan nå. Koordinér andre gateway-konfigurationsændringer, da Azure opdateres med et fuldt GET/PUT. Andre versionløse Key Vault-referencer kan blive opdateret af Azure ved en gatewayændring.
- Management-HTTPS verificeres med systemets CA-tillid. MANAGEMENT_TLS_CA_BUNDLE_BASE64, MANAGEMENT_TLS_PIN_SHA256 og MANAGEMENT_TLS_INSECURE er valgfrie indstillinger. En pin skal matche OAuth, ARM og Key Vault på samme tid; brug CA-tillid ved forskellige certifikater. Tillid til det serverede certifikat vælges separat med AZURE_VERIFY_CA_BUNDLE.
- AZURE_OPERATION_TIMEOUT er som standard 1800 sekunder, AZURE_VERIFY_TIMEOUT 300 sekunder; begge kan øges til 86400. Verifikationen gælder de valgte TLS-prober. Deploy gemmer backup_dir under appliance-datavolumenets HOME til verify og rollback; behold mappen i jeres rollbackperiode. Nye certifikatobjekter beholdes; planlæg oprydning efter jeres rollbackperiode.
- En selvstændig verify bruger den bevarede backup_dir og forsøger at gendanne den tidligere valgte binding, hvis TLS-proben fejler ved deadline, også når ARM stadig viser den nye binding.