Bliv en del af mit community / gratis nyhedsbrev — tilmeld dig her

Cloudflare Service Keys: Gennemgå ældre automatisering inden 30. september

Illustreret infografik, der opsummerer: Cloudflare Service Keys: Gennemgå ældre automatisering inden 30. september

Af Greg Nowak. Senest opdateret 2026-07-21.

Godkendelse med Cloudflare Service Keys holder op med at virke den 30. september 2026. Pr. 21. juli er der dermed omkring ti uger til at finde og migrere al automatisering, der stadig sender headeren X-Auth-User-Service-Key.

Risikoen ligger sandsynligvis ikke i jeres nyeste applikation. Se i stedet på den operationelle lim: scripts til DNS-opdatering, certifikatjobs, deploy hooks, gamle PHP-værktøjer, CI-variabler, planlagte opgaver og værktøjer, der er fulgt med en kundekonto. Disse integrationer kan forblive usynlige, indtil en deployment, fornyelse eller gendannelsesprocedure får brug for dem.

Det bør behandles som et mindre driftssikkerhedsprojekt og ikke blot som en søg og erstat-operation på credentials. Hvert job skal have en ejer, et API-token med passende afgrænsede rettigheder, en testet overgang og dokumentation for, hvor den nye hemmelighed opbevares.

Det fjerner Cloudflare

Cloudflare udfasede godkendelse med Service Keys den 19. marts 2026. Efter den 30. september understøttes API-kald med X-Auth-User-Service-Key ikke længere. Erstatningen er API Tokens, som giver finmaskede rettigheder, ressourceafgrænsning, udløbsdato, IP-begrænsninger og mulighed for uafhængig tilbagekaldelse.

Origin CA-nøgler er en del af samme oprydning. De begynder typisk med v1.0- og sendes i Service Key-headeren, når scripts kalder API'et til Origin CA-certifikater. Cloudflare oplyser, at disse nøgler kan tilgå alle konti, som brugeren har adgang til. Til certifikathåndtering skal de erstattes af et API-token med Zone → SSL and Certificates → Edit.

Hvis I bruger cloudflared, anbefaler Cloudflare en version fra november 2022 eller senere, da disse versioner bruger API Tokens. Teams, der bruger origin-ca-issuer, skal have en release, som understøtter godkendelse med API Tokens.

Find afhængigheden, før I vælger tokenet

Begynd med repositories, deployment-mapper, CI-konfiguration, cron-definitioner, infrastructure as code og secret stores. Følgende søgninger er fortsat nyttige:

rg -n 'X-Auth-User-Service-Key|v1\.0-' .
rg -n 'origin-ca|/certificates|cloudflare' .

Et match er kun begyndelsen. Registrér, hvad jobbet ændrer, hvilke konti og zoner det tilgår, hvor det kører, hvor ofte det kører, hvem der opdager fejl, og hvor dets credential indsættes. Søg også i dashboards til CI og hosting: En ældre hemmelighed findes muligvis slet ikke i versionsstyringen.

Gå ikke ud fra, at alle resultater er aktive. Omvendt bør I heller ikke slette et gammelt credential, blot fordi ingen genkender det. Spor den kaldende komponent, gennemgå de seneste joblogs, hvor de er tilgængelige, og identificér en sikker test, før I ændrer adgangen til produktion.

Vælg det snævreste praktisk anvendelige token

Cloudflare adskiller rettigheder fra ressourcer. En DNS-opdatering kan have brug for Zone DNS Edit, men kun til én navngiven zone. Et rapporteringsjob kan have brug for Zone DNS Read. Et Origin CA-workflow kræver certifikatrettigheder, ikke generel DNS-adgang.

Brug som udgangspunkt ét token pr. automatisering. Det gør ejerskab, rotation og tilbagekaldelse tydeligere og forhindrer, at en lækage i én kundes workflow eksponerer uvedkommende websites.

