GitHub Actions’ta SSH Anahtarları Kullanımına Son Verin: Daha Güvenli Alternatifler

GitHub Actions iş akışlarınızda SSH anahtarlarının risklerini ortadan kaldırarak güvenliği artırmanın ve operasyonel karmaşıklığı azaltmanın yollarını keşfedin. Bu makalede, geleneksel SSH kullanımından neden uzaklaşmamız gerektiğini ve yerine OpenID Connect (OIDC) gibi modern, kısa ömürlü kimlik doğrulama yöntemlerini nasıl entegre edebileceğinizi adım adım öğreneceksiniz.

GitHub Actions gibi modern CI/CD platformları, yazılım geliştirme süreçlerimizi otomatikleştirmek için vazgeçilmez araçlar haline geldi. Ancak, bu otomasyon süreçlerinde kullanılan kimlik doğrulama yöntemleri, genel güvenlik duruşumuzu doğrudan etkileyen kritik bir unsurdur. Geleneksel olarak, uzak sunuculara veya bulut kaynaklarına erişim için SSH anahtarları yaygın bir şekilde kullanılmıştır. Bu anahtarlar, GitHub depolarından sunuculara kod dağıtmak, bağımlılıkları indirmek veya uzak komutları çalıştırmak gibi pek çok senaryoda devreye girer. Ancak, SSH anahtarları, özellikle GitHub Actions gibi otomatize edilmiş ortamlarda kullanıldığında, ciddi güvenlik riskleri ve yönetim zorlukları yaratmaktadır.

Öncelikle, SSH anahtarlarının uzun ömürlü yapısı, potansiyel güvenlik açıklarının temelini oluşturur. Bir anahtar bir kez oluşturulduğunda ve bir GitHub Actions iş akışında bir sır (secret) olarak saklandığında, bu anahtarın süresi dolmaz. Eğer bu anahtar bir şekilde ele geçirilirse, saldırganlar bu anahtarı kullanarak süresiz erişim elde edebilirler. Bu durum, özellikle yüksek ayrıcalıklara sahip anahtarlar için felaketle sonuçlanabilecek bir güvenlik ihlaline yol açabilir. Çalınan bir SSH anahtarı, hassas verilere, üretim ortamlarına veya diğer kritik altyapılara yetkisiz erişim sağlayabilir.

İkinci olarak, SSH anahtarlarının yönetimi oldukça zahmetli ve hataya açıktır. Her bir sunucuya veya hizmete özel anahtar çiftleri oluşturmak, bu anahtarları GitHub Secrets gibi güvenli depolama alanlarında saklamak, erişim izinlerini düzenli olarak gözden geçirmek ve anahtarları zaman zaman döndürmek (rotate etmek) karmaşık bir süreçtir. Ölçek büyüdükçe, bu yönetim yükü katlanarak artar. Bir anahtarın yanlışlıkla bir genel depoya (public repository) sızması veya yetkisiz kişilerle paylaşılması riski her zaman mevcuttur. Ayrıca, bir ekip üyesi ayrıldığında veya bir anahtarın artık kullanılmaması gerektiğinde, ilgili anahtarın tüm sistemlerden eksiksiz bir şekilde kaldırıldığından emin olmak zorlayıcı olabilir. Bu tür manuel işlemler, insan hatasına açık kapı bırakır ve güvenlik açıklarının oluşma olasılığını artırır.

Son olarak, geleneksel SSH anahtarları, en az ayrıcalık (least privilege) ilkesini uygulamakta yetersiz kalabilir. Çoğu zaman, bir iş akışının belirli bir görevi yerine getirmesi için gerekenden daha geniş yetkilere sahip bir anahtar kullanılır. Bu da, eğer anahtar ele geçirilirse, saldırganın elde edebileceği zarar potansiyelini artırır. Modern güvenlik yaklaşımları, her zaman yalnızca belirli bir görevi yerine getirmek için gereken minimum yetkilere sahip, kısa ömürlü kimlik bilgileri kullanılmasını savunur. İşte bu noktada, SSH anahtarlarının yerini alabilecek daha güvenli ve yönetilebilir alternatiflere yönelme ihtiyacı doğmaktadır. Bu alternatifler, otomasyon süreçlerimizi daha dayanıklı, denetlenebilir ve siber tehditlere karşı daha dirençli hale getirmemizi sağlar.

Temel Kavramlar: SSH Anahtarları ve Güvenlik Mekanizmaları Nelerdir?

GitHub Actions’ta SSH anahtarlarını neden bırakmamız gerektiğini anlamak için, öncelikle SSH anahtarlarının ne olduğunu ve temel güvenlik mekanizmalarının nasıl işlediğini kavramak önemlidir. Ayrıca, CI/CD ortamlarında kimlik doğrulamanın ne anlama geldiğini ve neden bu kadar kritik olduğunu da irdelemeliyiz. Bu temel kavramlar, daha modern ve güvenli alternatiflere geçişin mantığını anlamanıza yardımcı olacaktır.

SSH Anahtarları (Secure Shell Keys) Nedir?

SSH anahtarları, güvenli ağ iletişimi sağlamak için kullanılan kriptografik anahtar çiftleridir. Bir açık (public) anahtar ve bir özel (private) anahtardan oluşurlar. Açık anahtar, erişim sağlamak istediğiniz uzak sunuculara veya hizmetlere yerleştirilirken, özel anahtar kullanıcının veya otomasyon sisteminin elinde gizli tutulur. Kimlik doğrulama sırasında, özel anahtara sahip olan istemci, açık anahtarla eşleşen bir kriptografik imza oluşturur. Sunucu bu imzayı doğrular ve eşleşme başarılı olursa, istemciye erişim izni verir. Bu mekanizma, parola tabanlı kimlik doğrulamasına kıyasla çok daha güvenli kabul edilir, zira anahtarların kırılması çok daha zordur.

