GitHub Actions i\u015f ak\u0131\u015flar\u0131n\u0131zda SSH anahtarlar\u0131n\u0131n risklerini ortadan kald\u0131rarak g\u00fcvenli\u011fi art\u0131rman\u0131n ve operasyonel karma\u015f\u0131kl\u0131\u011f\u0131 azaltman\u0131n yollar\u0131n\u0131 ke\u015ffedin. Bu makalede, geleneksel SSH kullan\u0131m\u0131ndan neden uzakla\u015fmam\u0131z gerekti\u011fini ve yerine OpenID Connect (OIDC) gibi modern, k\u0131sa \u00f6m\u00fcrl\u00fc kimlik do\u011frulama y\u00f6ntemlerini nas\u0131l entegre edebilece\u011finizi ad\u0131m ad\u0131m \u00f6\u011freneceksiniz.<\/p>\n
GitHub Actions gibi modern CI\/CD platformlar\u0131, yaz\u0131l\u0131m geli\u015ftirme s\u00fcre\u00e7lerimizi otomatikle\u015ftirmek i\u00e7in vazge\u00e7ilmez ara\u00e7lar haline geldi. Ancak, bu otomasyon s\u00fcre\u00e7lerinde kullan\u0131lan kimlik do\u011frulama y\u00f6ntemleri, genel g\u00fcvenlik duru\u015fumuzu do\u011frudan etkileyen kritik bir unsurdur. Geleneksel olarak, uzak sunuculara veya bulut kaynaklar\u0131na eri\u015fim i\u00e7in SSH anahtarlar\u0131 yayg\u0131n bir \u015fekilde kullan\u0131lm\u0131\u015ft\u0131r. Bu anahtarlar, GitHub depolar\u0131ndan sunuculara kod da\u011f\u0131tmak, ba\u011f\u0131ml\u0131l\u0131klar\u0131 indirmek veya uzak komutlar\u0131 \u00e7al\u0131\u015ft\u0131rmak gibi pek \u00e7ok senaryoda devreye girer. Ancak, SSH anahtarlar\u0131, \u00f6zellikle GitHub Actions gibi otomatize edilmi\u015f ortamlarda kullan\u0131ld\u0131\u011f\u0131nda, ciddi g\u00fcvenlik riskleri ve y\u00f6netim zorluklar\u0131 yaratmaktad\u0131r.<\/p>\n
\u00d6ncelikle, SSH anahtarlar\u0131n\u0131n uzun \u00f6m\u00fcrl\u00fc yap\u0131s\u0131, potansiyel g\u00fcvenlik a\u00e7\u0131klar\u0131n\u0131n temelini olu\u015fturur. Bir anahtar bir kez olu\u015fturuldu\u011funda ve bir GitHub Actions i\u015f ak\u0131\u015f\u0131nda bir s\u0131r (secret) olarak sakland\u0131\u011f\u0131nda, bu anahtar\u0131n s\u00fcresi dolmaz. E\u011fer bu anahtar bir \u015fekilde ele ge\u00e7irilirse, sald\u0131rganlar bu anahtar\u0131 kullanarak s\u00fcresiz eri\u015fim elde edebilirler. Bu durum, \u00f6zellikle y\u00fcksek ayr\u0131cal\u0131klara sahip anahtarlar i\u00e7in felaketle sonu\u00e7lanabilecek bir g\u00fcvenlik ihlaline yol a\u00e7abilir. \u00c7al\u0131nan bir SSH anahtar\u0131, hassas verilere, \u00fcretim ortamlar\u0131na veya di\u011fer kritik altyap\u0131lara yetkisiz eri\u015fim sa\u011flayabilir.<\/p>\n
\u0130kinci olarak, SSH anahtarlar\u0131n\u0131n y\u00f6netimi olduk\u00e7a zahmetli ve hataya a\u00e7\u0131kt\u0131r. Her bir sunucuya veya hizmete \u00f6zel anahtar \u00e7iftleri olu\u015fturmak, bu anahtarlar\u0131 GitHub Secrets gibi g\u00fcvenli depolama alanlar\u0131nda saklamak, eri\u015fim izinlerini d\u00fczenli olarak g\u00f6zden ge\u00e7irmek ve anahtarlar\u0131 zaman zaman d\u00f6nd\u00fcrmek (rotate etmek) karma\u015f\u0131k bir s\u00fcre\u00e7tir. \u00d6l\u00e7ek b\u00fcy\u00fcd\u00fck\u00e7e, bu y\u00f6netim y\u00fck\u00fc katlanarak artar. Bir anahtar\u0131n yanl\u0131\u015fl\u0131kla bir genel depoya (public repository) s\u0131zmas\u0131 veya yetkisiz ki\u015filerle payla\u015f\u0131lmas\u0131 riski her zaman mevcuttur. Ayr\u0131ca, bir ekip \u00fcyesi ayr\u0131ld\u0131\u011f\u0131nda veya bir anahtar\u0131n art\u0131k kullan\u0131lmamas\u0131 gerekti\u011finde, ilgili anahtar\u0131n t\u00fcm sistemlerden eksiksiz bir \u015fekilde kald\u0131r\u0131ld\u0131\u011f\u0131ndan emin olmak zorlay\u0131c\u0131 olabilir. Bu t\u00fcr manuel i\u015flemler, insan hatas\u0131na a\u00e7\u0131k kap\u0131 b\u0131rak\u0131r ve g\u00fcvenlik a\u00e7\u0131klar\u0131n\u0131n olu\u015fma olas\u0131l\u0131\u011f\u0131n\u0131 art\u0131r\u0131r.<\/p>\n
Son olarak, geleneksel SSH anahtarlar\u0131, en az ayr\u0131cal\u0131k (least privilege) ilkesini uygulamakta yetersiz kalabilir. \u00c7o\u011fu zaman, bir i\u015f ak\u0131\u015f\u0131n\u0131n belirli bir g\u00f6revi yerine getirmesi i\u00e7in gerekenden daha geni\u015f yetkilere sahip bir anahtar kullan\u0131l\u0131r. Bu da, e\u011fer anahtar ele ge\u00e7irilirse, sald\u0131rgan\u0131n elde edebilece\u011fi zarar potansiyelini art\u0131r\u0131r. Modern g\u00fcvenlik yakla\u015f\u0131mlar\u0131, her zaman yaln\u0131zca belirli bir g\u00f6revi yerine getirmek i\u00e7in gereken minimum yetkilere sahip, k\u0131sa \u00f6m\u00fcrl\u00fc kimlik bilgileri kullan\u0131lmas\u0131n\u0131 savunur. \u0130\u015fte bu noktada, SSH anahtarlar\u0131n\u0131n yerini alabilecek daha g\u00fcvenli ve y\u00f6netilebilir alternatiflere y\u00f6nelme ihtiyac\u0131 do\u011fmaktad\u0131r. Bu alternatifler, otomasyon s\u00fcre\u00e7lerimizi daha dayan\u0131kl\u0131, denetlenebilir ve siber tehditlere kar\u015f\u0131 daha diren\u00e7li hale getirmemizi sa\u011flar.<\/p>\n
GitHub Actions’ta SSH anahtarlar\u0131n\u0131 neden b\u0131rakmam\u0131z gerekti\u011fini anlamak i\u00e7in, \u00f6ncelikle SSH anahtarlar\u0131n\u0131n ne oldu\u011funu ve temel g\u00fcvenlik mekanizmalar\u0131n\u0131n nas\u0131l i\u015fledi\u011fini kavramak \u00f6nemlidir. Ayr\u0131ca, CI\/CD ortamlar\u0131nda kimlik do\u011frulaman\u0131n ne anlama geldi\u011fini ve neden bu kadar kritik oldu\u011funu da irdelemeliyiz. Bu temel kavramlar, daha modern ve g\u00fcvenli alternatiflere ge\u00e7i\u015fin mant\u0131\u011f\u0131n\u0131 anlaman\u0131za yard\u0131mc\u0131 olacakt\u0131r.<\/p>\n
SSH Anahtarlar\u0131 (Secure Shell Keys) Nedir?<\/strong><\/p>\n SSH anahtarlar\u0131, g\u00fcvenli a\u011f ileti\u015fimi sa\u011flamak i\u00e7in kullan\u0131lan kriptografik anahtar \u00e7iftleridir. Bir a\u00e7\u0131k (public) anahtar ve bir \u00f6zel (private) anahtardan olu\u015furlar. A\u00e7\u0131k anahtar, eri\u015fim sa\u011flamak istedi\u011finiz uzak sunuculara veya hizmetlere yerle\u015ftirilirken, \u00f6zel anahtar kullan\u0131c\u0131n\u0131n veya otomasyon sisteminin elinde gizli tutulur. Kimlik do\u011frulama s\u0131ras\u0131nda, \u00f6zel anahtara sahip olan istemci, a\u00e7\u0131k anahtarla e\u015fle\u015fen bir kriptografik imza olu\u015fturur. Sunucu bu imzay\u0131 do\u011frular ve e\u015fle\u015fme ba\u015far\u0131l\u0131 olursa, istemciye eri\u015fim izni verir. Bu mekanizma, parola tabanl\u0131 kimlik do\u011frulamas\u0131na k\u0131yasla \u00e7ok daha g\u00fcvenli kabul edilir, zira anahtarlar\u0131n k\u0131r\u0131lmas\u0131 \u00e7ok daha zordur.<\/p>\n GitHub Actions ba\u011flam\u0131nda, \u00f6zel SSH anahtarlar\u0131 genellikle GitHub Secrets ad\u0131 verilen g\u00fcvenli depolama alanlar\u0131nda saklan\u0131r. Bir i\u015f ak\u0131\u015f\u0131 \u00e7al\u0131\u015ft\u0131\u011f\u0131nda, bu anahtar \u00e7ekilir ve uzak sunucuya SSH ba\u011flant\u0131s\u0131 kurmak i\u00e7in kullan\u0131l\u0131r. \u00d6rne\u011fin, bir uygulamay\u0131 bir AWS EC2 \u00f6rne\u011fine veya bir DigitalOcean Droplet’e da\u011f\u0131tmak istedi\u011finizde, i\u015f ak\u0131\u015f\u0131n\u0131z bu \u00f6zel anahtar\u0131 kullanarak hedef sunucuya kimli\u011fini do\u011frular ve da\u011f\u0131t\u0131m komutlar\u0131n\u0131 \u00e7al\u0131\u015ft\u0131r\u0131r.<\/p>\n CI\/CD Ortamlar\u0131nda Kimlik Do\u011frulama Neden Kritik?<\/strong><\/p>\n S\u00fcrekli Entegrasyon (CI) ve S\u00fcrekli Da\u011f\u0131t\u0131m (CD) s\u00fcre\u00e7leri, yaz\u0131l\u0131m geli\u015ftirme ya\u015fam d\u00f6ng\u00fcs\u00fcn\u00fcn otomasyon omurgas\u0131n\u0131 olu\u015fturur. Bu s\u00fcre\u00e7ler, kodun derlenmesinden test edilmesine, paketlenmesinden da\u011f\u0131t\u0131m\u0131na kadar bir\u00e7ok ad\u0131m\u0131 kapsar. Bu ad\u0131mlar\u0131n \u00e7o\u011fu, d\u0131\u015f kaynaklara eri\u015fim gerektirir:<\/p>\n Bu eri\u015fimlerin her biri, kimlik do\u011frulama gerektirir. E\u011fer bir CI\/CD i\u015f ak\u0131\u015f\u0131, bu kaynaklara eri\u015fmek i\u00e7in kullan\u0131lan kimlik bilgilerini g\u00fcvende tutamazsa, t\u00fcm sistemin g\u00fcvenli\u011fi tehlikeye girer. Bir sald\u0131rgan, CI\/CD sistemini ele ge\u00e7irerek, hassas kodlara, verilere veya \u00fcretim ortamlar\u0131na yetkisiz eri\u015fim sa\u011flayabilir. Bu nedenle, kimlik do\u011frulama, CI\/CD g\u00fcvenli\u011finin temel direklerinden biridir.<\/p>\n SSH Anahtarlar\u0131yla Gelen G\u00fcvenlik Riskleri ve Y\u00f6netim Zorluklar\u0131:<\/strong><\/p>\n Yukar\u0131da da bahsetti\u011fimiz gibi, SSH anahtarlar\u0131 g\u00fc\u00e7l\u00fc bir kimlik do\u011frulama y\u00f6ntemi olsa da, CI\/CD ortamlar\u0131nda uzun \u00f6m\u00fcrl\u00fc olmalar\u0131 ve manuel y\u00f6netime ba\u011f\u0131ml\u0131 olmalar\u0131 nedeniyle \u00e7e\u015fitli riskleri beraberinde getirir:<\/p>\n Bu zorluklar g\u00f6z \u00f6n\u00fcne al\u0131nd\u0131\u011f\u0131nda, SSH anahtarlar\u0131n\u0131n yerini alacak, otomatikle\u015ftirilebilir, k\u0131sa \u00f6m\u00fcrl\u00fc ve en az ayr\u0131cal\u0131k ilkesine uygun \u00e7\u00f6z\u00fcmlere y\u00f6nelmek ka\u00e7\u0131n\u0131lmaz hale gelmi\u015ftir. Bir sonraki b\u00f6l\u00fcmde, bu modern yakla\u015f\u0131mlardan en \u00f6nemlisi olan OpenID Connect (OIDC) ve k\u0131sa \u00f6m\u00fcrl\u00fc kimlik bilgilerini detayland\u0131raca\u011f\u0131z.<\/p>\n Geleneksel SSH anahtarlar\u0131n\u0131n g\u00fcvenlik ve y\u00f6netim zorluklar\u0131n\u0131 geride b\u0131rakmak i\u00e7in OpenID Connect (OIDC) tabanl\u0131 kimlik do\u011frulama ve k\u0131sa \u00f6m\u00fcrl\u00fc kimlik bilgileri, CI\/CD ortamlar\u0131 i\u00e7in ideal bir \u00e7\u00f6z\u00fcm sunar. Bu yakla\u015f\u0131m, g\u00fcvenlik duru\u015fumuzu \u00f6nemli \u00f6l\u00e7\u00fcde g\u00fc\u00e7lendirirken, operasyonel y\u00fck\u00fc de azalt\u0131r. Peki, OIDC tam olarak nedir ve k\u0131sa \u00f6m\u00fcrl\u00fc kimlik bilgileri ne anlama gelir?<\/p>\n OpenID Connect (OIDC) Nedir ve Nas\u0131l \u00c7al\u0131\u015f\u0131r?<\/strong><\/p>\n OpenID Connect (OIDC), OAuth 2.0 protokol\u00fc \u00fczerine in\u015fa edilmi\u015f basit bir kimlik katman\u0131d\u0131r. Temel amac\u0131, istemcilerin bir kimlik sa\u011flay\u0131c\u0131 taraf\u0131ndan kimli\u011fi do\u011frulanm\u0131\u015f bir kullan\u0131c\u0131n\u0131n (veya bu durumda bir i\u015f ak\u0131\u015f\u0131n\u0131n) kimlik bilgilerini almas\u0131n\u0131 sa\u011flamakt\u0131r. OIDC’nin en \u00f6nemli \u00e7\u0131kt\u0131s\u0131, JSON Web Token (JWT) format\u0131ndaki bir ID Token’d\u0131r. Bu token, kimli\u011fi do\u011frulanm\u0131\u015f varl\u0131k (kullan\u0131c\u0131 veya i\u015f ak\u0131\u015f\u0131) hakk\u0131nda \u00e7e\u015fitli iddialar (claims) i\u00e7erir, \u00f6rne\u011fin kimin kimlik do\u011frulamas\u0131n\u0131 yapt\u0131\u011f\u0131, ne zaman yap\u0131ld\u0131\u011f\u0131 gibi bilgiler.<\/p>\n GitHub Actions ba\u011flam\u0131nda OIDC, i\u015f ak\u0131\u015f\u0131n\u0131z\u0131n kendisini bir “kimlik” olarak do\u011frulamas\u0131na olanak tan\u0131r. \u0130\u015f ak\u0131\u015f\u0131n\u0131z \u00e7al\u0131\u015ft\u0131\u011f\u0131nda, GitHub, otomatik olarak imzalanm\u0131\u015f bir JWT olu\u015fturur ve bu token\u0131 i\u015f ak\u0131\u015f\u0131n\u0131n kullan\u0131m\u0131na sunar. Bu JWT, i\u015f ak\u0131\u015f\u0131n\u0131n \u00e7al\u0131\u015ft\u0131\u011f\u0131 depo (repository), dal (branch), i\u015f ak\u0131\u015f\u0131 ad\u0131 gibi benzersiz tan\u0131mlay\u0131c\u0131lar i\u00e7erir. Daha sonra, i\u015f ak\u0131\u015f\u0131 bu JWT’yi bulut sa\u011flay\u0131c\u0131n\u0131za (\u00f6rne\u011fin AWS, Azure, GCP) g\u00f6nderir. Bulut sa\u011flay\u0131c\u0131n\u0131z, bu JWT’yi do\u011frular ve token i\u00e7indeki iddialara (claims) g\u00f6re i\u015f ak\u0131\u015f\u0131na ge\u00e7ici, k\u0131sa \u00f6m\u00fcrl\u00fc kimlik bilgileri (\u00f6rne\u011fin AWS i\u00e7in IAM rol\u00fc kimlik bilgileri, Azure i\u00e7in y\u00f6netilen kimlik veya servis prensibi) verir. Bu sayede, i\u015f ak\u0131\u015f\u0131n\u0131z do\u011frudan bulut kaynaklar\u0131na, hi\u00e7bir uzun \u00f6m\u00fcrl\u00fc s\u0131r (SSH anahtar\u0131 veya API anahtar\u0131) saklamadan eri\u015febilir.<\/p>\n K\u0131sa \u00d6m\u00fcrl\u00fc Kimlik Bilgileri Neden Daha G\u00fcvenli?<\/strong><\/p>\n K\u0131sa \u00f6m\u00fcrl\u00fc kimlik bilgileri (ephemeral credentials), ad\u0131ndan da anla\u015f\u0131laca\u011f\u0131 gibi, belirli bir s\u00fcre sonra otomatik olarak ge\u00e7ersiz hale gelen ge\u00e7ici kimlik bilgileridir. Bu, OIDC tabanl\u0131 kimlik do\u011frulaman\u0131n temel ta\u015f\u0131d\u0131r ve g\u00fcvenlik a\u00e7\u0131s\u0131ndan bir dizi \u00f6nemli avantaj sunar:<\/p>\n K\u0131sacas\u0131, OIDC ve k\u0131sa \u00f6m\u00fcrl\u00fc kimlik bilgileri, GitHub Actions ortam\u0131nda g\u00fcvenlik stratejisini temelden de\u011fi\u015ftirir. Uzun \u00f6m\u00fcrl\u00fc, manuel y\u00f6netilen s\u0131rlar\u0131n yerine, otomatik, ge\u00e7ici ve en az ayr\u0131cal\u0131kl\u0131 eri\u015fimi m\u00fcmk\u00fcn k\u0131lar. Bu da, hem geli\u015ftirme verimlili\u011fini art\u0131r\u0131r hem de siber g\u00fcvenlik risklerini \u00f6nemli \u00f6l\u00e7\u00fcde azalt\u0131r.<\/p>\n OIDC’yi etkinle\u015ftirmek ve do\u011fru bir \u015fekilde yap\u0131land\u0131rmak, GitHub Actions i\u015f ak\u0131\u015flar\u0131n\u0131z\u0131n g\u00fcvenli\u011fini katlayarak art\u0131r\u0131r. Ancak unutmay\u0131n, OIDC’nin sundu\u011fu bu g\u00fc\u00e7l\u00fc g\u00fcvenlik mekanizmas\u0131ndan tam olarak faydalanmak i\u00e7in bulut sa\u011flay\u0131c\u0131n\u0131zdaki IAM politikalar\u0131n\u0131 da en az ayr\u0131cal\u0131k prensibine g\u00f6re dikkatlice yap\u0131land\u0131rman\u0131z gerekmektedir. Yaln\u0131zca JWT’nin do\u011fru bir \u015fekilde do\u011frulanmas\u0131n\u0131 de\u011fil, ayn\u0131 zamanda bu do\u011frulama sonucunda verilen yetkilerin de sadece ihtiyac\u0131 kar\u015f\u0131layacak kadar olmas\u0131n\u0131 sa\u011flay\u0131n.<\/p>\n<\/p><\/div>\n \u015eimdi, \u00f6\u011frendi\u011fimiz teorik bilgileri prati\u011fe d\u00f6kelim. GitHub Actions i\u015f ak\u0131\u015f\u0131n\u0131z\u0131 AWS ile OpenID Connect (OIDC) kullanarak nas\u0131l entegre edece\u011finizi ad\u0131m ad\u0131m inceleyece\u011fiz. Bu vaka analizi, SSH anahtarlar\u0131ndan tamamen ar\u0131nm\u0131\u015f, g\u00fcvenli ve otomatik bir da\u011f\u0131t\u0131m ak\u0131\u015f\u0131n\u0131n nas\u0131l olu\u015fturulaca\u011f\u0131n\u0131 g\u00f6sterecektir.<\/p>\n \u0130lk olarak, AWS IAM (Identity and Access Management) i\u00e7inde GitHub Actions’\u0131 bir kimlik sa\u011flay\u0131c\u0131 olarak tan\u0131tman\u0131z gerekiyor. Bu, AWS’nin GitHub taraf\u0131ndan yay\u0131nlanan JWT’leri g\u00fcvenmesini sa\u011flayacakt\u0131r.<\/p>\n AWS Y\u00f6netim Konsolu’nda IAM hizmetine gidin ve sol men\u00fcden “Identity Providers” (Kimlik Sa\u011flay\u0131c\u0131lar\u0131) se\u00e7ene\u011fine t\u0131klay\u0131n. “Add Provider” (Sa\u011flay\u0131c\u0131 Ekle) butonuna basarak yeni bir OpenID Connect sa\u011flay\u0131c\u0131 olu\u015fturun.<\/p>\n Bu ad\u0131mlar\u0131 tamamlad\u0131\u011f\u0131n\u0131zda, AWS, GitHub Actions’\u0131n JWT’lerini do\u011frulayabilecek duruma gelecektir.<\/p>\n S\u0131rada, GitHub Actions i\u015f ak\u0131\u015f\u0131n\u0131z\u0131n \u00fcstlenece\u011fi bir IAM rol\u00fc olu\u015fturmak var. Bu rol, i\u015f ak\u0131\u015f\u0131n\u0131z\u0131n AWS kaynaklar\u0131 \u00fczerinde hangi eylemleri ger\u00e7ekle\u015ftirebilece\u011fini tan\u0131mlayacakt\u0131r. Rol\u00fc olu\u015ftururken, GitHub Actions Identity Provider’\u0131na g\u00fcvenmesini sa\u011flamal\u0131s\u0131n\u0131z.<\/p>\n IAM konsolunda “Roles” (Roller) b\u00f6l\u00fcm\u00fcne gidin ve “Create role” (Rol olu\u015ftur) butonuna t\u0131klay\u0131n. “Custom trust policy” (\u00d6zel g\u00fcven politikas\u0131) se\u00e7ene\u011fini se\u00e7in ve a\u015fa\u011f\u0131daki JSON politikas\u0131n\u0131 yap\u0131\u015ft\u0131r\u0131n:<\/p>\n <\/code><\/p>\n Yukar\u0131daki JSON'da Bu g\u00fcven politikas\u0131, GitHub Actions'tan gelen ve belirli bir depodan\/daldan gelen JWT'ye sahip olan bir varl\u0131\u011f\u0131n bu rol\u00fc \u00fcstlenmesine izin verir.<\/p>\n Daha sonra, bu role i\u015f ak\u0131\u015f\u0131n\u0131z\u0131n ihtiya\u00e7 duydu\u011fu izinleri (\u00f6rne\u011fin, S3'e dosya y\u00fckleme, EC2 \u00f6rneklerini y\u00f6netme vb.) atay\u0131n. \u00d6rne\u011fin, S3'e da\u011f\u0131t\u0131m yapacaksan\u0131z, Art\u0131k AWS taraf\u0131 haz\u0131r oldu\u011funa g\u00f6re, GitHub Actions i\u015f ak\u0131\u015f\u0131n\u0131z\u0131 OIDC kullanacak \u015fekilde g\u00fcncelleyebilirsiniz. \u0130\u015f ak\u0131\u015f\u0131 dosyan\u0131zda ( <\/code><\/p>\n Bu YAML dosyas\u0131nda dikkat edilmesi gereken \u00f6nemli noktalar:<\/p>\n Bu yap\u0131land\u0131rma ile i\u015f ak\u0131\u015f\u0131n\u0131z, uzun \u00f6m\u00fcrl\u00fc SSH anahtarlar\u0131 veya API anahtarlar\u0131 saklamadan g\u00fcvenli bir \u015fekilde AWS kaynaklar\u0131na eri\u015febilir. AWS CLI komutlar\u0131n\u0131 do\u011frudan \u00e7al\u0131\u015ft\u0131rabilir veya SDK kullanan uygulamalar\u0131n\u0131z\u0131 da\u011f\u0131tabilirsiniz.<\/p>\n Daha \u00f6nce SSH anahtar\u0131 kullanarak yapt\u0131\u011f\u0131n\u0131z i\u015flemleri (\u00f6rne\u011fin, E\u011fer dosya kopyalama i\u015flemi bir sunucuya uygulama dosyalar\u0131 da\u011f\u0131tmak i\u00e7inse, bunlar\u0131 bir S3 kovas\u0131na y\u00fckleyip sunucular\u0131n S3'ten \u00e7ekmesini sa\u011flayabilirsiniz. Veya do\u011frudan da\u011f\u0131t\u0131m ara\u00e7lar\u0131 (CodeDeploy, ECS, EKS) kullan\u0131n.<\/p>\n <\/code>\n <\/li>\n EC2 \u00f6rnekleri \u00fczerinde komut \u00e7al\u0131\u015ft\u0131rman\u0131z gerekiyorsa, bunun i\u00e7in AWS Systems Manager (SSM) Run Command kullanabilirsiniz. Bu, SSH portunu a\u00e7ma ihtiyac\u0131n\u0131 ortadan kald\u0131r\u0131r.<\/p>\n <\/code>\n <\/li>\n<\/ul>\n Bu y\u00f6ntemlerle, SSH anahtarlar\u0131n\u0131n g\u00fcvenlik risklerinden ka\u00e7\u0131narak, bulut sa\u011flay\u0131c\u0131n\u0131z\u0131n kendi g\u00fcvenli kimlik do\u011frulama mekanizmalar\u0131n\u0131 kullanm\u0131\u015f olursunuz. Bu yakla\u015f\u0131m, sadece g\u00fcvenlik de\u011fil, ayn\u0131 zamanda operasyonel esneklik ve denetlenebilirlik a\u00e7\u0131s\u0131ndan da \u00f6nemli avantajlar sunar.<\/p>\n GitHub Actions i\u015f ak\u0131\u015flar\u0131n\u0131zda SSH anahtarlar\u0131ndan uzakla\u015f\u0131rken, OIDC en g\u00fc\u00e7l\u00fc ve tercih edilen yol olsa da, ba\u015fka g\u00fcvenli alternatifler ve genel ge\u00e7er en iyi uygulamalar da bulunmaktad\u0131r. Bu se\u00e7enekler, OIDC'nin do\u011frudan uygulanamad\u0131\u011f\u0131 veya belirli \u00f6zel durumlar i\u00e7in uygun olabilecek senaryolarda devreye girebilir. Amac\u0131m\u0131z, her zaman en az ayr\u0131cal\u0131k (least privilege) ilkesine sad\u0131k kalmak ve s\u0131r y\u00f6netimi y\u00fck\u00fcn\u00fc en aza indirmektir.<\/p>\n GitHub Secrets, hassas bilgileri (API anahtarlar\u0131, veritaban\u0131 \u015fifreleri, \u00f6zel tokenlar vb.) i\u015f ak\u0131\u015flar\u0131n\u0131zda g\u00fcvenli bir \u015fekilde saklamak i\u00e7in GitHub taraf\u0131ndan sa\u011flanan yerle\u015fik bir mekanizmad\u0131r. Anahtarlar \u015fifrelenir ve yaln\u0131zca i\u015f ak\u0131\u015f\u0131n\u0131z\u0131n \u00e7al\u0131\u015ft\u0131\u011f\u0131 ortamda ge\u00e7ici olarak eri\u015filebilir hale gelir. SSH \u00f6zel anahtarlar\u0131n\u0131 saklamak i\u00e7in de kullan\u0131labilirler, ancak yukar\u0131da bahsedilen uzun \u00f6m\u00fcrl\u00fcl\u00fck riskleri devam eder.<\/p>\n Ne Zaman Kullan\u0131l\u0131r?<\/strong><\/p>\n En \u0130yi Uygulamalar:<\/strong><\/p>\n Unutmay\u0131n, GitHub Secrets, SSH anahtarlar\u0131n\u0131 saklamak i\u00e7in hala bir se\u00e7enektir, ancak bu, anahtarlar\u0131n uzun \u00f6m\u00fcrl\u00fcl\u00fc\u011f\u00fcnden kaynaklanan temel g\u00fcvenlik sorununu \u00e7\u00f6zmez. OIDC'nin m\u00fcmk\u00fcn oldu\u011fu her yerde OIDC'yi tercih etmek en g\u00fcvenli yakla\u015f\u0131md\u0131r.<\/p>\n E\u011fer da\u011f\u0131t\u0131m hedefiniz bulut \u00fczerinde \u00e7al\u0131\u015fan bir sanal makine (VM) veya konteyner ise, bulut sa\u011flay\u0131c\u0131lar\u0131n\u0131n y\u00f6netilen kimlik (managed identity) hizmetleri g\u00fc\u00e7l\u00fc bir alternatif sunabilir. \u00d6rne\u011fin:<\/p>\n Bu yakla\u015f\u0131m, da\u011f\u0131t\u0131m hedefine (VM veya konteyner) do\u011frudan SSH anahtarlar\u0131 yerle\u015ftirmekten \u00e7ok daha g\u00fcvenlidir, \u00e7\u00fcnk\u00fc kimlik bilgileri bulut sa\u011flay\u0131c\u0131s\u0131 taraf\u0131ndan y\u00f6netilir ve genellikle otomatik olarak d\u00f6nd\u00fcr\u00fcl\u00fcr.<\/p>\n Bu alternatifler ve en iyi uygulamalar, GitHub Actions'ta daha g\u00fcvenli ve s\u00fcrd\u00fcr\u00fclebilir bir CI\/CD ortam\u0131 olu\u015fturman\u0131za yard\u0131mc\u0131 olacakt\u0131r. Amac\u0131m\u0131z, hassas kimlik bilgilerini kod taban\u0131m\u0131zdan veya statik depolama alanlar\u0131ndan tamamen \u00e7\u0131karmak ve dinamik, k\u0131sa \u00f6m\u00fcrl\u00fc, bulut sa\u011flay\u0131c\u0131 tabanl\u0131 kimlik do\u011frulama mekanizmalar\u0131na ge\u00e7mektir.<\/p>\n GitHub Actions ve OIDC entegrasyonunun temellerini \u00f6\u011frendi\u011fimize g\u00f6re, \u015fimdi bu g\u00fc\u00e7l\u00fc g\u00fcvenlik mekanizmas\u0131n\u0131 daha da geli\u015ftirecek ve optimize edecek ileri d\u00fczey ipu\u00e7lar\u0131na g\u00f6z atal\u0131m. Bu ipu\u00e7lar\u0131, daha karma\u015f\u0131k da\u011f\u0131t\u0131m senaryolar\u0131nda g\u00fcvenli\u011fi art\u0131rman\u0131za, y\u00f6netimi kolayla\u015ft\u0131rman\u0131za ve i\u015f ak\u0131\u015flar\u0131n\u0131z\u0131n daha esnek olmas\u0131n\u0131 sa\u011flaman\u0131za yard\u0131mc\u0131 olacakt\u0131r.<\/p>\n Ad\u0131m 2'de olu\u015fturdu\u011fumuz AWS IAM g\u00fcven politikas\u0131, GitHub deponuzdan ve ana dal\u0131n\u0131zdan gelen istekleri hedefliyordu. Ancak, OIDC JWT'sinin sa\u011flad\u0131\u011f\u0131 iddialar (claims) \u00e7ok daha zengindir ve bunlar\u0131 kullanarak politikalar\u0131n\u0131z\u0131 daha da hassasla\u015ft\u0131rabilirsiniz. Bu, en az ayr\u0131cal\u0131k ilkesini daha derinlemesine uygulaman\u0131za olanak tan\u0131r.<\/p>\n \u0130\u015fte kullanabilece\u011finiz baz\u0131 ek iddialar (claims) ve \u00f6rnek ko\u015fullar:<\/p>\n \u00d6rnek Geli\u015fmi\u015f IAM G\u00fcven Politikas\u0131:<\/strong><\/p>\n <\/code><\/p>\n Bu politika, Tek bir bulut sa\u011flay\u0131c\u0131s\u0131na ba\u011f\u0131ml\u0131 olmayan veya hibrit bulut ortamlar\u0131nda \u00e7al\u0131\u015fan kurulu\u015flar i\u00e7in OIDC, esnek bir kimlik do\u011frulama k\u00f6pr\u00fcs\u00fc g\u00f6revi g\u00f6rebilir.<\/p>\n Bu yakla\u015f\u0131mlar, farkl\u0131 bulut platformlar\u0131 aras\u0131nda tutarl\u0131 ve g\u00fcvenli bir kimlik do\u011frulama mekanizmas\u0131 sa\u011flaman\u0131za yard\u0131mc\u0131 olur.<\/p>\n Bu ileri d\u00fczey ipu\u00e7lar\u0131 ve optimizasyonlar, OIDC'nin sundu\u011fu potansiyeli tam olarak kullanman\u0131za ve GitHub Actions tabanl\u0131 CI\/CD s\u00fcre\u00e7lerinizde maksimum g\u00fcvenlik ve verimlilik elde etmenize yard\u0131mc\u0131 olacakt\u0131r. SSH anahtarlar\u0131ndan vazge\u00e7mek, sadece bir ba\u015flang\u0131\u00e7 noktas\u0131d\u0131r; ger\u00e7ek g\u00fcvenlik, s\u00fcrekli iyile\u015ftirme ve en iyi uygulamalar\u0131n titizlikle uygulanmas\u0131yla sa\u011flan\u0131r.<\/p>\n Bu makalede, GitHub Actions i\u015f ak\u0131\u015flar\u0131n\u0131zda geleneksel SSH anahtarlar\u0131n\u0131 kullanman\u0131n neden modas\u0131 ge\u00e7mi\u015f ve riskli bir yakla\u015f\u0131m oldu\u011funu derinlemesine inceledik. Uzun \u00f6m\u00fcrl\u00fc kimlik bilgileri, y\u00f6netim y\u00fck\u00fc ve en az ayr\u0131cal\u0131k ilkesini uygulaman\u0131n zorluklar\u0131 gibi fakt\u00f6rler, bizi daha modern ve g\u00fcvenli alternatiflere y\u00f6nelmek zorunda b\u0131rak\u0131yor. \u0130\u015fte bu noktada, OpenID Connect (OIDC) ve k\u0131sa \u00f6m\u00fcrl\u00fc kimlik bilgileri devreye girerek, CI\/CD g\u00fcvenli\u011finde yeni bir standart belirliyor.<\/p>\n OIDC'nin sa\u011flad\u0131\u011f\u0131, anahtars\u0131z ve otomatik olarak d\u00f6nd\u00fcr\u00fclen ge\u00e7ici kimlik bilgileri, s\u0131z\u0131nt\u0131 riskini \u00f6nemli \u00f6l\u00e7\u00fcde azalt\u0131rken, y\u00f6netim y\u00fck\u00fcn\u00fc ortadan kald\u0131r\u0131yor ve en az ayr\u0131cal\u0131k ilkesini daha kolay uygulaman\u0131za olanak tan\u0131yor. AWS \u00f6rne\u011fi \u00fczerinden ad\u0131m ad\u0131m g\u00f6sterdi\u011fimiz entegrasyon s\u00fcreci, GitHub Actions'\u0131n nas\u0131l g\u00fcvenli bir \u015fekilde bulut kaynaklar\u0131na eri\u015febilece\u011fini somutla\u015ft\u0131rd\u0131. Bu entegrasyonla birlikte, SSH anahtar\u0131 gerektiren eski al\u0131\u015fkanl\u0131klar\u0131m\u0131z\u0131, bulut sa\u011flay\u0131c\u0131m\u0131z\u0131n kendi API'leri ve hizmetleri (S3, SSM Run Command gibi) \u00fczerinden g\u00fcvenli ve denetlenebilir eylemlerle de\u011fi\u015ftirebilece\u011fimizi g\u00f6rd\u00fck. Ayr\u0131ca, GitHub Secrets gibi di\u011fer alternatifleri ve bu alternatiflerin kullan\u0131m\u0131ndaki en iyi uygulamalar\u0131 da ele ald\u0131k.<\/p>\n \u0130leri d\u00fczey ipu\u00e7lar\u0131 ve optimizasyonlar b\u00f6l\u00fcm\u00fcnde ise, IAM politikalar\u0131n\u0131 OIDC JWT iddialar\u0131n\u0131 kullanarak daha da hassasla\u015ft\u0131rman\u0131n yollar\u0131n\u0131, \u00e7oklu bulut senaryolar\u0131nda OIDC'nin esnekli\u011fini ve CI\/CD ortam g\u00fcvenli\u011fini art\u0131rmak i\u00e7in di\u011fer genel en iyi uygulamalar\u0131 tart\u0131\u015ft\u0131k. Unutulmamal\u0131d\u0131r ki, g\u00fcvenli bir CI\/CD ortam\u0131 in\u015fa etmek s\u00fcrekli bir \u00e7aba gerektirir. Sadece do\u011fru ara\u00e7lar\u0131 se\u00e7mekle kalmamal\u0131, ayn\u0131 zamanda bu ara\u00e7lar\u0131 en iyi g\u00fcvenlik uygulamalar\u0131na uygun \u015fekilde yap\u0131land\u0131rmal\u0131 ve d\u00fczenli olarak g\u00f6zden ge\u00e7irmeliyiz.<\/p>\n \u00d6zetle, GitHub Actions'ta SSH anahtarlar\u0131 d\u00f6nemini geride b\u0131rakman\u0131n zaman\u0131 gelmi\u015ftir. OIDC gibi modern, federasyon tabanl\u0131 kimlik do\u011frulama mekanizmalar\u0131n\u0131 benimsemek, geli\u015ftirme s\u00fcre\u00e7lerinizi h\u0131zland\u0131r\u0131rken ayn\u0131 zamanda siber sald\u0131r\u0131lara kar\u015f\u0131 \u00e7ok daha diren\u00e7li bir altyap\u0131 olu\u015fturman\u0131z\u0131 sa\u011flayacakt\u0131r. Gelece\u011fin CI\/CD g\u00fcvenli\u011fi, k\u0131sa \u00f6m\u00fcrl\u00fc, otomatik ve minimum ayr\u0131cal\u0131kl\u0131 kimlik bilgileri \u00fczerine in\u015fa edilmektedir ve bu yolda OIDC, en g\u00fc\u00e7l\u00fc m\u00fcttefiklerimizden biridir.<\/p>\n Hay\u0131r, OIDC evrensel bir kimlik do\u011frulama standard\u0131d\u0131r ve GitHub Actions, AWS'in yan\u0131 s\u0131ra Azure (Workload Identity Federation) ve Google Cloud (Workload Identity Federation) gibi di\u011fer b\u00fcy\u00fck bulut sa\u011flay\u0131c\u0131lar\u0131yla da OIDC tabanl\u0131 entegrasyonlar\u0131 destekler. Temel prensip ayn\u0131d\u0131r: GitHub bir JWT verir, bulut sa\u011flay\u0131c\u0131s\u0131 bunu do\u011frular ve ge\u00e7ici kimlik bilgileri sa\u011flar.<\/p>\n Ta\u015f\u0131ma s\u00fcreci ad\u0131m ad\u0131m yap\u0131lmal\u0131d\u0131r. \u0130lk olarak, mevcut i\u015f ak\u0131\u015f\u0131n\u0131zda kulland\u0131\u011f\u0131n\u0131z SSH anahtar\u0131n\u0131n yerine OIDC tabanl\u0131 bir rol veya kimlik atayarak ayn\u0131 eri\u015fimi sa\u011flayacak bulut sa\u011flay\u0131c\u0131s\u0131 IAM politikas\u0131n\u0131 ve rol\u00fcn\u00fc olu\u015fturmal\u0131s\u0131n\u0131z. Daha sonra, i\u015f ak\u0131\u015f\u0131 dosyan\u0131z\u0131 g\u00fcncelleyerek Evet, OIDC ile bulut kimlik do\u011frulamas\u0131 yaparken bile GitHub Secrets'\u0131 kullanmaya devam edebilirsiniz. OIDC, bulut kaynaklar\u0131na eri\u015fim i\u00e7in tercih edilen yol olsa da, baz\u0131 \u00fc\u00e7\u00fcnc\u00fc taraf hizmetler veya legacy sistemler OIDC deste\u011fi sunmayabilir. Bu t\u00fcr durumlarda, API anahtarlar\u0131n\u0131 veya tokenlar\u0131 GitHub Secrets'ta g\u00fcvenli bir \u015fekilde saklayarak kullanmaya devam edebilirsiniz. Ancak, bu s\u0131rlar\u0131n rotasyonunu ve en az ayr\u0131cal\u0131k ilkesini uygulamay\u0131 unutmay\u0131n.<\/p>\n OIDC'nin i\u015f ak\u0131\u015flar\u0131n\u0131z\u0131n performans\u0131 \u00fczerinde g\u00f6zle g\u00f6r\u00fcl\u00fcr bir olumsuz etkisi genellikle yoktur. JWT'nin olu\u015fturulmas\u0131 ve do\u011frulanmas\u0131, milisaniyeler i\u00e7inde ger\u00e7ekle\u015fen h\u0131zl\u0131 kriptografik i\u015flemlerdir. Ge\u00e7ici kimlik bilgilerinin al\u0131nmas\u0131 da genellikle h\u0131zl\u0131d\u0131r. Aksine, SSH ba\u011flant\u0131lar\u0131n\u0131 y\u00f6netme ve anahtar do\u011frulama s\u00fcrecinden kaynaklanan baz\u0131 gecikmeleri ortadan kald\u0131rarak performansa olumlu y\u00f6nde bile etki edebilir.<\/p>\n OIDC ile denetlenebilirlik, SSH anahtarlar\u0131na k\u0131yasla \u00e7ok daha iyidir. GitHub Actions, JWT'lerin olu\u015fturuldu\u011funu ve kullan\u0131ld\u0131\u011f\u0131n\u0131 i\u015f ak\u0131\u015f\u0131 g\u00fcnl\u00fcklerinde kaydeder. Bulut sa\u011flay\u0131c\u0131n\u0131z (\u00f6rne\u011fin AWS CloudTrail), i\u015f ak\u0131\u015f\u0131n\u0131n \u00fcstlendi\u011fi rol\u00fc, ald\u0131\u011f\u0131 ge\u00e7ici kimlik bilgilerini ve bu kimlik bilgileriyle yapt\u0131\u011f\u0131 t\u00fcm API \u00e7a\u011fr\u0131lar\u0131n\u0131 detayl\u0131 olarak loglar. Bu, herhangi bir g\u00fcvenlik ihlali durumunda kimin, ne zaman ve hangi eylemi ger\u00e7ekle\u015ftirdi\u011fini takip etmeyi \u00e7ok daha kolay hale getirir.<\/p>\n <\/body><\/p>\n","protected":false},"excerpt":{"rendered":"GitHub Actions i\u015f ak\u0131\u015flar\u0131n\u0131zda SSH anahtarlar\u0131n\u0131n risklerini ortadan kald\u0131rarak g\u00fcvenli\u011fi art\u0131rman\u0131n ve operasyonel karma\u015f\u0131kl\u0131\u011f\u0131 azaltman\u0131n yollar\u0131n\u0131 ke\u015ffedin. Bu…","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"csco_page_header_type":"","csco_page_load_nextpost":"","csco_page_subscribe_form":"","csco_page_contact_form":"","footnotes":""},"categories":[1401],"tags":[],"class_list":{"0":"post-31544","1":"post","2":"type-post","3":"status-publish","4":"format-standard","6":"category-git","7":"cs-entry","8":"cs-video-wrap"},"yoast_head":"\n\n
\n
OpenID Connect (OIDC) ve K\u0131sa \u00d6m\u00fcrl\u00fc Kimlik Bilgileri: Gelece\u011fin G\u00fcvenlik Standard\u0131<\/h2>\n
\n
Uzman \u0130pucu: OIDC ve G\u00fcvenlik<\/h3>\n
GitHub Actions ve OIDC Entegrasyonu Nas\u0131l Yap\u0131l\u0131r? (Vaka Analizi: AWS \u00dczerinden Da\u011f\u0131t\u0131m)<\/h2>\n
Ad\u0131m 1: AWS IAM Identity Provider Olu\u015fturma<\/h3>\n
\n
https:\/\/token.actions.githubusercontent.com<\/code><\/li>\nsts.amazonaws.com<\/code><\/li>\n<\/ul>\nAd\u0131m 2: AWS IAM Rol\u00fc Olu\u015fturma ve G\u00fcven Politikas\u0131 Ayarlama<\/h3>\n
\n{\n \"Version\": \"2012-10-17\",\n \"Statement\": [\n {\n \"Effect\": \"Allow\",\n \"Principal\": {\n \"Federated\": \"arn:aws:iam::YOUR_AWS_ACCOUNT_ID:oidc-provider\/token.actions.githubusercontent.com\"\n },\n \"Resource\": \"*\",\n \"Action\": \"sts:AssumeRoleWithWebIdentity\",\n \"Condition\": {\n \"StringEquals\": {\n \"token.actions.githubusercontent.com:aud\": \"sts.amazonaws.com\",\n \"token.actions.githubusercontent.com:sub\": \"repo:YOUR_GITHUB_ORG\/YOUR_REPO_NAME:ref:refs\/heads\/main\"\n }\n }\n }\n ]\n}\n<\/pre>\nYOUR_AWS_ACCOUNT_ID<\/code> yerine kendi AWS hesap kimli\u011finizi, YOUR_GITHUB_ORG\/YOUR_REPO_NAME<\/code> yerine de GitHub kurulu\u015f ad\u0131n\u0131z\u0131 ve depo ad\u0131n\u0131z\u0131 girmeniz gerekmektedir. ref:refs\/heads\/main<\/code> k\u0131sm\u0131, bu rol\u00fcn yaln\u0131zca main<\/code> dal\u0131ndan gelen i\u015f ak\u0131\u015flar\u0131 taraf\u0131ndan \u00fcstlenilebilece\u011fini belirtir. Daha da g\u00fcvenli bir yakla\u015f\u0131m i\u00e7in, tam yolu (ref:refs\/heads\/main<\/code>) yerine, belirli bir i\u015f ak\u0131\u015f\u0131n\u0131 (repo:YOUR_GITHUB_ORG\/YOUR_REPO_NAME:workflow:your-workflow-name.yml<\/code>) veya ortam\u0131 (repo:YOUR_GITHUB_ORG\/YOUR_REPO_NAME:environment:production<\/code>) hedefleyebilirsiniz. Bu, en az ayr\u0131cal\u0131k ilkesini uygulaman\u0131n anahtar\u0131d\u0131r.<\/p>\ns3:PutObject<\/code> ve s3:ListBucket<\/code> gibi izinlere sahip bir politika eklemeniz gerekebilir.<\/p>\nAd\u0131m 3: GitHub Actions \u0130\u015f Ak\u0131\u015f\u0131n\u0131 Yap\u0131land\u0131rma<\/h3>\n
.github\/workflows\/main.yml<\/code> gibi) a\u015fa\u011f\u0131daki de\u011fi\u015fiklikleri yapman\u0131z gerekecek:<\/p>\n\nname: AWS OIDC Da\u011f\u0131t\u0131m Ak\u0131\u015f\u0131\n\non:\n push:\n branches:\n - main\n\npermissions:\n id-token: write # Bu, JWT olu\u015fturmak i\u00e7in gereklidir\n contents: read # Kodu okumak i\u00e7in gereklidir\n\njobs:\n deploy:\n runs-on: ubuntu-latest\n steps:\n - name: Kodu \u00c7ek\n uses: actions\/checkout@v3\n\n - name: AWS Kimlik Bilgilerini Yap\u0131land\u0131r\n uses: aws-actions\/configure-aws-credentials@v2\n with:\n role-to-assume: arn:aws:iam::YOUR_AWS_ACCOUNT_ID:role\/YOUR_IAM_ROLE_NAME\n aws-region: eu-central-1 # Kendi AWS b\u00f6lgenizi girin\n\n - name: S3'e Da\u011f\u0131t\u0131m Yap (\u00d6rnek)\n run: |\n aws s3 sync . s3:\/\/your-s3-bucket-name --delete\n # \u00d6rne\u011fin, bir EC2'ye SSH ba\u011flant\u0131s\u0131 yapmak yerine, AWS CLI\/SDK kullanarak da\u011f\u0131t\u0131m yap\u0131n.\n # ssh anahtar\u0131 gerektiren ad\u0131mlar\u0131 do\u011frudan AWS CLI\/SDK ile de\u011fi\u015ftirin.\n<\/pre>\n\n
permissions: id-token: write<\/code>: Bu izin, GitHub Actions'\u0131n i\u015f ak\u0131\u015f\u0131n\u0131z i\u00e7in bir OIDC JWT olu\u015fturmas\u0131na olanak tan\u0131r. Bu olmadan OIDC \u00e7al\u0131\u015fmaz.<\/li>\naws-actions\/configure-aws-credentials@v2<\/code> eylemi: Bu eylem, GitHub taraf\u0131ndan olu\u015fturulan JWT'yi al\u0131r, AWS STS'ye (Security Token Service) g\u00f6nderir ve belirtti\u011finiz IAM rol\u00fcn\u00fc \u00fcstlenerek ge\u00e7ici AWS kimlik bilgilerini i\u015f ak\u0131\u015f\u0131 ortam\u0131na enjekte eder. Bu, i\u015f ak\u0131\u015f\u0131n\u0131z\u0131n sonraki ad\u0131mlar\u0131nda aws cli<\/code> veya AWS SDK'lar\u0131 kullanabilmesini sa\u011flar.<\/li>\nrole-to-assume<\/code>: Burada, Ad\u0131m 2'de olu\u015fturdu\u011funuz IAM rol\u00fcn\u00fcn ARN'ini (Amazon Resource Name) belirtmeniz gerekmektedir.<\/li>\naws-region<\/code>: Da\u011f\u0131t\u0131m yapaca\u011f\u0131n\u0131z AWS b\u00f6lgesini belirtin.<\/li>\n<\/ul>\nSSH Anahtar\u0131 Gerektiren \u0130\u015flemler Nas\u0131l De\u011fi\u015ftirilir?<\/h3>\n
scp<\/code> ile dosya kopyalama, ssh<\/code> ile komut \u00e7al\u0131\u015ft\u0131rma) OIDC ve AWS CLI\/SDK ile de\u011fi\u015ftirmelisiniz. \u0130\u015fte birka\u00e7 \u00f6rnek:<\/p>\n\n
\naws s3 cp .\/build\/my-app.zip s3:\/\/your-app-distribution-bucket\/latest.zip\n <\/pre>\n\n - name: EC2 \u00dczerinde Komut \u00c7al\u0131\u015ft\u0131r\n run: |\n aws ssm send-command \\\n --instance-ids \"i-0abcdef1234567890\" \\\n --document-name \"AWS-RunShellScript\" \\\n --parameters 'commands=[\"sudo systemctl restart my-app.service\"]' \\\n --comment \"Uygulamay\u0131 yeniden ba\u015flat\"\n <\/pre>\nDi\u011fer G\u00fcvenli Alternatifler ve En \u0130yi Uygulamalar Nelerdir?<\/h2>\n
GitHub Secrets (Yine de Dikkatli Kullan\u0131lmal\u0131)<\/h3>\n
\n
\n
production<\/code> ortam\u0131na ait s\u0131rlar yaln\u0131zca production<\/code> da\u011f\u0131t\u0131m\u0131 i\u00e7in kullan\u0131labilir) veya belirli dallarla ili\u015fkilendirilmesini sa\u011flay\u0131n. GitHub'\u0131n ortam koruma kurallar\u0131 bu konuda yard\u0131mc\u0131 olabilir.<\/li>\nBulut Sa\u011flay\u0131c\u0131lar\u0131n Y\u00f6netilen Kimlik Hizmetleri (Managed Identity)<\/h3>\n
\n
En \u0130yi Uygulamalar ve G\u00fcvenlik \u0130pu\u00e7lar\u0131<\/h3>\n
\n
\u0130leri D\u00fczey \u0130pu\u00e7lar\u0131 ve Optimizasyonlar: OIDC Kullan\u0131m\u0131n\u0131 Geli\u015ftirmek<\/h2>\n
Daha Hassas Ko\u015fullar ile IAM Politikalar\u0131n\u0131 G\u00fc\u00e7lendirme<\/h3>\n
\n
sub<\/code> (Subject): JWT'nin kime ait oldu\u011funu belirtir. Genellikle repo:repo:environment<\/code>: E\u011fer GitHub ortamlar\u0131 kullan\u0131yorsan\u0131z, environment:actor<\/code>: \u0130\u015f ak\u0131\u015f\u0131n\u0131 ba\u015flatan GitHub kullan\u0131c\u0131s\u0131n\u0131n kullan\u0131c\u0131 ad\u0131.<\/li>\nevent_name<\/code>: \u0130\u015f ak\u0131\u015f\u0131n\u0131 tetikleyen olay\u0131n ad\u0131 (\u00f6rne\u011fin, push<\/code>, pull_request<\/code>).<\/li>\nref_type<\/code>: Referans tipi (\u00f6rne\u011fin, branch<\/code>, tag<\/code>).<\/li>\n<\/ul>\n\n{\n \"Version\": \"2012-10-17\",\n \"Statement\": [\n {\n \"Effect\": \"Allow\",\n \"Principal\": {\n \"Federated\": \"arn:aws:iam::YOUR_AWS_ACCOUNT_ID:oidc-provider\/token.actions.githubusercontent.com\"\n },\n \"Action\": \"sts:AssumeRoleWithWebIdentity\",\n \"Condition\": {\n \"StringEquals\": {\n \"token.actions.githubusercontent.com:aud\": \"sts.amazonaws.com\"\n },\n \"StringLike\": {\n \"token.actions.githubusercontent.com:sub\": \"repo:my-org\/my-app:*\",\n \"token.actions.githubusercontent.com:ref\": \"refs\/heads\/main\"\n },\n \"ForAllValues:StringLike\": {\n \"token.actions.githubusercontent.com:environment\": \"production\"\n }\n }\n }\n ]\n}\n<\/pre>\nmy-org\/my-app<\/code> deposundaki herhangi bir i\u015f ak\u0131\u015f\u0131n\u0131n, main<\/code> dal\u0131ndan \u00e7al\u0131\u015ft\u0131r\u0131ld\u0131\u011f\u0131nda ve production<\/code> ortam\u0131n\u0131 hedefledi\u011finde rol\u00fc \u00fcstlenmesine izin verir. Bu seviyedeki detay, g\u00fcvenlik riskini minimuma indirmek i\u00e7in \u00e7ok \u00f6nemlidir.<\/p>\n\u00c7oklu Bulut ve Hibrit Ortamlarda OIDC Kullan\u0131m\u0131<\/h3>\n
\n
CI\/CD Ortam G\u00fcvenli\u011fi i\u00e7in Ek \u0130pu\u00e7lar\u0131<\/h3>\n
\n
<\/code> i\u00e7eri\u011fi \u00fcretti\u011fi i\u00e7in do\u011frudan CSS media query kodlar\u0131 i\u00e7eremez, ancak bu bir web geli\u015ftirme ipucudur.)<\/li>\n<\/ol>\nSonu\u00e7: Gelece\u011fin CI\/CD G\u00fcvenli\u011fi OIDC ile \u015eekilleniyor<\/h2>\n
S\u0131k\u00e7a Sorulan Sorular<\/h2>\n
OIDC sadece AWS ile mi \u00e7al\u0131\u015f\u0131r?<\/h3>\n
Mevcut SSH anahtarlar\u0131m\u0131 OIDC'ye nas\u0131l ta\u015f\u0131r\u0131m?<\/h3>\n
configure-aws-credentials<\/code> (veya e\u015fde\u011feri) gibi eylemleri kullan\u0131p OIDC ile kimlik do\u011frulamay\u0131 ba\u015flat\u0131rs\u0131n\u0131z. En son ad\u0131mda, SSH anahtar\u0131n\u0131 tamamen devre d\u0131\u015f\u0131 b\u0131rak\u0131p GitHub Secrets'tan kald\u0131r\u0131rs\u0131n\u0131z.<\/p>\nOIDC kullan\u0131rken GitHub Secrets'\u0131 yine de kullanabilir miyim?<\/h3>\n
OIDC'nin performansa etkisi var m\u0131d\u0131r?<\/h3>\n
OIDC'yi kullan\u0131rken denetlenebilirlik nas\u0131l sa\u011flan\u0131r?<\/h3>\n