CI/CD'de Proxy Kimlik Bilgilerini Sızıntısız Saklama ve Aktarma: Adım Adım Rehber

Proxy kimlik bilgileri, düşünülenden daha sık kamuya açık derleme loglarına düşer. Dikkatsiz bir curl -v, açıkta kalan bir değişken, URL içindeki bir parola — ve kullanıcı adınızla parolanız tüm ekibin görebileceği pipeline geçmişinde yerini almış olur. Bu rehberde, bunu nasıl önleyeceğinizi adım adım ele alacağız.

Giriş: Proxy kimlik bilgileri loglara ve geçmişe nasıl sızar?

Tipik bir senaryo düşünün. Harici kaynaklara erişmek için Proxeon proxy'si üzerinden geçen bir derleme yapılandırıyorsunuz. Bağlantıyı hızlıca test etmek için parolayı doğrudan adrese yazıyorsunuz: http://user:pass@host:port. Derleme başarılı olur, sevinirsiniz. Bir hafta sonra parolanın her çalıştırmanın logunda, çalıştırıcıdaki shell geçmişinde ve hatta istemcinin hata ayıklama çıktısında göründüğünü fark edersiniz.

Bu nadir bir durum değil, aksine kaçınılmazdır. Proxy kimlik bilgilerinin hoş olmayan bir özelliği vardır: neredeyse her ağ çağrısında gereklidirler, bu yüzden aynı anda onlarca yere kolayca sızabilirler.

Sonunda ne elde edeceksiniz?

Bu rehberi tamamladıktan sonra CI/CD'nizi, proxy kimlik bilgilerinin hiçbir logda, komut geçmişinde veya depoda görünmeyeceği şekilde yapılandırabileceksiniz. Popüler sistemlerin sırlarını kullanmayı, tehlikeli hata ayıklama modlarını kapatmayı, derlemeleri durdurmadan parolayı güvenle değiştirmeyi ve tüm bunları hazır bir komut dosyasıyla kontrol etmeyi öğreneceksiniz.

Bu rehber kimler için?

İçerik, orta düzey mühendisler için tasarlanmıştır: DevOps, backend geliştiricileri, QA otomasyon uzmanları. Pipeline çalıştırmayı biliyor ve ortam değişkeninin ne olduğunu anlıyorsanız, burada kendinizi rahat hissedeceksiniz. İleri düzey okuyucular rotasyon ve denetim bölümlerini faydalı bulacaktır.

Önceden bilmeniz gerekenler

http_proxy ve no_proxy değişkenlerinin temel yapılandırmasını burada yeniden anlatmıyoruz — buna ayrı bir materyal ayrılmıştır. Proxy bağlantınızın zaten çalıştığı ve görevinizin artık kimlik bilgilerini güvenli bir şekilde saklamak olduğu varsayılır.

Ne kadar zaman gerekir?

Okumak ve anlamak yaklaşık 40 dakika sürer. Tek bir pipeline'a uygulamak, CI sistemine bağlı olarak 30 dakika ile bir buçuk saat arasında değişir. Rotasyon ve sızıntı kontrolünü daha sonra eklersiniz; her biri 15–20 dakika sürer.

Ön hazırlık: Neler gerekecek?

Başlamadan önce ihtiyacınız olan her şeyi toplayın. Bu, zamandan tasarruf sağlar ve işin ortasında kesintilere karşı korur.

Araçlar ve erişimler

• Ayarları ve sırları düzenleme yetkisiyle CI/CD projenize erişim.
• Kullanıcı adı, parola, ana bilgisayar ve port içeren aktif bir Proxeon proxy aboneliği.
• curl, git ve örnekleri deneyecekseniz Python 3 ve Node.js yorumlayıcılarının kurulu olduğu yerel bir makine.
• Pipeline yapılandırma dosyalarını düzenlemek için bir metin düzenleyici.

Sistem gereksinimleri

Özel bir gereksinim yoktur. Her şey Linux, macOS ve Windows üzerinde çalışır. CI çalıştırıcıları genellikle Linux tabanlıdır, bu nedenle örneklerin çoğu bash sözdizimindedir. Windows çalıştırıcıları için farklılıklardan ayrıca bahsedeceğiz.

Önceden hazırlanacaklar

Mevcut proxy kimlik bilgilerinizi güvenilir bir parola yöneticisine kaydedin. Sırları yapılandırırken işinize yarayacaklar. Bunları masaüstündeki düz bir metin dosyasında saklamayın.

İpucu: Proxeon tarifeniz izin veriyorsa CI için ayrı bir proxy hesabı açın. Böylece derleme kimlik bilgilerinin ele geçirilmesi kişisel kimlik bilgilerinizi etkilemez ve tam tersi de geçerlidir.

Yapılandırmanın yedek kopyası

Pipeline'ı değiştirmeden önce mevcut yapılandırma dosyasının bir kopyasını alın. .gitlab-ci.yml, workflow dosyası veya Jenkinsfile dosyasını deponun dışında ayrı bir klasöre kopyalamanız yeterlidir.

⚠️ Dikkat: Yedek kopyayı asla parolayla birlikte aynı depoya işlemeyin. Geçici bir dalda bile kimlik bilgileri git geçmişine sonsuza dek girer.