GitHub Actions bağlamında, özel SSH anahtarları genellikle GitHub Secrets adı verilen güvenli depolama alanlarında saklanır. Bir iş akışı çalıştığında, bu anahtar çekilir ve uzak sunucuya SSH bağlantısı kurmak için kullanılır. Örneğin, bir uygulamayı bir AWS EC2 örneğine veya bir DigitalOcean Droplet’e dağıtmak istediğinizde, iş akışınız bu özel anahtarı kullanarak hedef sunucuya kimliğini doğrular ve dağıtım komutlarını çalıştırır.

CI/CD Ortamlarında Kimlik Doğrulama Neden Kritik?

Sürekli Entegrasyon (CI) ve Sürekli Dağıtım (CD) süreçleri, yazılım geliştirme yaşam döngüsünün otomasyon omurgasını oluşturur. Bu süreçler, kodun derlenmesinden test edilmesine, paketlenmesinden dağıtımına kadar birçok adımı kapsar. Bu adımların çoğu, dış kaynaklara erişim gerektirir:

• Bağımlılık yöneticilerinden (npm, Maven, pip) paket çekme.
• Konteyner kayıt defterlerine (Docker Hub, AWS ECR) görüntü gönderme/çekme.
• Bulut depolama alanlarına (AWS S3, Azure Blob Storage) derlenmiş yapıtları kaydetme.
• Veritabanı bağlantısı veya API çağrıları yapma.
• Uzak sunuculara veya Kubernetes kümelerine kod dağıtma.

Bu erişimlerin her biri, kimlik doğrulama gerektirir. Eğer bir CI/CD iş akışı, bu kaynaklara erişmek için kullanılan kimlik bilgilerini güvende tutamazsa, tüm sistemin güvenliği tehlikeye girer. Bir saldırgan, CI/CD sistemini ele geçirerek, hassas kodlara, verilere veya üretim ortamlarına yetkisiz erişim sağlayabilir. Bu nedenle, kimlik doğrulama, CI/CD güvenliğinin temel direklerinden biridir.

SSH Anahtarlarıyla Gelen Güvenlik Riskleri ve Yönetim Zorlukları:

Yukarıda da bahsettiğimiz gibi, SSH anahtarları güçlü bir kimlik doğrulama yöntemi olsa da, CI/CD ortamlarında uzun ömürlü olmaları ve manuel yönetime bağımlı olmaları nedeniyle çeşitli riskleri beraberinde getirir:

1. Sızıntı Riski: Özel anahtarın yanlışlıkla depoya işlenmesi, bir GitHub Secret’ın güvenliğinin aşılması veya yetkisiz erişim sonucu ele geçirilmesi durumunda, bu anahtarın süresiz geçerliliği büyük bir güvenlik açığı oluşturur.
2. Anahtar Rotasyonu Zorluğu: Güvenlik en iyi uygulamaları, kimlik bilgilerinin düzenli olarak döndürülmesini (rotate) gerektirir. Ancak SSH anahtarlarının rotasyonu, birden fazla sunucu ve iş akışı arasında manuel koordinasyon gerektirdiği için genellikle ihmal edilir veya ertelenir.
3. Ayrıcalık Yükseltme: Genellikle, bir SSH anahtarı belirli bir işlem için gerekenden daha fazla ayrıcalığa sahip olabilir. Bu, eğer anahtar ele geçirilirse, saldırganın daha geniş sistemlere erişim sağlamasına olanak tanır.
4. Denetim ve İzlenebilirlik Eksikliği: Kimin ne zaman hangi anahtarı kullandığını takip etmek zor olabilir. Bu da, bir güvenlik ihlali durumunda kök nedeni bulmayı zorlaştırır.

Bu zorluklar göz önüne alındığında, SSH anahtarlarının yerini alacak, otomatikleştirilebilir, kısa ömürlü ve en az ayrıcalık ilkesine uygun çözümlere yönelmek kaçınılmaz hale gelmiştir. Bir sonraki bölümde, bu modern yaklaşımlardan en önemlisi olan OpenID Connect (OIDC) ve kısa ömürlü kimlik bilgilerini detaylandıracağız.

OpenID Connect (OIDC) ve Kısa Ömürlü Kimlik Bilgileri: Geleceğin Güvenlik Standardı

Geleneksel SSH anahtarlarının güvenlik ve yönetim zorluklarını geride bırakmak için OpenID Connect (OIDC) tabanlı kimlik doğrulama ve kısa ömürlü kimlik bilgileri, CI/CD ortamları için ideal bir çözüm sunar. Bu yaklaşım, güvenlik duruşumuzu önemli ölçüde güçlendirirken, operasyonel yükü de azaltır. Peki, OIDC tam olarak nedir ve kısa ömürlü kimlik bilgileri ne anlama gelir?

OpenID Connect (OIDC) Nedir ve Nasıl Çalışır?

OpenID Connect (OIDC), OAuth 2.0 protokolü üzerine inşa edilmiş basit bir kimlik katmanıdır. Temel amacı, istemcilerin bir kimlik sağlayıcı tarafından kimliği doğrulanmış bir kullanıcının (veya bu durumda bir iş akışının) kimlik bilgilerini almasını sağlamaktır. OIDC’nin en önemli çıktısı, JSON Web Token (JWT) formatındaki bir ID Token’dır. Bu token, kimliği doğrulanmış varlık (kullanıcı veya iş akışı) hakkında çeşitli iddialar (claims) içerir, örneğin kimin kimlik doğrulamasını yaptığı, ne zaman yapıldığı gibi bilgiler.