Automatisering Udgangspunkt for rettigheder Ejerskab af token Dokumentation for overgangen
Deploy hook til DNS Zone DNS Edit for navngivne zoner Kontotoken til varig, fælles automatisering Kontrolleret opdatering af record og rollback
DNS-inventar eller -overvågning Zone DNS Read Kontotoken eller snævert afgrænset brugertoken Læs den forventede zone, og afvis en anden
Job til Origin CA-certifikater Zone SSL and Certificates Edit Kontotoken, når endpointet understøtter det Test udstedelse i det tiltænkte workflow
Administrators midlertidige script Minimal, opgavespecifik adgang Brugertoken Udfør den tiltænkte handling, og tilbagekald derefter tokenet
En indledende matrix til tokendesign. Bekræft det præcise endpoint og ressourceomfanget, før I udsteder et credential til produktion.

Account API tokens fungerer som service principals og er ikke knyttet til en medarbejder. Cloudflare anbefaler dem til varige integrationer såsom CI/CD, men kompatibiliteten med det enkelte endpoint skal kontrolleres. Det kræver Super Administrator-rettigheder at oprette et. Brugertokens er fortsat nyttige til ad hoc-arbejde, der udføres på vegne af en bestemt administrator.

Hvis den maskine, der kører jobbet, har en stabil udgående IP-adresse, bør I overveje en IP-begrænsning. Angiv en udløbsdato, hvor rotation er realistisk i driften. Cloudflare viser kun tokenets hemmelige værdi én gang, så placér den direkte i en secret manager, et lager til CI-variabler eller en platform vault – aldrig i et repository eller et fælles driftsnotat.

Test aktivitet, afgrænsning og det faktiske job

Til et brugerejet token tilbyder Cloudflare følgende statuskontrol:

curl "https://api.cloudflare.com/client/v4/user/tokens/verify" \
  --header "Authorization: Bearer <API_TOKEN>"

Til et kontoejet token skal I bruge det kontospecifikke endpoint til verificering:

curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/tokens/verify" \
  --header "Authorization: Bearer <API_TOKEN>"

Et active-svar bekræfter, at credentialet virker. Det beviser ikke, at rettighederne og ressourcerne passer til jobbet. Følg op med en smoke test på endpointniveau. Ved læseadgang skal I anmode om den forventede ressource og bekræfte, at adgang til en uvedkommende zone afvises. Ved skriveadgang skal I bruge en kontrolleret ændring med en dokumenteret rollback. Kør derefter automatiseringen fra dens faktiske miljø, så I også tester indsættelse af hemmeligheden, netværksbegrænsninger og runtime-konfiguration.

En praktisk migrationsrækkefølge

  1. Kortlæg headere, nøglemønstre, hjælpeværktøjer, planlagte jobs og eksternt lagrede variabler.
  2. Knyt hver aktiv kaldende komponent til dens forretningsformål, ejer, konto, zoner og nødvendige handlinger.
  3. Opret et særskilt navngivet token med minimale rettigheder, passende ejerskab og relevante begrænsninger.
  4. Udrul det sammen med en rollback-plan, og test fra det faktiske runtime-miljø.
  5. Fjern den gamle header, overvåg den næste normale kørsel, og tilbagekald først den ældre nøgle, når der er redegjort for alle afhængigheder.
  6. Registrér tokenets ejer, afgrænsning, lagringssted, udløbsdato og rotationsprocedure.

Deadlinen skaber tidspres, men gevinsten varer ved: færre delte hemmeligheder, tydeligere operationelt ejerskab og automatisering, der er nemmere at supportere.

Brug for et ekstra sæt øjne?

Hvis jeres Cloudflare-opsætning spænder over kundekonti, ældre certifikatværktøjer eller flere deploymentsystemer, kan Greg hjælpe med at kortlægge afhængighederne, designe fornuftige tokenafgrænsninger og styre en testet overgang. Tal med Greg om jeres gennemgang af Cloudflare-tokens.

Relateret indhold på GrN.dk

Brug for hjælp til denne type arbejde?

Tal med Greg om jeres gennemgang af Cloudflare-tokens Kontakt Greg.

Kilder

Sidst ændret
2026-08-30

Tags