Temel kavramlar: Basit anlatımla terimler

Daha sonra kafa karışıklığı yaşamamak için anahtar kelimeleri inceleyelim.

Proxy kimlik bilgileri

İstemcinizin Proxeon proxy'sini kullanma hakkını doğrulamak için kullandığı kullanıcı adı ve paroladır. Bazen kullanıcı adı/parola yerine IP'ye bağlama kullanılır, ancak burada kullanıcı adı/parola çiftinden bahsediyoruz.

CI'da sır

Sır, CI sistemi içinde hassas bir değeri koyduğunuz özel bir depodur. Sistem onu şifreler ve derlemeye bir ortam değişkeni olarak eklerken otomatik olarak loglarda gizler.

Maskeleme

Maskeleme, CI'ın sır değerini çıktıda yıldız işaretleriyle değiştirmesidir. Parola yanlışlıkla yazdırılırsa, onun yerine [MASKED] gibi bir şey görürsünüz. Her zaman mükemmel çalışmaz, bu yüzden birden çok korumayı birleştireceğiz.

Proxy-Authorization başlığı

İstemci proxy'de kimlik doğrulaması yaptığında, kodlanmış kimlik bilgileriyle birlikte bir Proxy-Authorization HTTP başlığı gönderir. Ayrıntılı hata ayıklama modunda birçok istemci bu başlığın tamamını yazdırır. Kodunu çözmek önemsizdir, bu nedenle bu çıktı bir sızıntı olarak kabul edilir.

Kapsam

Kapsam, sırrın hangi derlemelerde kullanılabilir olduğunu belirler. Doğru şekilde sınırlandırılmış bir sır yalnızca korunan dallarda görünür ve çatallara veya dışarıdan gelen pull request'lere girmez.

İpucu: Ana ilkeyi unutmayın: sır, işlem belleğinde yalnızca gerektiği kadar yaşamalı ve diskte ve çıktıda hiçbir iz bırakmamalıdır.

Adım 1: Ana tuzağı anlayın — URL'deki parola

Aşamanın hedefi: En yaygın sızıntı kaynağını tanımayı öğrenmek ve ondan sonsuza dek vazgeçmek.

En yaygın hata, kimlik bilgilerini doğrudan proxy adresine yazmaktır: http://user:pass@host:port. Kullanışlı olduğu için neredeyse tüm yeni başlayanlar böyle yapar. Sorun şu ki, böyle bir URL beklenmedik yerlerde ortaya çıkar.

URL'deki parola tam olarak nerede ortaya çıkar?

1. İşlem listesi. Çalıştırıcıdaki ps komutu, parola dahil tam çalıştırma satırını gösterir. Aynı makinedeki herhangi bir işlem bunu okuyabilir.
2. Proxy'nin kendi logları. Bazı sunucu logları bağlantı dizesini kaydeder. URL parola içeriyorsa, parola loga işlenir.
3. Shell komut geçmişi. .bash_history dosyası, URL'deki parola dahil girdiğiniz her şeyi saklar.
4. İstemcinin hata ayıklama çıktısı. Ayrıntılı modda başlatıldığında istemci, hedef adresi kimlik bilgileriyle birlikte yazdırır.
5. CI logları. URL'yi içeren değişken sır olarak işaretlenmemişse, echo aşamasında veya bir hata sırasında açıkça yazdırılır.

Hemen kontrol edin. Herhangi bir makinede zararsız bir komut çalıştırın ve işlem listesine bakın.

curl -x http://myuser:mypass@proxy.proxeon.net:8080 https://example.com & ps aux | grep curl

ps çıktısında parolanızı açıkça göreceksiniz. Ortadan kaldırdığımız sızıntı tam olarak budur.

⚠️ Dikkat: Derleme özel olsa bile, çalıştırıcının işlem listesine başka bir işlem, paylaşılan çalıştırıcıdaki başka bir iş veya bir izleme aracı erişebilir. URL'deki parolayı herkese açık kabul edin.

Beklenen sonuç: beş sızıntı noktasını anlıyor ve proxy adresinin içine asla parola yazmayacaksınız.

✅ Kontrol: yukarıdaki test komutunu çalıştırın ve ps çıktısında parolayı gördüğünüzden emin olun. Görüyorsanız, sorunu doğru şekilde yeniden ürettiniz ve çözmeye hazırsınız.

Adım 2: Doğru yol — ortam değişkenleri ve kimlik bilgisi dosyaları

Aşamanın hedefi: kimlik bilgilerini URL'den güvenli depolara — ortam değişkenlerine ve özel dosyalara — taşımak.

Fikir basittir. Kullanıcı adını ve parolayı adresten ayrı olarak saklarız. İstemci, komut satırından değil, ortamdan veya kısıtlı izinlere sahip bir dosyadan okur. Bu şekilde işlem listesine ve geçmişe düşmezler.

Seçenek A: Ortam değişkenleri

Birçok istemci proxy kimlik bilgilerini ortamdan okuyabilir. Örneklerle inceleyelim.

Ortam değişkeni aracılığıyla curl