GitHub Actions bağlamında OIDC, iş akışınızın kendisini bir “kimlik” olarak doğrulamasına olanak tanır. İş akışınız çalıştığında, GitHub, otomatik olarak imzalanmış bir JWT oluşturur ve bu tokenı iş akışının kullanımına sunar. Bu JWT, iş akışının çalıştığı depo (repository), dal (branch), iş akışı adı gibi benzersiz tanımlayıcılar içerir. Daha sonra, iş akışı bu JWT’yi bulut sağlayıcınıza (örneğin AWS, Azure, GCP) gönderir. Bulut sağlayıcınız, bu JWT’yi doğrular ve token içindeki iddialara (claims) göre iş akışına geçici, kısa ömürlü kimlik bilgileri (örneğin AWS için IAM rolü kimlik bilgileri, Azure için yönetilen kimlik veya servis prensibi) verir. Bu sayede, iş akışınız doğrudan bulut kaynaklarına, hiçbir uzun ömürlü sır (SSH anahtarı veya API anahtarı) saklamadan erişebilir.

Kısa Ömürlü Kimlik Bilgileri Neden Daha Güvenli?

Kısa ömürlü kimlik bilgileri (ephemeral credentials), adından da anlaşılacağı gibi, belirli bir süre sonra otomatik olarak geçersiz hale gelen geçici kimlik bilgileridir. Bu, OIDC tabanlı kimlik doğrulamanın temel taşıdır ve güvenlik açısından bir dizi önemli avantaj sunar:

1. Sızıntı Riskinin Azalması: Bir saldırgan kısa ömürlü bir kimlik bilgisini ele geçirse bile, bu kimlik bilgileri yalnızca kısa bir süre (genellikle dakikalar veya saatler) için geçerli olacaktır. Süresi dolduğunda, artık kullanılamaz hale gelirler, bu da saldırganın sistem üzerinde kalıcı erişim elde etmesini büyük ölçüde zorlaştırır. Uzun ömürlü SSH anahtarlarının aksine, kalıcı bir tehdit oluşturmazlar.
2. Anahtar Rotasyonu İhtiyacının Ortadan Kalkması: Kısa ömürlü kimlik bilgileri, “kendiliğinden rotasyon” mekanizmasıyla çalışır. Her iş akışı çalıştığında yeni, geçici bir kimlik bilgisi seti alınır ve önceki kimlik bilgileri otomatik olarak süresi dolduğu için geçersiz hale gelir. Bu durum, manuel anahtar rotasyonu ihtiyacını tamamen ortadan kaldırır ve yönetim yükünü sıfıra indirir.
3. En Az Ayrıcalık İlkesinin Uygulanması: OIDC ile, bulut sağlayıcınızda tanımlanan IAM rolleri veya servis prensipleri aracılığıyla, her iş akışına yalnızca görevi için kesinlikle gerekli olan minimum ayrıcalıkları verebilirsiniz. Bu, eğer bir iş akışının kimlik bilgileri ele geçirilse bile, potansiyel zararın kapsamını sınırlar. Örneğin, bir dağıtım iş akışına yalnızca belirli bir S3 kovasına yazma izni verebilirsiniz, tüm hesap üzerinde tam erişim değil.
4. Gelişmiş Denetim ve İzlenebilirlik: OIDC akışı ve kısa ömürlü kimlik bilgileri, bulut sağlayıcınızın denetim günlüklerinde ayrıntılı olarak kaydedilir. Kimin (hangi iş akışının) ne zaman hangi geçici kimlik bilgilerini aldığını ve bu kimlik bilgilerini kullanarak hangi eylemleri gerçekleştirdiğini kolayca takip edebilirsiniz. Bu, güvenlik ihlali durumunda daha hızlı yanıt vermenize ve kök nedeni daha kolay tespit etmenize yardımcı olur.

Kısacası, OIDC ve kısa ömürlü kimlik bilgileri, GitHub Actions ortamında güvenlik stratejisini temelden değiştirir. Uzun ömürlü, manuel yönetilen sırların yerine, otomatik, geçici ve en az ayrıcalıklı erişimi mümkün kılar. Bu da, hem geliştirme verimliliğini artırır hem de siber güvenlik risklerini önemli ölçüde azaltır.

GitHub Actions ve OIDC Entegrasyonu Nasıl Yapılır? (Vaka Analizi: AWS Üzerinden Dağıtım)

Şimdi, öğrendiğimiz teorik bilgileri pratiğe dökelim. GitHub Actions iş akışınızı AWS ile OpenID Connect (OIDC) kullanarak nasıl entegre edeceğinizi adım adım inceleyeceğiz. Bu vaka analizi, SSH anahtarlarından tamamen arınmış, güvenli ve otomatik bir dağıtım akışının nasıl oluşturulacağını gösterecektir.

Adım 1: AWS IAM Identity Provider Oluşturma

İlk olarak, AWS IAM (Identity and Access Management) içinde GitHub Actions’ı bir kimlik sağlayıcı olarak tanıtmanız gerekiyor. Bu, AWS’nin GitHub tarafından yayınlanan JWT’leri güvenmesini sağlayacaktır.

AWS Yönetim Konsolu’nda IAM hizmetine gidin ve sol menüden “Identity Providers” (Kimlik Sağlayıcıları) seçeneğine tıklayın. “Add Provider” (Sağlayıcı Ekle) butonuna basarak yeni bir OpenID Connect sağlayıcı oluşturun.

