Af Greg Nowak. Senest opdateret 2026-08-15.
De fleste permanente adgangsoplysninger var aldrig tænkt som permanente. En udvikler føjer en API-nøgle til GitHub Actions, et bureau opretter et Cloudflare-token til et deployment-script, og det akutte problem er løst. Flere måneder senere fungerer automatiseringen stadig – men ingen kan med sikkerhed sige, hvem der ejer adgangsoplysningen, hvor den bruges, eller hvordan den kan udskiftes forsvarligt.
En udløbsdato hjælper, men det bedre spørgsmål er: Har denne workload overhovedet brug for en gemt secret? For GitHub Actions, der kalder OpenAI, er svaret ofte nej. Til Cloudflare-automatisering kan et token stadig være den rette løsning, men det bør have snævre rettigheder, være begrænset til bestemte ressourcer, have en bevidst fastsat levetid og en afprøvet procedure for udskiftning.
Udløb er kun én del af et godt credential-design
Gode adgangsoplysninger besvarer fem driftsmæssige spørgsmål, før de når produktion:
- Ejer: Hvilken person eller hvilket team har ansvaret?
- Formål: Hvilket job, hvilken integration eller hvilket deployment bruger dem?
- Omfang: Hvilke handlinger og ressourcer giver de adgang til?
- Levetid: Hvornår skal de holde op med at virke eller gennemgås?
- Udskiftning: Hvordan kan de ændres uden unødvendig nedetid?
Hvis svarene kun findes i én udviklers hukommelse, udgør adgangsoplysningerne allerede en driftsmæssig risiko. En secrets manager kan beskytte selve værdien, men kan ikke afhjælpe uklart ejerskab eller for omfattende rettigheder.
| Workload | Foretrukken tilgang | Vigtig kontrol |
|---|---|---|
| GitHub Actions, der kalder OpenAI | Ombyt GitHubs OIDC-identitet til et kortlivet OpenAI-adgangstoken | Hav kun tillid til et bestemt repository, en bestemt branch, workflow-fil og environment |
| Automatisering af Cloudflare-deployments | Brug et opgavespecifikt API-token | Begræns rettigheder samt konto- eller zoneressourcer |
| Cloudflare-job på en fast runner | Brug et afgrænset token med TTL og filtrering efter klientens IP-adresse | Kontrollér, at runneren har forudsigelige egress-adresser |
| Ældre integration, der kræver en statisk secret | Behold den midlertidigt med en angivet ejer og udskiftningsdato | Dokumentér alle brugere af den, før den roteres |
OpenAI-adgang fra GitHub Actions kan være kortlivet
OpenAI dokumenterer nu workload identity federation til GitHub Actions. I stedet for at gemme en OpenAI API-nøgle med lang levetid som en repository secret anmoder workflowet om et signeret OIDC-token fra GitHub. OpenAI validerer identiteten og ombytter den til et kortlivet OpenAI-adgangstoken.
Workflowet skal have tilladelse til at anmode om sin OIDC-identitet:
permissions:
id-token: write
contents: readid-token: write giver ikke skriveadgang til indholdet i repositoryet. Det giver kun jobbet mulighed for at anmode om et OIDC-token. contents: read er normalt nødvendigt for actions/checkout.
Det vigtige arbejde foregår i trust-konfigurationen. Hav ikke tillid til en hel GitHub-organisation, når kun ét deployment-workflow har brug for adgang. OpenAI understøtter matchning af claims, herunder repository, Git ref, workflow-reference og GitHub environment. Ved privilegeret adgang anbefaler dokumentationen at bruge den specifikke workflow_ref frem for at basere sig på navnet på et genanvendeligt workflow.
Brug en separat OpenAI-servicekonto til workflowet, og begræns dens API-rettigheder, hvor det er praktisk muligt. Hold produktionsapplikationer og CI/CD bag forskellige adgangsgrænser. Provider-ID, audience og servicekonto-ID kan gemmes som GitHub Actions-variabler, fordi de identificerer konfigurationen; de er ikke bearer secrets. GitHubs OIDC-token og det ombyttede OpenAI-token må aldrig skrives til logs.
Cloudflare-tokens kræver afgrænsning, begrænsninger og en ejer
Cloudflare anbefaler så vidt muligt API-tokens frem for globale API-nøgler. Et token kan begrænses efter rettighedsgruppe, adgangsniveau og ressource. Et DNS-automatiseringsjob for én zone bør ikke have redigeringsadgang til samtlige zoner på kontoen.
Vælg Read, når jobbet kun henter oplysninger. Tildel kun skrive- eller redigeringsadgang, når jobbet rent faktisk ændrer konfigurationen. Til virksomhedsejet automatisering bør du overveje et kontoejet API-token frem for et brugerejet token, når de nødvendige endpoints understøtter det. Dermed bliver kritisk infrastruktur ikke bundet til en medarbejders eller et bureaus konto.
Cloudflare understøtter også filtrering efter klientens IP-adresse og begrænsning af levetiden. Uden et konfigureret sluttidspunkt udløber et token ikke. Dashboardet bruger datoer, der begynder kl. 00.00 UTC; API'et understøtter mere præcise UTC-timestamps. Betragt udløbet som et planlagt tidspunkt for fornyelse, ikke som en uventet fejl: Registrér ejeren, og opret en alarm i god tid, før tokenet holder op med at virke.
Kontrollér efter oprettelsen, at tokenet er aktivt, før du deployer det:
curl "https://api.cloudflare.com/client/v4/user/tokens/verify" \
--header "Authorization: Bearer <API_TOKEN>"Rotation og udløb løser forskellige problemer
Udløb begrænser, hvor længe glemte adgangsoplysninger kan forblive brugbare. Rotation erstatter den aktive secret. Du har brug for både en politik for levetid og en procedure for udskiftning.
Cloudflare kan rotere et token og bevare dets rettigheder, men rotationen ugyldiggør øjeblikkeligt den tidligere secret. Det er nyttigt under en hændelse, men kan få de systemer, der endnu ikke har modtaget erstatningen, til at svigte. Ved planlagt rotation med lav risiko bør du oprette endnu et snævert afgrænset token, opdatere og teste hver enkelt bruger og derefter tilbagekalde det gamle token. Brug øjeblikkelig rotation, når den gamle værdi kan være kompromitteret, og hurtig ugyldiggørelse er vigtigere end en problemfri overgang.
En migrationsrækkefølge, der undgår unødvendig nedetid
- Registrér OpenAI-nøgler samt Cloudflare-nøgler og -tokens sammen med deres ejere, brugere, rettigheder og senest kendte anvendelse.
- Flyt egnede GitHub Actions-workloads fra gemte OpenAI API-nøgler til workload identity federation.
- Erstat globale Cloudflare-nøgler og bredt anvendte delte tokens med opgavespecifikke, bruger- eller kontoejede tokens.
- Tilføj TTL- og klient-IP-begrænsninger, hvor workloaden har en kendt levetid eller en forudsigelig netværksoprindelse.
- Test udskiftning og rollback, før du tilbagekalder eksisterende adgangsoplysninger til produktion.
- Tilføj påmindelser om fornyelse, og gennemgå registreringen, hver gang et workflow, en leverandør eller en teamejer ændres.
Det er i mindre grad en øvelse i secret management end i ejerskab af infrastrukturen. Målet er ikke at rotere alle adgangsoplysninger efter en vilkårlig kalender. Det er at fjerne gemte secrets, hvor det er muligt, og gøre alle tilbageværende adgangsoplysninger forståelige, afgrænsede og udskiftelige.
Hvis dit team har overtaget GitHub-workflows, Cloudflare-automatisering eller API-integrationer, som ingen har lyst til at røre ved, kan Greg hjælpe med at kortlægge afhængighederne og planlægge en mere sikker migrering uden at gøre produktionen til et sikkerhedseksperiment.
Relateret indhold på GrN.dk
- Copilot har nu målinger på repository-niveau. Hvad bør teams måle?
- Den risikable del af pilotprojekter med AI-workflows er ofte OAuth-skærmen
- En voice agent er først klar, når overdragelsen til et menneske fungerer
Har du brug for hjælp til denne type arbejde?
Planlæg en gennemgang af adgangsoplysningerne med Greg. Kontakt Greg.
