Gem legitimationsoplysninger ét sted

Brug navngiven nøglelagerlegitimation til private repositories, administrerede værter og Ansible Vault-adgangskoder. Gem automatiseringskode og ikke-følsom konfiguration i Git, mens skabelonen refererer til nødvendig legitimation. En reference gør genbrug og rotation lettere end indlejrede værdier i scripts. Det fjerner ikke behovet for at beskytte, hvem der kan redigere eksekverbar kode, da koden kører med den adgang, den får.

Nej. Ansible Vault beskytter krypteret Ansible-indhold; en opgaveskabelon kan bruge en Vault-adgangskode fra Semaphores nøglelager til at åbne det. HashiCorp Vault er en separat ekstern Pro-lagringsmulighed til nøglelagerhemmeligheder. Den optagede forhåndskontrol på siden viser Ansible Vault-adgangskodevejen, ikke en forbindelse til HashiCorp Vault. Vurder ekstern lagring separat med en midlertidig legitimationspost før driftsbrug.

Lokale nøglelagerværdier bruger den konfigurerede kryptering af adgangsnøgler til databaselagring. Indstil og beskyt krypteringskonfigurationen korrekt, og medtag dens gendannelseskrav i sikkerhedskopieringsproceduren. Kryptering i hvile er én del af designet: autoriseret eksekvering skal stadig bruge legitimationsoplysningerne. Beskyt server, runtime, administratoradgang og logge frem for at betragte en krypteret databaseværdi som utilgængelig for al kode og alle ingeniører.

De dokumenterede miljø- og filkilder opløses af Semaphore-serveren, når en opgave kræver nøglen, også ved eksekvering på en ekstern runner. Filkilder skal følge den tilladte hemmelighedsmappe og det dokumenterede værdiformat. En senere opgave kan hente en roteret kildeværdi uden omskrivning af skabelonen. Antag ikke, at en rå nøglefil på runneren implementerer denne serversidemekanisme.

Ja. Pro understøtter HashiCorp Vault og OpenBao som eksterne hemmelighedskilder. Enterprise tilføjer andre understøttede hemmelighedsintegrationer. Konfigurer udbyderen, og referer til legitimationen via nøglelageret frem for at gemme værdien i Git. Følg udbydervejledningen til autentifikation og hemmelighedsstier, og test jobbet med den tilsigtede legitimation.

Skabeloner refererer til navngivne legitimationsoplysninger frem for at indlejre en separat adgangskode eller nøgle i hvert job. Opdater legitimationsposten eller dens konfigurerede kilde, og kontroller derefter de refererende repositories og inventarer. Test en repræsentativ opgave efter rotation, så autentifikationsfejl opdages før næste planlagte produktionskørsel.

Stol ikke på en universel maskeringsgaranti. En playbook eller et script kan udskrive følsomme variabler, kommandoargumenter eller API-svar i outputtet. Log bevidst, brug værktøjets passende muligheder til håndtering af hemmeligheder, og gennemgå repræsentativt fejloutput såvel som succesoutput. Begræns adgang til logge og eksporterede poster efter deres indhold. Sikker lagring af en værdi styrer ikke i sig selv alt, hvad eksekveringskoden udskriver.

Ja. Giv legitimationen et navn i nøglelageret, og vælg den, hvor repository, inventar eller skabelon kræver typen. Jobbene refererer til den konfigurerede post frem for at have egen kopi i Git. Brug separat legitimation, når målsystemer kræver forskellige identiteter. Se opgaveskabeloner.