• Provider Type: OpenID Connect
• Provider URL: https://token.actions.githubusercontent.com
• Audience: sts.amazonaws.com

Bu adımları tamamladığınızda, AWS, GitHub Actions’ın JWT’lerini doğrulayabilecek duruma gelecektir.

Adım 2: AWS IAM Rolü Oluşturma ve Güven Politikası Ayarlama

Sırada, GitHub Actions iş akışınızın üstleneceği bir IAM rolü oluşturmak var. Bu rol, iş akışınızın AWS kaynakları üzerinde hangi eylemleri gerçekleştirebileceğini tanımlayacaktır. Rolü oluştururken, GitHub Actions Identity Provider’ına güvenmesini sağlamalısınız.

IAM konsolunda “Roles” (Roller) bölümüne gidin ve “Create role” (Rol oluştur) butonuna tıklayın. “Custom trust policy” (Özel güven politikası) seçeneğini seçin ve aşağıdaki JSON politikasını yapıştırın:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::YOUR_AWS_ACCOUNT_ID:oidc-provider/token.actions.githubusercontent.com"
      },
      "Resource": "*",
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "token.actions.githubusercontent.com:aud": "sts.amazonaws.com",
          "token.actions.githubusercontent.com:sub": "repo:YOUR_GITHUB_ORG/YOUR_REPO_NAME:ref:refs/heads/main"
        }
      }
    }
  ]
}

Yukarıdaki JSON'da YOUR_AWS_ACCOUNT_ID yerine kendi AWS hesap kimliğinizi, YOUR_GITHUB_ORG/YOUR_REPO_NAME yerine de GitHub kuruluş adınızı ve depo adınızı girmeniz gerekmektedir. ref:refs/heads/main kısmı, bu rolün yalnızca main dalından gelen iş akışları tarafından üstlenilebileceğini belirtir. Daha da güvenli bir yaklaşım için, tam yolu (ref:refs/heads/main) yerine, belirli bir iş akışını (repo:YOUR_GITHUB_ORG/YOUR_REPO_NAME:workflow:your-workflow-name.yml) veya ortamı (repo:YOUR_GITHUB_ORG/YOUR_REPO_NAME:environment:production) hedefleyebilirsiniz. Bu, en az ayrıcalık ilkesini uygulamanın anahtarıdır.

Bu güven politikası, GitHub Actions'tan gelen ve belirli bir depodan/daldan gelen JWT'ye sahip olan bir varlığın bu rolü üstlenmesine izin verir.

