- GitHub Actionsin salaisuudet ovat salattuja, laajuudeltaan rajattuja ympäristömuuttujia, joiden laajuus on määritettävä huolellisesti tietovaraston, ympäristön ja organisaation tasolla.
- Turvallisuus perustuu vähiten käyttöoikeuksia koskevaan periaatteeseen, lokien paljastumisen välttämiseen, salaisuuksien kiertämiseen ja auditointiin sekä arkaluonteisten tuotantoympäristöjen eristämiseen.
- Skriptien injektoinnista, kolmansien osapuolten toimista ja itse isännöidyistä suoritusohjelmista aiheutuvat riskit edellyttävät kiinnittämistä, koodin tarkistusta sekä tiukkoja suoritus- ja käyttöoikeuskäytäntöjä.
- OpenID Connect ja ulkoiset salaisuuksien hallintaohjelmat auttavat korvaamaan pitkäikäiset tunnistetiedot lyhytikäisillä tokeneilla ja keskitetyillä, auditoitavilla salaisilla työnkuluilla.
Salaisuuksien hallinta GitHub Actionsissa on yksi niistä aiheista, jotka ensi silmäyksellä vaikuttavat yksinkertaisilta, mutta muuttuvat nopeasti kriittiseksi tietoturvaongelmaksi, kun prosessisi alkavat olla yhteydessä tuotantoympäristöön, pilvipalveluntarjoajiin ja kolmansien osapuolten palveluihin. CI/CD-työnkulkusi käsittelevät rutiininomaisesti API-avaimia, tietokannan salasanoja, SSH-avaimia, tokeneita ja muita arvoja, ja jokainen näistä arvoista on mahdollinen hyökkääjän sisäänpääsykohta, jos niitä käsitellään huolimattomasti.
Tässä oppaassa syvennymme siihen, miten salaisuudet toimivat GitHub Actionsissa, miten ne konfiguroidaan tietovarasto-, ympäristö- ja organisaatiotasolla, miten työnkulkuja voidaan suojata vuodoilta ja toimitusketjuhyökkäyksiltä sekä milloin on järkevää ottaa käyttöön ulkoisia salaisuuksien hallintaohjelmia. Ajatuksena on antaa sinulle käytännöllinen, tietoturvaan keskittyvä yleiskatsaus, jotta voit pitää prosessisi nopeina. ja turvallista tekemättä päivittäisestä työstä päänsärkyä.
Mitä tarkalleen ottaen ovat GitHub Actionsin salaisuudet?
GitHub Actionsissa "salaisuus" on salattu ympäristömuuttuja, jonka arvo on piilotettu käyttöliittymältä, lokeilta ja tietovaraston sisällöltä. Määrittelet sen kerran (repo-, organisaatio- tai ympäristötasolla) ja viittaat siihen sitten työnkulun YAML-muodossa käyttämällä secrets. kontekstissa, joten myyntiputkesi voivat käyttää arkaluontoisia arvoja ilman, että niitä koskaan vahvistetaan koodikantaan.
GitHub salaa salaisuudet vahvalla kryptografialla (Libsodium-sinetöidyt laatikot) jo ennen kuin ne edes päätyvät GitHubin palvelimille, ja arvot puretaan vasta suorituksen aikana työnkulun suorittimella. Kun salaisuudet on luotu, niitä ei voi muuttaa käyttöliittymästä: voit korvata ne, mutta et voi lukea niitä takaisin, ja kun ne näkyvät lokeissa, ne peitetään automaattisesti *** missä vain mahdollista.
Tässä mallissa on joitakin tärkeitä suunnittelurajoituksia, jotka sinun on tiedettävä: salaisuuksia ei voi hakea käyttöliittymän tai API:n kautta, ne on poistettu lokeista ja ne sijaitsevat tietyssä näkyvyysalueessa: tietovarasto, tietovaraston sisäinen ympäristö tai organisaatio. Oikean laajuuden valitseminen on ensimmäinen suuri päätös järkevän salaisuusstrategian kannalta.
Tietovarasto-, ympäristö- ja organisaatiosalaisuudet
GitHub tarjoaa salaisuuksille kolme pääkerrosta: tietovaraston salaisuudet, ympäristön salaisuudet ja organisaation salaisuudet, joilla kullakin on omat käyttötapauksensa ja etusijasääntönsä. Ymmärtämällä, miten ne ovat vuorovaikutuksessa keskenään, voit välttää konflikteja ja pitää arkaluontoiset arvot siellä missä ne kuuluvat.
Tietovarastotason salaisuudet
Tietovaraston salaisuudet on sidottu yhteen tietovarastoon ja ne ovat kaikkien kyseisen tietovaraston työnkulkujen käytettävissä. Ne sopivat täydellisesti projektikohtaisille arvoille, kuten palvelun API-avaimelle, käyttöönottosalasanoille tai vain kyseisen repositorion käyttämälle webhook-tunnukselle.
Voit luoda tietovaraston salaisuuden käyttöliittymästä siirtymällä kohdetietovarastoon, avaamalla ”Asetukset” → ”Salaisuudet ja muuttujat” → ”Toiminnot” ja napsauttamalla sitten ”Uusi tietovaraston salaisuus”. Annat sille isolla kirjaimella kirjoitetun nimen alaviivoilla (esimerkiksi PAYMENTS_API_KEY), liitä salainen arvo ja tallenna; siitä hetkestä lähtien työnkulut voivat käyttää sitä nimellä ${{ secrets.PAYMENTS_API_KEY }}.
Jokainen, jolla on kirjoitusoikeudet repositorioon, voi viitata näihin salaisuuksiin työnkuluissa, joten repositorion käyttöoikeuksista tulee osa tietoturvatarinaasi. Jos annat kirjoitusoikeuden useille käyttäjille, annat heille implisiittisesti oikeuden käyttää kaikkia automaation tietovaraston salaisuuksia.
Ympäristökohtaisia salaisuuksia
Ympäristösalaisuudet sijaitsevat yhden tason tietovaraston salaisuuksien alapuolella ja niiden avulla voit määrittää erilaisia arvoja ympäristöä kohden, kuten dev, stagingtai production. Ne on liitetty nimettyyn ympäristöön, ja niitä voidaan suojata säännöillä, kuten pakollisilla tarkistajilla tai odotusajastimilla, ennen kuin työ voidaan suorittaa niitä vastaan.
Voit määrittää nämä siirtymällä kohtaan ”Asetukset” → ”Ympäristöt”, luomalla tai valitsemalla ympäristön ja lisäämällä sitten salaisuuksia kyseisen ympäristön kokoonpanoon. Salaiset nimet käyttävät edelleen secrets. konteksti (esimerkiksi secrets.PROD_DB_PASSWORD), mutta arvot tulevat saataville vain töille, jotka suoritetaan nimenomaisesti kyseisessä ympäristössä.
Keskeinen yksityiskohta on, että ympäristösalaisuudet ohittavat tietovaraston salaisuudet, kun niillä on sama nimi. Eli voit määritellä DB_PASSWORD repotasolla paikallista/testikäyttöä varten ja sitten eri DB_PASSWORD tuotantoympäristön salaisuutena, jolla on etusija tuotantotöissä, muuttamatta työnkulun syntaksia.
Ympäristöt mahdollistavat myös suojaussäännöt, kuten "pakolliset tarkistajat" tai "vain tietyistä haaroista", mikä on uskomattoman hyödyllistä, kun haluat rajoittaa pääsyä arkaluontoisimpiin salaisuuksiin. Esimerkiksi tuotantoympäristö saattaa vaatia DevOpsin hyväksynnän ennen kuin sen salaisuuksia käyttäviä töitä voidaan suorittaa.
Organisaationlaajuiset salaisuudet
Organisaation salaisuudet jaetaan useiden tietovarastojen kesken organisaatiossa, ja ne sopivat erinomaisesti laajasti uudelleenkäytettäville tunnistetiedoille, kuten jaetulle Slack-webhookille tai keskitetyn metriikan API-tunnukselle. Ne vähentävät päällekkäisyyksiä ja helpottavat rotaatiota, koska päivität salaisuuden kerran ja lopuksi kuluttavat repot poimivat uuden arvon.
Ylläpitäjät luovat ne organisaation ”Asetukset” → ”Salaisuudet ja muuttujat” → ”Toiminnot” -osiossa napsauttamalla ”Uusi organisaation salaisuus” ja valitsemalla sitten, millä tietovarastoilla on pääsy kyseiseen salaisuuteen. Voit sallia kaikki nykyiset ja tulevat repot tai rajoittaa sen tiukasti tiettyyn osajoukkoon.
On olemassa ennakkotapausketju, joka sinun tulisi pitää mielessä: organisaation salaisuus < tietovaraston salaisuus < ympäristön salaisuus, kun nimet törmäävät. Toisin sanoen ympäristön salaisuus voittaa tietovaraston salaisuuden, joka puolestaan voittaa organisaation salaisuuden, jos niillä kaikilla on sama avain.
Kuinka salaisuudet käyttäytyvät suorituksen aikana
Kun salaisuudet on määritelty, ne tulevat töiden saataville suorituksen aikana secrets kontekstissa ja ne injektoidaan ympäristömuuttujina, kun niihin viitataan. Niitä ei viedä oletuksena laajasti jokaiseen vaiheeseen; ne liitetään erikseen omaan env: lohkot tai välitä ne toimintoihin, jotka tukevat salaisuuksia syötteinä.
GitHub tarjoaa myös erityisen GITHUB_TOKEN työnkulkuajoa kohden, joka ei ole manuaalisesti määritetty salaisuus, mutta toimii sellaisena ja jota käytetään usein API-kutsuissa tai tietovaraston toiminnoissa. Voit (ja sinun pitäisi) hienosäätää tämän tunnuksen käyttöoikeuksia käyttämällä permissions: lohko niin, että sillä on kullekin työlle tarvittava vähimmäislaajuus.
Vahingossa tapahtuvan altistumisen vähentämiseksi GitHub peittää kaikki rekisteröityä salaisuutta vastaavat arvot työnkulkulokeissa korvaamalla ne arvolla ***. Tämä maskaus tehdään suorittimen puolella, ja se toimii yleensä hyvin raakamerkkijonoille, mutta se olettaa, että tulosteessa näkyy tarkka salaisuuden arvo. Jos muunnat salaisuuden (esimerkiksi base64-koodaamalla sen tai upottamalla sen strukturoituun JSON-muotoon), maski ei välttämättä tunnista sitä.
Koska peittäminen on parasta mahdollista eikä matemaattisesti taattua, sinun tulisi suunnitella työnkulut siten, että salaisuuksia tai niiden johdannaisia ei tulosteta lokeihin lainkaan, ja käyttää peittämiskomentoja suorituksen aikana luomillesi lisäarvoille. Käsittele lokeja mahdollisina näkyvinä useammille ihmisille kuin odotat ja oleta, että kaikki tulostettu voi vuotaa.
Käytännön käyttö: salaisuuksien viittaaminen työnkuluissa
Useimmiten salaisuuksia käytetään yhdistämällä ne ympäristömuuttujiin tietyssä vaiheessa tai työssä ja antamalla sitten komentosarjojen tai työkalujen lukea ympäristöstä. Klassinen kaava näyttää tältä:
– nimi: Käyttöönotto API:in
env:
API_KEY: ${{ salaisuudet.PROD_API_KEY }}
juoksu: |
curl -H “Valtuutus: Haltija $API_KEY” https://api.example.com/deploy
Voit myös kirjoittaa tiedostoon salaisuuden juoksijalla, mikä on turvallinen niin kauan kuin tiedosto pysyy työn lyhytaikaisessa työtilassa eikä sitä vahvisteta tai ladata palvelimelle artefaktina. Esimerkiksi SSH-avaimen tallentaminen:
– nimi: Kirjoita SSH-avain tiedostoon
komentotulkki: bash
env:
SSH_KEY: ${{ salaisuudet.SSH_KEY }}
juoksu: |
kaiku “$SSH_KEY” > avain
chmod 600 -avain
Lokitiedostoista näet vain varsinaisen komentotulkkikomennon (jossa on $SSH_KEY), mutta ei itse salaista arvoa, joka sensuroidaan tai piilotetaan. Koska GitHubissa isännöidyt suoritusohjelmat tuhotaan työn päätyttyä, väliaikainen tiedosto katoaa virtuaalikoneen mukana; itse isännöidyissä suoritusohjelmissa on oltava paljon tarkempi siivoamisen suhteen.
GitHub Actionsin salaisuuksien parhaat käytännöt
Pelkän salaisuuksien käyttöliittymän käyttö ei riitä; tarvitset joukon tapoja ja suojatoimia räjähdyksen säteen minimoimiseksi, jos jokin menee pieleen. GitHub tarjoaa monia nuppeja, mutta sinun on itse käännettävä niitä oikein.
Käytä vähiten etuoikeuksien periaatetta
Jokaisen salaisuuden ja jokaisen tunnuksen tulisi myöntää vain ne käyttöoikeudet, jotka ovat ehdottoman välttämättömiä tietylle tehtävälle. Ulkoisia palveluita varten luo erilliset tunnistetiedot, joilla on rajatut käyttöoikeudet (esimerkiksi ”vain käyttöönotto” tai ”vain luku -mittarit”) sen sijaan, että käyttäisit uudelleen täysiä järjestelmänvalvojan avaimia.
Sama periaate pätee sisäänrakennettuun GITHUB_TOKEN; aseta oletusoikeudet minimiin (usein contents: read) ja sitten nostaa käyttöoikeuksia vain tietyissä töissä, jotka tarvitsevat enemmän. Voit määrittää tämän käyttämällä permissions: työnkulun tai työn tasolla oleva osio, jotta vaarantunut työ ei voi tehdä hiljaisia kirjoituksia.
Vältä salaisuuksien tulostamista tai koodaamista lokitiedostoihin
Salaisuuksia ei tule koskaan kovakoodata työnkulkutiedostoihin tai tulostaa selkotekstinä virheenkorjauksen helpottamiseksi. Jos sinulla on muita arkaluontoisia arvoja, joita ei ole rekisteröity GitHub-salaisuuksiksi (esimerkiksi suorituksen aikana luotu tunnus), voit silti pyytää suorittajaa käsittelemään niitä salaisuuksina komentosyntaksin avulla:
kaiku “::lisää-maski::$GENERATED_TOKEN”
Rakenteiset blobit, kuten JSON, XML tai suuret YAML-dokumentit, ovat erityisen vaarallisia salaisuuksina, koska GitHubin maskeri perustuu tarkkaan merkkijonojen täsmäytykseen. Jos laitat useita arkaluontoisia arvoja yhden ison JSON-merkkijonon sisään ja käytät sitä yhtenä salaisuutena, pienetkin muotoilumuutokset voivat aiheuttaa peittämisen epäonnistumisen. Sen sijaan määritä erilliset salaisuudet jokaiselle arkaluonteiselle kentälle.
Tarkista lokit aina työnkulkuja testatessasi ja kiinnitä erityistä huomiota virheilmoituksiin ja pinonjäljityksiin. Jotkin työkalut toistavat mielellään komentoja ja lipuja stderr-järjestelmään, mikä voi vahingossa sisältää salaisia arvoja, ellet nimenomaisesti vältä tätä kaavaa.
Kierrätä ja tarkasta salaisuudet säännöllisesti
Salaisten tietojen rotaatio on työlästä, mutta siitä ei voi tinkiä, jos turvallisuus on tärkeää; tunnistetietojen pitäminen muuttumattomina vuosien ajan lisää hyökkääjien mahdollisuuksia. Kohtuullinen lähtökohta on kierrättää kriittisimpiä tuotantosalaisuuksia kuukausittain, riskialttiimpia muutaman kuukauden välein ja kaikkea muuta vähintään neljännesvuosittain.
Voit automatisoida osan tästä käyttämällä GitHubin REST-rajapintaa salaisuuksille, jonka avulla voit hakea tietovaraston tai organisaation julkisen avaimen ja ladata uusia salattuja arvoja. Tämä on erityisen kätevää suurille organisaatioille, joilla on useita repositorioita, jotka jakavat palvelutilejä ja joiden on kierrätettävä niitä nopeasti tapahtumien varalta.
Auditointi on yhtä tärkeää: tarkista säännöllisesti määritettyjen salaisuuksien luettelo ja poista ne, joita ei enää käytetä, ja käytä GitHubin tietoturva-/auditointilokeja tapahtumien seuraamiseen, kuten org.update_actions_secret. Näin tiedät kuka muutti mitä ja milloin, ja voit yhdistää epäilyttävät muutokset muuhun toimintaan.
Käytä ympäristöön perustuvaa erottelua
Ympäristösalaisuudet ovat yksi helpoimmista tavoista vahvistaa prosessiasi, koska niiden avulla voit eristää erittäin arkaluontoiset arvot (kuten tuotantotietokannan tunnistetiedot) nimenomaisten hyväksyntöjen taakse. Voit vaatia ihmistarkistajia, rajoittaa sitä, mitkä haarat voivat ottaa käyttöön, ja jopa lisätä jäähyaikoja ennen käyttöönoton aloittamista.
Yleinen kaava on, että staging ympäristö, jossa on lieviä suojauksia ja production ympäristö, jossa on tiukemmat säännöt ja erilliset salaisuudet. Työnkulut määrittelevät sitten työt, jotka kohdistuvat kuhunkin ympäristöön varmistaen, että tuotesalaisuuksia ei koskaan käytetä vahingossa testitöissä.
Valitse selkeät nimeämiskäytännöt
Salaisuuksien hyvä nimeäminen säästää sinut turhauttavalta arvailulta ja vaarallisilta sekaannuksilta. Yleisnimien sijaan, kuten API_KEY, koodaa palvelu ja ympäristö nimeen, esimerkiksi STRIPE_PROD_API_KEY or AWS_STAGING_DEPLOY_ROLE_ARN.
Tiimit, jotka käsittelevät useita palveluita, omaksuvat usein seuraavanlaisen kaavan: <SERVICE>_<ENV>_<PURPOSE>. Joten sinulla saattaa olla SLACK_PROD_ALERTS_WEBHOOK, GCP_DEV_BUILD_SERVICE_ACCOUNTja DB_STAGING_PASSWORDTämä tekee paljon selvemmäksi, mitä salaisuutta tulisi käyttää missäkin työssä.
Suojautuminen komentosarjojen injektoimiselta sisällöltä ja kolmansien osapuolten riskeiltä
Salaisuudet eivät ole vaarassa ainoastaan väärän konfiguroinnin vuoksi, vaan ne ovat myös houkuttelevia kohteita skriptien injektoinnille työnkulkuihin ja haitallisille tai vaarantuneille kolmansien osapuolten toimille. Yksikin haavoittuvainen askel voi paljastaa kaikki työssä käytettävissä olevat salaisuudet, jos et ole varovainen.
Skriptien injektoinnin lieventäminen inline-vaiheissa
Kun interpoloit epäluotettavaa dataa (kuten pull-pyyntöjen otsikoita, haaran nimiä tai ongelmakommentteja) suoraan komentoskripteihin, avaat oven injektoinnille. Esimerkiksi PR-otsikko voitaisiin muotoilla niin, että se murtautuu ulos komennosta ja suorittaa mielivaltaista komentotulkkikoodia juoksijassasi.
Turvallisin tapa on käsitellä monimutkaista logiikkaa ensimmäisen osapuolen tai hyvin auditoiduissa JavaScript/TypeScript-toiminnoissa ja välittää epäluotettavat arvot syötteinä sen sijaan, että ne sisällytettäisiin komentotulkkiin. Tässä mallissa toiminto vastaanottaa merkkijonoja argumentteina ja käsittelee ne luomatta kaapattavia komentosarjoja.
Jos sinun on käytettävä inline-komentotulkkia, tallenna ensin epäluotettavat arvot ympäristömuuttujiin ja viittaa sitten näihin muuttujiin, mieluiten lainausmerkeissä. Tällä tavoin arvoa käsitellään datana eikä osana komentosarjan rakennetta, mikä tekee injektioyritysten onnistumisen todennäköisyydestä paljon epätodennäköisempää.
Kolmannen osapuolen toimintojen kiinnittäminen ja tarkastelu
Jokainen työnkulkuusi tuomasi kolmannen osapuolen toiminto suoritetaan työympäristön ja salaisuuksien käyttöoikeudella, joten sinun tulisi käsitellä niitä koodiriippuvuuksina, jotka vaativat tarkastelua. Haitallinen tai vaarantunut toiminto voi lukea salaisuuksia ja lähettää ne hyökkääjälle yhdellä HTTP-kutsulla.
Paras käytäntö on kiinnittää toiminnot täyden commit SHA:n avulla pelkkien tagien tai haarojen sijaan, koska tageja voidaan siirtää tai korvata. SHA viittaa koodin tarkkaan versioon, mikä tekee hyökkääjän paljon vaikeammaksi lisätä uusia toimintoja hiljaisesti ilman, että päivität työnkulkua.
Ennen toiminnon käyttöä silmäile sen lähdekoodi (tai ainakin tee tietoturvatarkistus) varmistaaksesi, että se käsittelee salaisuuksia vastuullisesti eikä kirjaa niitä lokiin tai lähetä niitä tuntemattomiin päätepisteisiin. Jos käytät markkinapaikkatoimintoja, varmista julkaisija mahdollisuuksien mukaan ja luota Dependabotiin haavoittuvuuksien ja päivitysten varoittamiseksi.
Isännöidyt vs. itse isännöidyt juoksijat ja salainen paljastuminen
Työnkulkujesi suorituspaikalla on valtava vaikutus siihen, kuinka turvallisesti salaisuuksia käsitellään. GitHubin ylläpitämät ja itse isännöidyt suorituspalvelimet käyttäytyvät hyvin eri tavalla eristäytymisen ja pysyvyyden suhteen.
GitHubin ylläpitämät suoritusohjelmat käynnistävät uusia virtuaalikoneita kutakin työtä varten, suorittavat työnkulkusi ja purkavat ne. Se antaa sinulle puhtaan ympäristön joka kerta ja varmistaa, että kaikki tiedostot tai ympäristömuuttujat (mukaan lukien levylle kirjoitetut salaisuudet) tuhoutuvat työn valmistuttua.
Itse isännöidyt juoksijat ovat sitä vastoin pitkäikäisiä koneita, joita hallinnoit. Tämä tarkoittaa, että mikä tahansa salaisuuksiin pääsyä omaava koodi voi mahdollisesti säilyä tai vuotaa ne yhden työn elinkaaren jälkeen. Julkisissa arkistoissa itse isännöidyt suorituspalvelimet ovat erityisen riskialttiita, koska epäluotettavat osallistujat voivat avata pull-pyyntöjä, jotka käynnistävät työnkulkuja.
Jos käytät itse isännöityjä suorittimia, eristä ne herkkyystason mukaan, rajoita, mitkä repositoriot voivat käyttää mitä suorittimia, ja ole vainoharhainen sen suhteen, mitä muuta näillä koneilla on (SSH-avaimet, pilvitunnukset, verkkoyhteys sisäisiin palveluihin ja niin edelleen). Jotkut organisaatiot käyttävät itse isännöityjä ”just-in-time” (JIT) -suoritinohjelmia, jotka luodaan API:n kautta yhtä työtä varten ja sitten tuhotaan, mutta silloinkin on varmistettava, etteivät työt jaa samaa suoritinohjelmaa odottamatta.
OpenID Connectin (OIDC) käyttö pitkäaikaisten pilvisalaisuuksien sijaan
Yksi GitHub Actionsin suurimmista salassapitoa parantavista eduista on pitkäikäisten pilvikäyttöavainten korvaaminen lyhytikäisillä tunnistetiedoilla OpenID Connectin kautta. Sen sijaan, että AWS-, Azure- tai GCP-avaimia tallennettaisiin salaisuuksina, työnkulkusi pyytävät väliaikaisia tokeneita pilvipalveluntarjoajalta käyttäen GitHubia identiteetintarjoajana.
Työnkulku näyttää suurin piirtein tältä: työ pyytää allekirjoitettua JWT-tunnistetta GitHubin OIDC-päätepisteestä, pilvipalveluntarjoajasi vahvistaa kyseisen tokenin ja vaihtaa sen lyhytaikaisiin tunnistetietoihin, ja työnkulku käyttää näitä tunnistetietoja koko työn keston ajan. Yhdenkään staattisen salaisuuden ei tarvitse koskaan sijaita GitHubissa.
Esimerkiksi AWS:ssä määrität IAM-roolin, joka luottaa GitHubin OIDC-tarjoajaan ja rajoittaa, mitkä repositoriot/haarat voivat ottaa kyseisen roolin. Sitten työnkulussasi käytät toimintoa, kuten aws-actions/configure-aws-credentials OIDC-käyttöoikeudet käytössä tunnistetietojen hankkimiseksi lennossa.
Tällä lähestymistavalla on useita etuja: GitHubin sisällä ei ole mitään kierrätettävää, tokenit ovat automaattisesti lyhytaikaisia, käyttöoikeudet ovat rajattuja ja pilvipuolella saat täydelliset lokit, jotka seuraavat kaikkia roolioletuksia. Korkean tietoturvan ympäristöissä OIDC:n tulisi olla oletusarvo, jos sitä tuetaan.
Natiivit työkalut ja ulkoiset salaisuuksien hallintaohjelmat
GitHubin sisäänrakennetut salaisuudet sopivat moniin skenaarioihin, mutta jossain vaiheessa saatat haluta keskitetymmän ja ominaisuuksiltaan rikkaamman salaisuuksien hallinnan, joka kattaa useita alustoja ja ympäristöjä. Tähän tarkoitukseen käytetään usein GitHub Actionsin rinnalla työkaluja, kuten HashiCorp Vault, Infisical tai Doppler.
Nämä järjestelmät pystyvät käsittelemään dynaamisia salaisuuksia (esimerkiksi lyhytaikaisten tietokantakäyttäjien luomista), edistyneitä käyttöoikeuskäytäntöjä, yksityiskohtaisia lokitietoja ja rotaatiotyönkulkuja, jotka ylittävät GitHubin yksin tarjoamat ominaisuudet. GitHub Actions todentaa sitten näille hallinnoijille (usein OIDC:n tai muun todennusmenetelmän kautta), hakee heidän tarvitsemansa salaisuudet suorituksen aikana ja käyttää niitä tallentamatta koskaan pitkäaikaisia tunnistetietoja repositorioon.
Tarjolla on myös yhteisötoimintoja ja -laajennuksia, jotka on suunniteltu hakemaan ulkoisten päälliköiden salaisuuksia suoraan työnkulkuihin. Niitä käytettäessä pätee sama neuvo: tarkista toiminnon lähde, kiinnitä se commit SHA -pyyntöön ja rajoita ulkoiseen järjestelmään pääsyyn käytettävän tunnuksen tai roolin käyttöoikeuksia.
Turvallinen salaisuuksien hallinta GitHub Actionsissa tarkoittaa oikean laajuuden valitsemista kullekin salaisuudelle, pienimpien oikeuksien noudattamista, ympäristöjen ja OIDC:n käyttöä tarvittaessa, lokien ja kolmansien osapuolten toimien käsittelyä mahdollisina hyökkäyspintoina ja ulkoisten salaisuuksien hallintaohjelmien käyttöön turvautumista, kun mittakaava- tai vaatimustenmukaisuusvaatimukset sitä vaativat. Näiden käytäntöjen avulla CI/CD-prosessisi voivat pysyä joustavina ja nopeina samalla, kun se vähentää merkittävästi riskiä, että kadonnut tunniste tai huonosti tarkistettu työnkulku muuttuisi täysimittaiseksi ongelmaksi.