Proxy adresini kimlik bilgileri olmadan ayarlayın ve kullanıcı adı ile parolayı, değeri değişkenden alınan ayrı bir bayrakla iletin.

1. Kimlik bilgilerini içeren değişkeni ortama aktarın (CI'da bunu bir sır yapacaktır, yerel olarak güvenli bir kaynak).
2. Değerini URL'de değil, -U bayrağıyla iletin.

export PROXY_CREDS="$PROXEON_USER:$PROXEON_PASS"; curl -x http://proxy.proxeon.net:8080 -U "$PROXY_CREDS" https://example.com

-U bayrağı değişkenle birlikte URL'deki paroladan daha iyidir, ancak yine de ps çıktısında görünür. Bu nedenle aşağıda bahsedilen kimlik bilgisi dosyası tercih edilir.

Python requests

Python'da kimlik bilgilerini os.environ üzerinden okuyun ve proxies sözlüğünü bellekte oluşturun. Hiçbir şey yazdırmayın.

import os, requests; user=os.environ['PROXEON_USER']; pwd=os.environ['PROXEON_PASS']; proxy=f'http://{user}:{pwd}@proxy.proxeon.net:8080'; r=requests.get('https://example.com', proxies={'http':proxy,'https':proxy}); print(r.status_code)

Burada parola, Python işleminin içindeki bir değişkende kalır ve komut satırına girmez. Önemli olan, proxy değişkenini bir bütün olarak loglamamaktır.

Node.js

Node'da da kimlik bilgilerini process.env üzerinden alın ve proxy aracısını kodda oluşturun.

const user=process.env.PROXEON_USER; const pass=process.env.PROXEON_PASS; const proxyUrl=`http://${user}:${pass}@proxy.proxeon.net:8080`; const {HttpsProxyAgent}=require('https-proxy-agent'); const agent=new HttpsProxyAgent(proxyUrl); fetch('https://example.com',{agent}).then(r=>console.log(r.status));

İpucu: Her dilde, loga yalnızca yanıt durumunu ve gerekiyorsa hedef ana bilgisayarı yazdırın. Proxy ayarlarını içeren nesnenin tamamını asla yazdırmayın — içinde parola vardır.

Seçenek B: .netrc dosyası

.netrc dosyası, kimlik bilgilerini komutlardan ayrı saklamanın klasik bir yoludur. curl bunu otomatik olarak okuyabilir.

1. CI sırrından çalıştırıcının ana dizininde anında bir .netrc dosyası oluşturun.
2. Makine, kullanıcı adı ve parola içeren satırı yazın.
3. Dosyayı yalnızca sahibinin okuyabilmesi için 600 izinlerini ayarlayın.
4. curl'ü netrc kullanım bayrağıyla çalıştırın.

printf 'machine proxy.proxeon.net login %s password %s' "$PROXEON_USER" "$PROXEON_PASS" > ~/.netrc; chmod 600 ~/.netrc; curl --netrc -x http://proxy.proxeon.net:8080 https://example.com

Artık parola ne komut satırında ne de işlem listesinde görünmez. 600 iznine sahip dosyada durur ve derleme sonunda silersiniz.

⚠️ Dikkat: 600 izni zorunludur. Aksi takdirde curl dosyayı okumayı reddedebilir ve dosya makinedeki diğer kullanıcılar tarafından erişilebilir hale gelir.

Seçenek C: curl yapılandırması

curl bayrakları bir yapılandırma dosyasından okuyabilir. Proxy ve kimlik bilgilerini oraya koyun ve 600 iznini ayarlayın.

printf 'proxy = http://proxy.proxeon.net:8080\nproxy-user = "%s:%s"\n' "$PROXEON_USER" "$PROXEON_PASS" > ~/.curlrc; chmod 600 ~/.curlrc; curl https://example.com

600 iznine sahip bir .curlrc varsa, kimlik bilgileri işlemde ve komut geçmişinde görünmez.

Seçenek D: Uygulama istemci yapılandırması

Kendi yapılandırmanızı okuyan bir uygulamanız varsa, proxy kimlik bilgilerini deponun dışında bir yapılandırma dosyasında saklayın. Depoda yalnızca yer tutucuları olan bir şablon tutun ve gerçek değerleri çalıştırıcıda sırlardan değiştirin.

Beklenen sonuç: hiçbir örnekte parola komut satırında ve işlem listesinde görünmez. Ya işlem içindeki bir değişkende ya da 600 iznine sahip bir dosyada yaşar.

✅ Kontrol: herhangi bir örneği çalıştırın ve paralel olarak ps aux | grep curl komutunu çalıştırın. Çıktıda parola olmamalıdır. netrc kullanıyorsanız, ls -l ~/.netrc ile izinleri kontrol edin — -rw------- olmalıdır.

Adım 3: Popüler CI'larda Sırlar — GitHub Actions, GitLab CI, Jenkins

Aşamanın hedefi: proxy kimlik bilgilerini CI sisteminizin korumalı deposuna koymak ve sızıntısız şekilde değiştirmek.

GitHub Actions

GitHub'da sırlar depo veya organizasyon düzeyinde saklanır.

1. Depoyu açın ve Settings bölümüne gidin.
2. Solda Secrets and variables — Actions bölümünü bulun.
3. New repository secret düğmesine tıklayın.
4. PROXEON_USER gibi bir ad ve değer olarak kullanıcı adınızı girin. Kaydedin.
5. Parola için PROXEON_PASS ile tekrarlayın.

Workflow'da sırlara secrets bağlamı üzerinden erişin ve bunları ortam değişkenleri olarak bir adıma iletin.

steps: - name: request env: PROXEON_USER: ${{ secrets.PROXEON_USER }} PROXEON_PASS: ${{ secrets.PROXEON_PASS }} run: printf 'machine proxy.proxeon.net login %s password %s' "$PROXEON_USER" "$PROXEON_PASS" > ~/.netrc; chmod 600 ~/.netrc; curl --netrc -x http://proxy.proxeon.net:8080 https://example.com

GitHub, sır değerlerini loglarda otomatik olarak gizler. Parola yanlışlıkla yazdırılırsa, üç yıldız işareti görürsünüz.

⚠️ Dikkat: Sırlar varsayılan olarak pull_request üzerinden çatallardan başlatılan workflow'larda kullanılamaz. Gerekmedikçe bu davranışı pull_request_target olarak değiştirmeyin — aksi takdirde harici bir katkıda bulunan kimlik bilgilerinizi alabilir.

GitLab CI

GitLab'da sırlara CI/CD değişkenleri denir ve projede yapılandırılır.

1. Projeyi açın, Settings — CI/CD bölümüne gidin.
2. Variables bölümünü genişletin ve Add variable düğmesine tıklayın.
3. PROXEON_USER anahtarını ve değeri girin.
4. Değerin loglarda gizlenmesi için Masked onay kutusunu işaretleyin.
5. Değişkenin yalnızca korunan dallar ve etiketler için kullanılabilir olması için Protected onay kutusunu işaretleyin.
6. PROXEON_PASS için tekrarlayın.

.gitlab-ci.yml içinde değişkenler otomatik olarak ortam olarak kullanılabilir.

request: script: - printf 'machine proxy.proxeon.net login %s password %s' "$PROXEON_USER" "$PROXEON_PASS" > ~/.netrc - chmod 600 ~/.netrc - curl --netrc -x http://proxy.proxeon.net:8080 https://example.com

İpucu: GitLab'daki Masked bayrağı yalnızca kuralları karşılayan değerler için çalışır: minimum uzunluk, satır sonu yok, base64 uyumlu karakter kümesi. Parola maskelenmezse GitLab kaydederken bir uyarı gösterir. Bu durumda parolayı gereksinimleri karşılayacak şekilde değiştirin.

Jenkins

Jenkins'te kimlik bilgileri Credentials bölümünde saklanır ve Credentials Binding eklentisi aracılığıyla eklenir.

1. Manage Jenkins — Credentials bölümünü açın.
2. Örneğin System ve Global credentials gibi bir alan seçin.
3. Add Credentials düğmesine tıklayın.
4. Username with password türünü seçin.
5. Kullanıcı adını ve parolayı girin, proxeon-creds gibi anlaşılır bir kimlik (ID) verin.

Jenkinsfile'da kullanımı withCredentials bloğuyla sarın. Jenkins değerleri konsolda gizler.

withCredentials([usernamePassword(credentialsId: 'proxeon-creds', usernameVariable: 'PROXEON_USER', passwordVariable: 'PROXEON_PASS')]) { sh 'printf "machine proxy.proxeon.net login %s password %s" "$PROXEON_USER" "$PROXEON_PASS" > ~/.netrc; chmod 600 ~/.netrc; curl --netrc -x http://proxy.proxeon.net:8080 https://example.com' }

⚠️ Dikkat: Jenkins yalnızca Credentials Binding aracılığıyla tanımlanan değerleri gizler. Parolayı Groovy'de bir dize olarak birleştirir ve yazdırırsanız, maskeleme çalışmaz. Kimlik bilgileriyle yalnızca withCredentials bloğunun içinde ve yalnızca sh adımlarında çalışın.

Beklenen sonuç: kimlik bilgileri CI sisteminizin korumalı deposunda durur, derlemeye ortam olarak eklenir ve loglarda gizlenir.

✅ Kontrol: bir derleme çalıştırın ve logu açın. Parola yerine yıldız işaretleri veya maskeleme işaretini gördüğünüzden emin olun. Değişkeni bilerek echo ile yazdırmayı deneyin — sistem onu gizlemelidir.

Adım 4: Loglar — Proxy-Authorization yazdıran modları kapatın

Aşamanın hedefi: yetkilendirme başlığını açığa çıkaran ayrıntılı çıktıyı kaldırmak ve güvenli bir günlük düzeyi bırakmak.

CI maskeleme her derde deva değildir. İstemci Proxy-Authorization başlığını base64 olarak yazdırırsa ve sistem orijinal parolayı tam olarak bilmiyorsa maskeleme çalışmayabilir. Bu nedenle kaynaktaki tehlikeli modları kapatıyoruz.

curl

-v ve özellikle --trace bayrakları, proxy yetkilendirmesi dahil başlıkları yazdırır. CI'da sessiz modu kullanın.

1. Derleme komutlarından -v, --verbose, --trace ve --trace-ascii bayraklarını kaldırın.
2. Hata kontrolü için -sS kullanın: sessiz ama hataları gösterir.
3. Hata ayıklama gerekiyorsa --trace yalnızca yerel olarak ve asla CI'da kullanın.

curl -sS --netrc -x http://proxy.proxeon.net:8080 https://example.com -o /dev/null -w '%{http_code}'

Böylece çıktıda tek bir başlık olmadan yalnızca yanıt kodunu alırsınız.

Python requests

requests kitaplığı varsayılan olarak kimlik bilgilerini yazdırmaz, ancak urllib3'ün DEBUG düzeyinde günlüğü istek başlıklarını gösterir. Günlük düzeyini WARNING veya INFO'da tutun.

import logging; logging.getLogger('urllib3').setLevel(logging.WARNING)

İpucu: Teşhis için yine de DEBUG gerekiyorsa, Proxy-Authorization başlığını mesajlardan kesen bir günlük filtresi ekleyin. Ancak yerel olarak teşhis etmek ve CI'da WARNING tutmak daha kolaydır.

Node.js

Node'da CI'da NODE_DEBUG=http ortam değişkenini ayarlamaktan kaçının — başlıkları gösterir. Ayrıca agent nesnesini ve istek nesnesinin tamamını yazdırmayın.

1. NODE_DEBUG'ü çalıştırıcı ortamından kaldırın.
2. Hata işleyicilerinde yalnızca error.message yazdırın, tüm nesneyi değil.
3. Üretim derlemelerinde HTTP istek günlükçü kitaplıkları kullanmayın.

⚠️ Dikkat: İşlenmemiş bir istisnanın yığın izi, parolalı bir URL oluşturduysanız proxy URL'sini de içerebilir. Bu, parolayı URL'ye koymamanın ve netrc veya ayrı alanlar kullanmanın bir başka nedenidir.

Beklenen sonuç: CI'daki hiçbir araç yetkilendirme başlığını ve tam proxy URL'sini yazdırmaz.

✅ Kontrol: derlemeyi çalıştırın ve logda Proxy-Authorization, Basic ve kullanıcı adınızı arayın. Hiçbir eşleşme olmamalıdır.

Adım 5: Proxy parolasını derlemeleri durdurmadan döndürme

Aşamanın hedefi: parolayı derlemeler düşmeden ve eski parola çalışmayı bırakacak şekilde değiştirmeyi öğrenmek.

Proxy parolası periyodik olarak ve herhangi bir sızıntı şüphesinden sonra mutlaka değiştirilmelidir. Görev, bunu kesinti olmadan yapmaktır.

Örtüşme stratejisi

İdeal seçenek, bir süre hem eski hem de yeni parolanın geçerli olmasıdır. Proxeon tarifeniz ikinci bir hesap veya ek bir kimlik bilgisi seti oluşturmanıza izin veriyorsa, bunu kullanın.

1. Eski kimlik bilgilerini silmeden Proxeon kişisel hesabınızda yeni kimlik bilgileri oluşturun.
2. Yeni değerleri PROXEON_USER_NEW gibi geçici adlarla CI sırlarına ekleyin.
3. Pipeline'ı ayrı bir dalda yeni adlara geçirin ve bir derleme çalıştırın.
4. Derlemenin yeni kimlik bilgileriyle geçtiğinden emin olun.
5. Ana sırların PROXEON_USER ve PROXEON_PASS değerlerini yenileriyle değiştirin.
6. Geçici sırları kaldırın.
7. Proxeon hesabınızda eski kimlik bilgilerini iptal edin.

Böylece her an çalışan bir kimlik bilgisi seti vardır ve derlemeler düşmez.

Örtüşme yoksa

Yalnızca bir çift kimlik bilgisi varsa, sakin bir pencerede hareket edin.

1. Derleme etkinliğinin en az olduğu bir zaman seçin.
2. Birkaç dakikalığına yeni pipeline başlatmalarını duraklatın.
3. Proxeon hesabınızda parolayı değiştirin.
4. CI'daki sır değerini hemen güncelleyin.
5. Bir test derlemesi çalıştırın.
6. Normal işleyişe devam edin.

İpucu: Kısa bir rotasyon prosedürü hazırlayın ve pipeline açıklamasının yanında saklayın. Sızıntı sonrası stresli bir durumda hazır bir adım listesi sinirlerinizi ve zamanınızı kurtarır.

⚠️ Dikkat: Parolayı değiştirdikten sonra, çalıştırıcıda derlemeler arasında önbelleğe alınıyorsa eski netrc veya curlrc dosyasını mutlaka silin. Aksi takdirde istemci eski kimlik bilgilerini kullanmaya devam eder.

Beklenen sonuç: parola değiştirildi, yeni derlemeler yeni kimlik bilgileriyle çalışıyor, eski parola artık çalışmıyor.

✅ Kontrol: eski parolayla bir istek çalıştırmayı deneyin — proxy yetkilendirme hatası dönmelidir. Yeni derleme başarılı olmalıdır.

Adım 6: Sızıntı kontrolü — hazır denetim komut dosyası

Aşamanın hedefi: kimlik bilgilerinin yapıtlarda, loglarda ve depoda olmadığından emin olmak ve bu kontrolü otomatikleştirmek.

Nerede aranmalı

• Derleme yapıtları: derlenmiş dosyalar, raporlar, dökümler.
• Pipeline logları, eski çalıştırmalar dahil.
• Git deposu geçmişi.
• Çalıştırıcının önbellekleri ve geçici dosyaları.

Yapıtlarda ve loglarda arama

Yapıtları ve logları yerel bir klasöre indirin ve karakteristik işaretçileri arayın: kullanıcı adı, parolanın parçası, Basic kelimesi ve yetkilendirme başlığı.

grep -RniE 'proxy-authorization|Basic [A-Za-z0-9+/=]{8,}|proxeon.*login|:[^@/]+@proxy' ./artifacts ./logs

Komut dosyası yetkilendirme başlığını, Basic kelimesinden sonraki base64 dizelerini, netrc'deki oturum açma şablonunu ve @ işaretinden önce URL'deki parolanın işaretini arar. Herhangi bir eşleşme araştırma nedenidir.

Git geçmişinde arama

Parola eski bir commit'e girmiş olabilir. Tüm geçmişi kontrol edin.

git log -p -S 'proxy.proxeon.net' --all | grep -nE ':[^@/]+@proxy|password [^ ]+'

⚠️ Dikkat: Git geçmişinde bir parola bulunursa, dosyayı silmek yeterli değildir — eski commit'lerde kalır. Geçmişi özel araçlarla yeniden yazmak ve daha da önemlisi derhal parolayı değiştirmek gerekir. Böyle bir parolayı tehlikeye girmiş sayın.

Pipeline'da otomasyon

Yayınlamadan önce derlenen yapıtları tarayan ve bir bulgu durumunda başarısız olan ayrı bir iş ekleyin. Böyle bir güvenlik önlemi, sızıntıyı dışarı çıkmadan önce yakalar.

leak_check: script: - if grep -RniE 'proxy-authorization|Basic [A-Za-z0-9+/=]{8,}' ./artifacts; then echo 'LEAK DETECTED'; exit 1; fi

İpucu: Ek olarak, yerel olarak pre-commit aşamasında hazır sır tarayıcıları bağlayın. Kimlik bilgilerini daha commit'e girmeden yakalarlar ve depoya girmelerini engellerler.

Beklenen sonuç: manuel denetim ve otomatik iş, kimlik bilgilerinin hiçbir yerde olmadığını doğrular.

✅ Kontrol: denetim komut dosyasını çalıştırın — eşleşme olmadan tamamlanmalıdır. Ardından, yapıta Basic işaretli bir test dizesi koyun ve komut dosyasının onu bulduğundan ve başarısız olduğundan emin olun.

Adım 7: Pipeline'ı yayınlamadan önce kontrol listesi

Aşamanın hedefi: pipeline'ı çalıştırmadan önce son kontrolü yapmak.

Listeyi gözden geçirin ve her maddeyi işaretleyin. Biri bile yapılmadıysa pipeline'ı yayınlamayın.

1. Proxy parolası user:pass@host biçimindeki URL'lerin içinde hiçbir yerde yazılı değil.
2. Kullanıcı adı ve parola yalnızca CI sırlarında saklanıyor, depo dosyalarında değil.
3. Sırlar maskelenebilir ve korumalı olarak işaretlenmiş.
4. Sırlar çatallardan ve harici pull request'lerden gelen derlemelere açık değil.
5. Komutlardan ayrıntılı mod ve izleme bayrakları kaldırılmış.
6. HTTP kitaplıklarının günlük düzeyi DEBUG değil.
7. NODE_DEBUG gibi hata ayıklama değişkenleri çalıştırıcı ortamında yok.
8. netrc ve curlrc dosyaları anında oluşturuluyor ve 600 iznine sahip.
9. Kimlik bilgisi dosyaları derleme sonunda siliniyor veya geçici bir çalıştırıcıda yaşıyor.
10. Pipeline'da sızıntı kontrolü için bir iş var.
11. Git geçmişi kontrol edilmiş ve kimlik bilgisi içermiyor.
12. Parola rotasyonu için bir prosedür var.

İpucu: Bu kontrol listesini bir şablon olarak kaydedin ve proxy kullanılan her yeni pipeline'a ekleyin. Tutarlılık hata sayısını azaltır.

✅ Kontrol: on iki maddenin tümü işaretlenmiş. Ancak o zaman pipeline yayına hazırdır.

Sonucu doğrulama: Her şeyin çalıştığından nasıl emin olunur?

Son kontrolü tek bir senaryoda toplayalım.

İşlevsellik kontrol listesi

• Derleme Proxeon proxy'si üzerinden başarıyla geçiyor ve gerekli yanıtları alıyor.
• Derleme logunda parola, kullanıcı adı, base64 yetkilendirme dizeleri ve tam proxy URL'si yok.
• İstek sırasında çalıştırıcının işlem listesinde parola yok.
• Yapıtlar temiz, denetim komut dosyası eşleşme bulmuyor.
• Sırlar kasıtlı echo'da bile maskeleniyor.

Nasıl test edilir?

1. Tam pipeline'ı baştan sona çalıştırın.
2. Logu açın ve kullanıcı adıyla arama yapın — eşleşme olmamalıdır.
3. Yapıtları indirin ve denetim komut dosyasını üzerlerinde çalıştırın.
4. Sızıntı kontrolü işini kontrol edin — yeşil geçmelidir.

Başarı göstergeleri

Başarı şöyle görünür: derleme yeşil, proxy üzerinden istekler geçiyor ve olası tüm yerlerde yapılan arama kimlik bilgilerinin tek bir parçasını bile bulamıyor. Durum buysa rehberin hedefine ulaştınız.

Sık karşılaşılan hatalar ve çözümler

Sık karşılaşılan sorunları sorun, neden, çözüm şemasıyla inceleyelim.

Sorun 1: Parola hala logda görünüyor

Neden: Değişken normal bir değişken olarak oluşturulmuş, sır olarak değil veya maskelenebilir olarak işaretlenmemiş.

Çözüm: Değeri sırlar bölümüne taşıyın, maskelemeyi açın ve değişken adının yapılandırma ile depoda eşleştiğini doğrulayın.

Sorun 2: GitLab'da maskeleme çalışmıyor

Neden: Parola maskeleme için izin verilmeyen karakterler veya satır sonları içeriyor.

Çözüm: Parolayı maskeleme gereksinimlerini karşılayan, yeterli uzunlukta, harf, rakam ve izin verilen karakterlerden oluşan bir dizeyle değiştirin.

Sorun 3: curl netrc'yi okumuyor

Neden: Dosyanın izinleri yanlış veya ana dizinde değil.

Çözüm: chmod ile 600 iznini ayarlayın ve dosya yolunun beklenenle eşleştiğinden emin olun veya netrc-file bayrağıyla yolu belirtin.

Sorun 4: Hata durumunda yığın izinde parola

Neden: Proxy URL'si kimlik bilgileriyle oluşturulmuş ve istemci bunu bir istisnada yazdırıyor.

Çözüm: URL'nin kimlik bilgisi içermemesi için netrc veya ayrı kullanıcı adı/parola alanlarına geçin ve yalnızca hata mesajını yazdırın.

Sorun 5: Rotasyondan sonra eski parola kullanılmaya devam ediyor

Neden: Çalıştırıcıda önbelleğe alınmış netrc veya curlrc dosyası kalmış.

Çözüm: Kimlik bilgisi dosyalarını her derleme sonunda silin ve dosya sisteminin çalıştırmalar arasında temizlendiği geçici çalıştırıcılar kullanın.

Sorun 6: Sır fork pull request'ine sızdı

Neden: Harici PR'lere sırlara erişim veren mod açık.

Çözüm: Böyle bir modu kapatın, sırlarla derlemeleri yalnızca güvenilir dallarda çalıştırın ve harici PR kontrollerini proxy erişimi olmadan yapın.

Sorun 7: Parola git geçmişinde bulundu

Neden: Kimlik bilgileri bir zamanlar bir yapılandırma dosyasına işlenmiş.

Çözüm: Derhal parolayı değiştirin, ardından hassas verileri tüm commit'lerden kaldırarak depo geçmişini yeniden yazın.

Ek olanaklar: Gelişmiş koruma

Temel koruma yapılandırıldığında, onu güçlendirebilirsiniz.

Harici sır yöneticisi

Kimlik bilgilerini CI sisteminde saklamak yerine harici bir sır yöneticisi bağlayın. Pipeline, kimlik bilgilerini yalnızca derleme süresince kısa ömürlü bir belirteçle alır. Böylece sırlar proje ayarlarında sürekli durmaz.

Parola yerine kısa ömürlü belirteçler

Proxeon altyapısı ve erişim şemanız destekliyorsa, sınırlı ömürlü geçici belirteçleri tercih edin. Sızıntı durumunda bile böyle bir belirteç hızla işe yaramaz hale gelir.

Ortamlara göre kimlik bilgilerini ayırma

Test ve üretim derlemeleri için farklı kimlik bilgileri kullanın. Test kimlik bilgilerinin ele geçirilmesi üretim süreçlerini etkilemez.

İpucu: Proxy hesabındaki anormal etkinlikler için bildirim ayarlayın. Ani istek artışı veya beklenmedik kaynaklardan gelen bağlantılar, acil rotasyon gerektiren olası bir sızıntının işaretidir.

Otomatik rotasyon

İleri düzey ekipler rotasyonu programa göre otomatikleştirir: komut dosyası yeni kimlik bilgileri oluşturur, sırrı günceller ve insan müdahalesi olmadan eskilerini iptal eder. Manuel prosedürle başlayın ve süreç oturduğunda otomasyonu ekleyin.

SSS: Sık sorulan sorular

Sadece CI maskelemeye güvenip uğraşmasam olur mu?

Hayır. Maskeleme yalnızca bilinen değerin tam eşleşmelerini yakalar. Base64'teki bir başlığı veya kısmi çıktıyı kaçırabilir. Maskelemeyi, parolayı URL'ye koymamayı ve ayrıntılı logları kapatmayı birleştirin.

Hangisi daha güvenli: ortam değişkeni mi yoksa netrc dosyası mı?

600 iznine sahip netrc dosyası curl için tercih edilir çünkü değer işlem listesine bile girmez. Python ve Node kodu için işlem içinde okunan ortam değişkenleri daha kullanışlıdır. Her iki seçenek de dikkatli kullanıldığında güvenlidir.

Derlemeden sonra kimlik bilgisi dosyasını silmek gerekli mi?

Evet, çalıştırıcı yeniden kullanılıyorsa. Derleme sonrası makinenin yok edildiği geçici çalıştırıcılarda bu daha az kritiktir, ancak her durumda sonunda silmek iyi bir alışkanlıktır.

Proxy parolası özel karakterler içeriyorsa ne yapmalı?

netrc ve ayrı alanlarda özel karakterler genellikle sorun değildir. Sorunlar tam olarak URL'ye eklerken ortaya çıkar; burada @ ve iki nokta üst üste gibi karakterler ayrıştırmayı bozar. Bu, parolayı URL'ye koymamak için bir başka argümandır.

requests kendiliğinden kimlik bilgilerini yazdırır mı?

Varsayılan olarak hayır. Sızıntı, urllib3 DEBUG günlüğü açıldığında veya proxy ayarları nesnesi yazdırıldığında ortaya çıkar. Günlüğü WARNING'de tutun ve ayarların tamamını yazdırmayın.

proxy-user bayrağı kullanılırken parola işlem listesinde görünür mü?

Evet, komut satırındaki bayrak ps çıktısında görünür. Bu nedenle curl için kimlik bilgilerinin bir argümanla iletilmediği netrc veya curlrc'yi tercih edin.

Proxy parolası ne sıklıkta değiştirilmeli?

Planlı rotasyonu düzenli olarak, örneğin üç ayda bir yapmak mantıklıdır ve herhangi bir sızıntı şüphesinde derhal yapılmalıdır. Adım 5'teki rotasyon prosedürü bunu hızlı yapmanıza yardımcı olur.

Kimlik bilgileri depoda şifreli bir dosyada saklanabilir mi?

Teknik olarak evet, ancak süreci karmaşıklaştırır ve şifreleme anahtarının sızma riski yaratır. CI sırları ve harici sır yöneticileri bu sorunu daha basit ve güvenli çözer. Gerekmedikçe kendi depolama yönteminizi icat etmeyin.

Zaten bir sızıntı olduysa ne yapmalı?

Sırayla ilerleyin: derhal proxy parolasını değiştirin, eski kimlik bilgilerini iptal edin, denetim komut dosyasıyla tüm sızıntı noktalarını bulun, gerekirse git geçmişini yeniden yazın ve tekrarlanmaması için nedeni inceleyin.

Bu öneriler Windows çalıştırıcıları için de geçerli mi?

Evet, ilkeler aynıdır. Sözdizimi farklıdır: export yerine kabuğunuz için ortam değişkeni ayarlama yöntemini kullanın ve chmod yerine dosya özelliklerinden izinleri ayarlayın. Saklama mantığı ve log kapatma aynıdır.

Sonuç

Parolayı URL'ye yazma güvensiz alışkanlığından, CI/CD'de proxy kimlik bilgilerinin tam korumasına kadar bir yol kat ettiniz. Yapılanları hatırlayalım.

Beş sızıntı noktasını tanımayı öğrendiniz ve proxy adresindeki paroladan vazgeçtiniz. Kimlik bilgilerini ortam değişkenlerine ve 600 izinli netrc, curlrc ve istemci yapılandırma dosyalarına taşıdınız. GitHub Actions, GitLab CI ve Jenkins'te maskeleme ve kapsam kısıtlamasıyla sırları yapılandırdınız. curl, Python requests ve Node'da yetkilendirme başlığını yazdıran ayrıntılı logları kapattınız. Derlemeleri durdurmadan parola rotasyonunu öğrendiniz ve hazır bir sızıntı denetim komut dosyası oluşturdunuz. Son olarak, yayın öncesi son kontrol listesini geçtiniz.

Şimdi ne yapmalı. Proxeon proxy'si kullanılan tüm pipeline'lar için kontrol listesini zorunlu bir inceleme aşaması olarak uygulayın. Tüm projelere sızıntı kontrolü işini ekleyin. Temel süreç alışkanlık haline geldiğinde, kademeli olarak harici bir sır yöneticisine ve kısa ömürlü belirteçlere geçin.

Nereye gelişmeli. Kuruluş genelinde sır yönetimi uygulamalarını, otomatik rotasyonu ve proxy hesabındaki anormallik izlemeyi inceleyin. Kimlik bilgisi güvenliği tek seferlik bir kurulum değil, sürekli bir mühendislik disiplinidir. Ama artık her şeyi üzerine inşa edebileceğiniz sağlam bir temeliniz var. Başarılı ve güvenli derlemeler.