Daha sonra, bu role iş akışınızın ihtiyaç duyduğu izinleri (örneğin, S3'e dosya yükleme, EC2 örneklerini yönetme vb.) atayın. Örneğin, S3'e dağıtım yapacaksanız, s3:PutObject ve s3:ListBucket gibi izinlere sahip bir politika eklemeniz gerekebilir.

Adım 3: GitHub Actions İş Akışını Yapılandırma

Artık AWS tarafı hazır olduğuna göre, GitHub Actions iş akışınızı OIDC kullanacak şekilde güncelleyebilirsiniz. İş akışı dosyanızda (.github/workflows/main.yml gibi) aşağıdaki değişiklikleri yapmanız gerekecek:

name: AWS OIDC Dağıtım Akışı

on:
  push:
    branches:
      - main

permissions:
  id-token: write # Bu, JWT oluşturmak için gereklidir
  contents: read # Kodu okumak için gereklidir

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Kodu Çek
        uses: actions/checkout@v3

      - name: AWS Kimlik Bilgilerini Yapılandır
        uses: aws-actions/configure-aws-credentials@v2
        with:
          role-to-assume: arn:aws:iam::YOUR_AWS_ACCOUNT_ID:role/YOUR_IAM_ROLE_NAME
          aws-region: eu-central-1 # Kendi AWS bölgenizi girin

      - name: S3'e Dağıtım Yap (Örnek)
        run: |
          aws s3 sync . s3://your-s3-bucket-name --delete
        # Örneğin, bir EC2'ye SSH bağlantısı yapmak yerine, AWS CLI/SDK kullanarak dağıtım yapın.
        # ssh anahtarı gerektiren adımları doğrudan AWS CLI/SDK ile değiştirin.

Bu YAML dosyasında dikkat edilmesi gereken önemli noktalar:

• permissions: id-token: write: Bu izin, GitHub Actions'ın iş akışınız için bir OIDC JWT oluşturmasına olanak tanır. Bu olmadan OIDC çalışmaz.
• aws-actions/configure-aws-credentials@v2 eylemi: Bu eylem, GitHub tarafından oluşturulan JWT'yi alır, AWS STS'ye (Security Token Service) gönderir ve belirttiğiniz IAM rolünü üstlenerek geçici AWS kimlik bilgilerini iş akışı ortamına enjekte eder. Bu, iş akışınızın sonraki adımlarında aws cli veya AWS SDK'ları kullanabilmesini sağlar.
• role-to-assume: Burada, Adım 2'de oluşturduğunuz IAM rolünün ARN'ini (Amazon Resource Name) belirtmeniz gerekmektedir.
• aws-region: Dağıtım yapacağınız AWS bölgesini belirtin.

Bu yapılandırma ile iş akışınız, uzun ömürlü SSH anahtarları veya API anahtarları saklamadan güvenli bir şekilde AWS kaynaklarına erişebilir. AWS CLI komutlarını doğrudan çalıştırabilir veya SDK kullanan uygulamalarınızı dağıtabilirsiniz.

SSH Anahtarı Gerektiren İşlemler Nasıl Değiştirilir?

Daha önce SSH anahtarı kullanarak yaptığınız işlemleri (örneğin, scp ile dosya kopyalama, ssh ile komut çalıştırma) OIDC ve AWS CLI/SDK ile değiştirmelisiniz. İşte birkaç örnek:

• Dosya Kopyalama (SCP yerine S3):

  Eğer dosya kopyalama işlemi bir sunucuya uygulama dosyaları dağıtmak içinse, bunları bir S3 kovasına yükleyip sunucuların S3'ten çekmesini sağlayabilirsiniz. Veya doğrudan dağıtım araçları (CodeDeploy, ECS, EKS) kullanın.

  
  aws s3 cp ./build/my-app.zip s3://your-app-distribution-bucket/latest.zip
              

• Uzak Komut Çalıştırma (SSH yerine AWS Systems Manager Run Command):

  EC2 örnekleri üzerinde komut çalıştırmanız gerekiyorsa, bunun için AWS Systems Manager (SSM) Run Command kullanabilirsiniz. Bu, SSH portunu açma ihtiyacını ortadan kaldırır.

  
        - name: EC2 Üzerinde Komut Çalıştır
          run: |
            aws ssm send-command \
              --instance-ids "i-0abcdef1234567890" \
              --document-name "AWS-RunShellScript" \
              --parameters 'commands=["sudo systemctl restart my-app.service"]' \
              --comment "Uygulamayı yeniden başlat"
              

Bu yöntemlerle, SSH anahtarlarının güvenlik risklerinden kaçınarak, bulut sağlayıcınızın kendi güvenli kimlik doğrulama mekanizmalarını kullanmış olursunuz. Bu yaklaşım, sadece güvenlik değil, aynı zamanda operasyonel esneklik ve denetlenebilirlik açısından da önemli avantajlar sunar.

Diğer Güvenli Alternatifler ve En İyi Uygulamalar Nelerdir?

GitHub Actions iş akışlarınızda SSH anahtarlarından uzaklaşırken, OIDC en güçlü ve tercih edilen yol olsa da, başka güvenli alternatifler ve genel geçer en iyi uygulamalar da bulunmaktadır. Bu seçenekler, OIDC'nin doğrudan uygulanamadığı veya belirli özel durumlar için uygun olabilecek senaryolarda devreye girebilir. Amacımız, her zaman en az ayrıcalık (least privilege) ilkesine sadık kalmak ve sır yönetimi yükünü en aza indirmektir.

GitHub Secrets (Yine de Dikkatli Kullanılmalı)

GitHub Secrets, hassas bilgileri (API anahtarları, veritabanı şifreleri, özel tokenlar vb.) iş akışlarınızda güvenli bir şekilde saklamak için GitHub tarafından sağlanan yerleşik bir mekanizmadır. Anahtarlar şifrelenir ve yalnızca iş akışınızın çalıştığı ortamda geçici olarak erişilebilir hale gelir. SSH özel anahtarlarını saklamak için de kullanılabilirler, ancak yukarıda bahsedilen uzun ömürlülük riskleri devam eder.

Ne Zaman Kullanılır?

• OIDC entegrasyonu henüz mümkün olmayan eski sistemlerle veya üçüncü taraf hizmetlerle etkileşim kurmanız gerektiğinde.
• Kısa ömürlü kimlik bilgileri sunmayan bir API'ye erişim için kısa süreli bir token saklamanız gerektiğinde.
• Küçük ölçekli projelerde veya SSH anahtarlarının kalıcılığının kritik bir risk oluşturmadığı geçici senaryolarda.

En İyi Uygulamalar:

• Rotasyon: GitHub Secrets'ta sakladığınız sırları düzenli olarak döndürün. Otomatik rotasyon mekanizmaları kullanabiliyorsanız, bunlar idealdir.
• En Az Ayrıcalık: Sakladığınız sırların sadece ihtiyacı olan minimum ayrıcalıklara sahip olduğundan emin olun.
• Erişim Kısıtlaması: Sırların belirli ortamlarla (örneğin, production ortamına ait sırlar yalnızca production dağıtımı için kullanılabilir) veya belirli dallarla ilişkilendirilmesini sağlayın. GitHub'ın ortam koruma kuralları bu konuda yardımcı olabilir.
• Denetim: Secret erişimlerini ve kullanımlarını denetleyin.

Unutmayın, GitHub Secrets, SSH anahtarlarını saklamak için hala bir seçenektir, ancak bu, anahtarların uzun ömürlülüğünden kaynaklanan temel güvenlik sorununu çözmez. OIDC'nin mümkün olduğu her yerde OIDC'yi tercih etmek en güvenli yaklaşımdır.

Bulut Sağlayıcıların Yönetilen Kimlik Hizmetleri (Managed Identity)

Eğer dağıtım hedefiniz bulut üzerinde çalışan bir sanal makine (VM) veya konteyner ise, bulut sağlayıcılarının yönetilen kimlik (managed identity) hizmetleri güçlü bir alternatif sunabilir. Örneğin:

• AWS IAM Rolleri (EC2, ECS, EKS için): EC2 örneklerine veya ECS/EKS servislerine doğrudan IAM rolleri atayarak, bu kaynakların diğer AWS hizmetlerine (S3, DynamoDB vb.) güvenli bir şekilde erişmesini sağlayabilirsiniz. İş akışınız, bu VM'lere doğrudan SSH yapmak yerine, AWS API'leri veya CLI kullanarak dağıtım yapabilir ve VM'ler kendi atanmış rolleriyle kimlik doğrulaması yapabilir.
• Azure Yönetilen Kimlikler (Managed Identities): Azure VM'lerine veya App Services'larına atanan yönetilen kimlikler, bu kaynakların Azure AD üzerinden kimlik doğrulaması yapmasını ve diğer Azure hizmetlerine erişmesini sağlar. GitHub Actions, bu VM'lere uzaktan komut çalıştırmak için Azure CLI'yı kullanabilir ve VM, kendi kimliğiyle Azure kaynaklarına erişebilir.
• Google Cloud Service Accounts (Hizmet Hesapları): GCP'de bir sanal makine veya GKE podu oluştururken, ona belirli bir hizmet hesabı atayabilirsiniz. Bu hizmet hesabı, VM'nin GCP kaynaklarına erişim ayrıcalıklarını tanımlar.

Bu yaklaşım, dağıtım hedefine (VM veya konteyner) doğrudan SSH anahtarları yerleştirmekten çok daha güvenlidir, çünkü kimlik bilgileri bulut sağlayıcısı tarafından yönetilir ve genellikle otomatik olarak döndürülür.

En İyi Uygulamalar ve Güvenlik İpuçları

1. En Az Ayrıcalık İlkesi: Bu, her güvenlik stratejisinin temelidir. Herhangi bir kimlik bilgisine, role veya hizmet hesabına, görevi için kesinlikle gerekli olan minimum izinleri verin. Bir dağıtım iş akışı yalnızca belirli bir kovaya yazmalı, tüm S3'e değil.
2. Kısa Ömürlü Kimlik Bilgilerini Tercih Edin: Mümkün olan her yerde OIDC gibi kısa ömürlü kimlik bilgileri sağlayan yöntemleri kullanın. Bu, güvenlik ihlallerinin etkisini önemli ölçüde azaltır.
3. Sır Yönetimini Otomatikleştirin: Sırların manuel olarak yönetilmesi hataya açıktır. OIDC'nin doğası gereği otomatik olan rotasyonu haricinde, eğer GitHub Secrets gibi uzun ömürlü sırlar kullanmak zorundaysanız, bunların rotasyonunu otomatikleştirecek mekanizmalar (örneğin, bir periyodik iş) kurmayı düşünün.
4. Ortam Ayırma: Geliştirme, test ve üretim ortamları için farklı kimlik bilgileri ve izin setleri kullanın. Üretim ortamına erişim, diğerlerinden daha kısıtlı ve denetimli olmalıdır.
5. Denetim ve İzleme: Tüm kimlik doğrulama ve yetkilendirme eylemlerini kaydedin ve izleyin. Anormal erişim denemelerini veya kullanım kalıplarını tespit etmek için izleme ve uyarı sistemleri kurun.
6. İş Akışı Gözden Geçirmeleri: İş akışı dosyalarınızı (YAML) ve kullandıkları kimlik bilgilerini düzenli olarak güvenlik açısından gözden geçirin. Değişiklikler için kod incelemesi süreçleri uygulayın.

Bu alternatifler ve en iyi uygulamalar, GitHub Actions'ta daha güvenli ve sürdürülebilir bir CI/CD ortamı oluşturmanıza yardımcı olacaktır. Amacımız, hassas kimlik bilgilerini kod tabanımızdan veya statik depolama alanlarından tamamen çıkarmak ve dinamik, kısa ömürlü, bulut sağlayıcı tabanlı kimlik doğrulama mekanizmalarına geçmektir.

İleri Düzey İpuçları ve Optimizasyonlar: OIDC Kullanımını Geliştirmek

GitHub Actions ve OIDC entegrasyonunun temellerini öğrendiğimize göre, şimdi bu güçlü güvenlik mekanizmasını daha da geliştirecek ve optimize edecek ileri düzey ipuçlarına göz atalım. Bu ipuçları, daha karmaşık dağıtım senaryolarında güvenliği artırmanıza, yönetimi kolaylaştırmanıza ve iş akışlarınızın daha esnek olmasını sağlamanıza yardımcı olacaktır.

Daha Hassas Koşullar ile IAM Politikalarını Güçlendirme

Adım 2'de oluşturduğumuz AWS IAM güven politikası, GitHub deponuzdan ve ana dalınızdan gelen istekleri hedefliyordu. Ancak, OIDC JWT'sinin sağladığı iddialar (claims) çok daha zengindir ve bunları kullanarak politikalarınızı daha da hassaslaştırabilirsiniz. Bu, en az ayrıcalık ilkesini daha derinlemesine uygulamanıza olanak tanır.

İşte kullanabileceğiniz bazı ek iddialar (claims) ve örnek koşullar:

• sub (Subject): JWT'nin kime ait olduğunu belirtir. Genellikle repo:/:ref: veya repo:/:workflow: formatındadır.
• environment: Eğer GitHub ortamları kullanıyorsanız, environment: ile belirli bir ortama özgü erişim sağlayabilirsiniz.
• actor: İş akışını başlatan GitHub kullanıcısının kullanıcı adı.
• event_name: İş akışını tetikleyen olayın adı (örneğin, push, pull_request).
• ref_type: Referans tipi (örneğin, branch, tag).

Örnek Gelişmiş IAM Güven Politikası:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::YOUR_AWS_ACCOUNT_ID:oidc-provider/token.actions.githubusercontent.com"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "token.actions.githubusercontent.com:aud": "sts.amazonaws.com"
        },
        "StringLike": {
          "token.actions.githubusercontent.com:sub": "repo:my-org/my-app:*",
          "token.actions.githubusercontent.com:ref": "refs/heads/main"
        },
        "ForAllValues:StringLike": {
          "token.actions.githubusercontent.com:environment": "production"
        }
      }
    }
  ]
}

Bu politika, my-org/my-app deposundaki herhangi bir iş akışının, main dalından çalıştırıldığında ve production ortamını hedeflediğinde rolü üstlenmesine izin verir. Bu seviyedeki detay, güvenlik riskini minimuma indirmek için çok önemlidir.

Çoklu Bulut ve Hibrit Ortamlarda OIDC Kullanımı

Tek bir bulut sağlayıcısına bağımlı olmayan veya hibrit bulut ortamlarında çalışan kuruluşlar için OIDC, esnek bir kimlik doğrulama köprüsü görevi görebilir.

• Azure Workload Identity Federation: Azure DevOps'taki Servis Bağlantılarına benzer şekilde, GitHub Actions ile Azure AD arasında Workload Identity Federation kurarak Azure kaynaklarına (Storage Account, Key Vault, AKS vb.) doğrudan ve sır olmadan erişim sağlayabilirsiniz. AWS örneğinde olduğu gibi, bir Azure Service Principal'ına GitHub JWT'si üzerinden kimlik doğrulaması yapma izni verilir.
• Google Cloud Workload Identity Federation: GCP de benzer bir mekanizma sunar. GitHub Actions'ın oluşturduğu JWT'yi kullanarak GCP hizmet hesaplarına erişim federasyonu kurabilirsiniz. Bu sayede, GCP kaynaklarına erişmek için uzun ömürlü hizmet hesabı anahtarlarını saklama ihtiyacını ortadan kaldırırsınız.

Bu yaklaşımlar, farklı bulut platformları arasında tutarlı ve güvenli bir kimlik doğrulama mekanizması sağlamanıza yardımcı olur.

CI/CD Ortam Güvenliği için Ek İpuçları

1. GitHub Ortamlarını Kullanma: GitHub Environments (Ortamlar) özelliğini kullanarak dağıtım süreçlerinizi daha da güvence altına alabilirsiniz. Ortamlar, sırlarınızı, değişkenlerinizi ve dağıtım kurallarınızı (örneğin, manuel onay gereksinimi, belirli bir dalın dağıtım yapabilmesi) belirli bir dağıtım ortamıyla ilişkilendirmenize olanak tanır. OIDC politikalarınızda ortam isimlerini koşul olarak kullanarak ek bir güvenlik katmanı ekleyebilirsiniz.
2. Güvenlik Taramaları ve Kod Analizi: GitHub Actions iş akışlarınızda ve dağıttığınız kodda güvenlik açıklarını bulmak için statik kod analizi (SAST), dinamik kod analizi (DAST) ve bağımlılık tarayıcıları (dependency scanners) kullanın. Bu araçlar, dağıtımın erken aşamalarında zafiyetleri tespit etmenize yardımcı olur.
3. Least Privilege Prensibini Kodu Yazarken Uygulayın: Sadece IAM politikalarıyla değil, aynı zamanda uygulamanızın kendisinin de minimum ayrıcalıkla çalışmasını sağlayın. Örneğin, bir veritabanı kullanıcısı yalnızca belirli tablolara erişebilmeli veya bir mikroservis yalnızca kendi verilerine yazabilmelidir.
4. Güvenlik Günlüklerini İzleme: GitHub Actions iş akışı günlüklerini, bulut sağlayıcınızın denetim günlüklerini (örneğin AWS CloudTrail, Azure Monitor, GCP Cloud Logging) düzenli olarak izleyin. Anormal davranışları veya yetkisiz erişim denemelerini tespit etmek için merkezi bir günlük yönetimi ve güvenlik bilgi ve olay yönetimi (SIEM) çözümü kullanmayı düşünün.
5. Mobil Uyumlu HTML ve Erişim: Makalenin çıktısını alırken HTML'in mobil cihazlarda da düzgün görüntülendiğinden emin olmak önemlidir. CSS media query'ler kullanarak sayfa düzenini ve font boyutlarını farklı ekran boyutlarına göre optimize etmek, kullanıcı deneyimini artıracaktır. (Not: Bu makale sadece HTML içeriği ürettiği için doğrudan CSS media query kodları içeremez, ancak bu bir web geliştirme ipucudur.)

Bu ileri düzey ipuçları ve optimizasyonlar, OIDC'nin sunduğu potansiyeli tam olarak kullanmanıza ve GitHub Actions tabanlı CI/CD süreçlerinizde maksimum güvenlik ve verimlilik elde etmenize yardımcı olacaktır. SSH anahtarlarından vazgeçmek, sadece bir başlangıç noktasıdır; gerçek güvenlik, sürekli iyileştirme ve en iyi uygulamaların titizlikle uygulanmasıyla sağlanır.

Sonuç: Geleceğin CI/CD Güvenliği OIDC ile Şekilleniyor

Bu makalede, GitHub Actions iş akışlarınızda geleneksel SSH anahtarlarını kullanmanın neden modası geçmiş ve riskli bir yaklaşım olduğunu derinlemesine inceledik. Uzun ömürlü kimlik bilgileri, yönetim yükü ve en az ayrıcalık ilkesini uygulamanın zorlukları gibi faktörler, bizi daha modern ve güvenli alternatiflere yönelmek zorunda bırakıyor. İşte bu noktada, OpenID Connect (OIDC) ve kısa ömürlü kimlik bilgileri devreye girerek, CI/CD güvenliğinde yeni bir standart belirliyor.

OIDC'nin sağladığı, anahtarsız ve otomatik olarak döndürülen geçici kimlik bilgileri, sızıntı riskini önemli ölçüde azaltırken, yönetim yükünü ortadan kaldırıyor ve en az ayrıcalık ilkesini daha kolay uygulamanıza olanak tanıyor. AWS örneği üzerinden adım adım gösterdiğimiz entegrasyon süreci, GitHub Actions'ın nasıl güvenli bir şekilde bulut kaynaklarına erişebileceğini somutlaştırdı. Bu entegrasyonla birlikte, SSH anahtarı gerektiren eski alışkanlıklarımızı, bulut sağlayıcımızın kendi API'leri ve hizmetleri (S3, SSM Run Command gibi) üzerinden güvenli ve denetlenebilir eylemlerle değiştirebileceğimizi gördük. Ayrıca, GitHub Secrets gibi diğer alternatifleri ve bu alternatiflerin kullanımındaki en iyi uygulamaları da ele aldık.

İleri düzey ipuçları ve optimizasyonlar bölümünde ise, IAM politikalarını OIDC JWT iddialarını kullanarak daha da hassaslaştırmanın yollarını, çoklu bulut senaryolarında OIDC'nin esnekliğini ve CI/CD ortam güvenliğini artırmak için diğer genel en iyi uygulamaları tartıştık. Unutulmamalıdır ki, güvenli bir CI/CD ortamı inşa etmek sürekli bir çaba gerektirir. Sadece doğru araçları seçmekle kalmamalı, aynı zamanda bu araçları en iyi güvenlik uygulamalarına uygun şekilde yapılandırmalı ve düzenli olarak gözden geçirmeliyiz.

Özetle, GitHub Actions'ta SSH anahtarları dönemini geride bırakmanın zamanı gelmiştir. OIDC gibi modern, federasyon tabanlı kimlik doğrulama mekanizmalarını benimsemek, geliştirme süreçlerinizi hızlandırırken aynı zamanda siber saldırılara karşı çok daha dirençli bir altyapı oluşturmanızı sağlayacaktır. Geleceğin CI/CD güvenliği, kısa ömürlü, otomatik ve minimum ayrıcalıklı kimlik bilgileri üzerine inşa edilmektedir ve bu yolda OIDC, en güçlü müttefiklerimizden biridir.

Sıkça Sorulan Sorular

OIDC sadece AWS ile mi çalışır?

Hayır, OIDC evrensel bir kimlik doğrulama standardıdır ve GitHub Actions, AWS'in yanı sıra Azure (Workload Identity Federation) ve Google Cloud (Workload Identity Federation) gibi diğer büyük bulut sağlayıcılarıyla da OIDC tabanlı entegrasyonları destekler. Temel prensip aynıdır: GitHub bir JWT verir, bulut sağlayıcısı bunu doğrular ve geçici kimlik bilgileri sağlar.

Mevcut SSH anahtarlarımı OIDC'ye nasıl taşırım?

Taşıma süreci adım adım yapılmalıdır. İlk olarak, mevcut iş akışınızda kullandığınız SSH anahtarının yerine OIDC tabanlı bir rol veya kimlik atayarak aynı erişimi sağlayacak bulut sağlayıcısı IAM politikasını ve rolünü oluşturmalısınız. Daha sonra, iş akışı dosyanızı güncelleyerek configure-aws-credentials (veya eşdeğeri) gibi eylemleri kullanıp OIDC ile kimlik doğrulamayı başlatırsınız. En son adımda, SSH anahtarını tamamen devre dışı bırakıp GitHub Secrets'tan kaldırırsınız.

OIDC kullanırken GitHub Secrets'ı yine de kullanabilir miyim?

Evet, OIDC ile bulut kimlik doğrulaması yaparken bile GitHub Secrets'ı kullanmaya devam edebilirsiniz. OIDC, bulut kaynaklarına erişim için tercih edilen yol olsa da, bazı üçüncü taraf hizmetler veya legacy sistemler OIDC desteği sunmayabilir. Bu tür durumlarda, API anahtarlarını veya tokenları GitHub Secrets'ta güvenli bir şekilde saklayarak kullanmaya devam edebilirsiniz. Ancak, bu sırların rotasyonunu ve en az ayrıcalık ilkesini uygulamayı unutmayın.

OIDC'nin performansa etkisi var mıdır?

OIDC'nin iş akışlarınızın performansı üzerinde gözle görülür bir olumsuz etkisi genellikle yoktur. JWT'nin oluşturulması ve doğrulanması, milisaniyeler içinde gerçekleşen hızlı kriptografik işlemlerdir. Geçici kimlik bilgilerinin alınması da genellikle hızlıdır. Aksine, SSH bağlantılarını yönetme ve anahtar doğrulama sürecinden kaynaklanan bazı gecikmeleri ortadan kaldırarak performansa olumlu yönde bile etki edebilir.

OIDC'yi kullanırken denetlenebilirlik nasıl sağlanır?

OIDC ile denetlenebilirlik, SSH anahtarlarına kıyasla çok daha iyidir. GitHub Actions, JWT'lerin oluşturulduğunu ve kullanıldığını iş akışı günlüklerinde kaydeder. Bulut sağlayıcınız (örneğin AWS CloudTrail), iş akışının üstlendiği rolü, aldığı geçici kimlik bilgilerini ve bu kimlik bilgileriyle yaptığı tüm API çağrılarını detaylı olarak loglar. Bu, herhangi bir güvenlik ihlali durumunda kimin, ne zaman ve hangi eylemi gerçekleştirdiğini takip etmeyi çok daha kolay hale getirir.