OCI Workload Identity Federation: GitHub, Kubernetes ve AI İçin Kalıcı Kimlik Bilgisi Olmadan Güvenli Erişim

OCI Workload Identity Federation: GitHub, Kubernetes ve AI İçin Kalıcı Kimlik Bilgisi Olmadan Güvenli Erişim

Modern bulut tabanlı uygulamalar ve otomasyon süreçleri, sürekli olarak farklı hizmetlere ve kaynaklara erişim ihtiyacı duyar. Bu erişimi sağlamanın geleneksel yolu, uzun ömürlü API anahtarları, hizmet hesapları veya statik kimlik bilgileri kullanmaktı. Ancak bu yöntemler, güvenlik açıkları, yönetim zorlukları ve uyumluluk sorunları gibi ciddi riskleri beraberinde getirir. Peki, GitHub Actions, Kubernetes podları veya yapay zeka ajanları gibi iş yüklerinin, kalıcı kimlik bilgileri olmaksızın OCI (Oracle Cloud Infrastructure) kaynaklarına güvenli bir şekilde erişmesini nasıl sağlayabiliriz? İşte tam bu noktada OCI Workload Identity Federation (İş Yükü Kimlik Federasyonu) devreye giriyor ve bu makale, bu devrim niteliğindeki çözümü derinlemesine inceleyerek, modern bulut güvenliği paradigmalarını nasıl yeniden şekillendirdiğini anlatacak.

Kalıcı Kimlik Bilgisi Olmadan Erişim Neden Bu Kadar Önemli?

Geleneksel güvenlik yaklaşımları, genellikle statik kimlik bilgilerinin (API anahtarları, şifreler) oluşturulması, dağıtılması ve yönetilmesi üzerine kuruludur. Ancak bu yaklaşım, özellikle otomasyonun ve dinamik iş yüklerinin yaygınlaştığı günümüz DevOps ve bulut ortamlarında bir dizi önemli zorluk yaratır. İlk olarak, bu tür kimlik bilgileri sızdırıldığında veya kötüye kullanıldığında, ciddi güvenlik ihlallerine yol açabilir. Bir anahtarın süresi dolana veya manuel olarak iptal edilene kadar sınırsız erişim sağlaması, risk faktörünü artırır. İkinci olarak, bu kimlik bilgilerinin güvenli bir şekilde depolanması, döndürülmesi ve yaşam döngüsünün yönetilmesi karmaşık ve hataya açık bir süreçtir. Geliştiricilerin ve operasyon ekiplerinin otonom sistemler için sürekli olarak anahtar yönetimiyle uğraşması, verimliliği düşürür ve insan hatası riskini artırır. Üçüncü olarak, uyumluluk standartları (örneğin SOC 2, HIPAA, GDPR), kimlik bilgilerinin güvenli bir şekilde yönetilmesini ve erişimlerin en az ayrıcalık ilkesine (least privilege) göre verilmesini gerektirir. Statik anahtarların bu gereksinimleri karşılaması genellikle zordur.

İşte tam da bu nedenlerle, kalıcı kimlik bilgisi olmadan erişim (credential-less access) kavramı büyük önem kazanmıştır. Bu yaklaşım, iş yüklerinin OCI gibi bulut sağlayıcılarına doğrudan, kısa ömürlü ve otomatik olarak verilen token’lar (jetonlar) aracılığıyla kimlik doğrulaması yapmasına olanak tanır. Bu token’lar, belirli bir süre sonra geçerliliğini yitirir ve yeniden oluşturulması gerekir, bu da bir güvenlik ihlali durumunda potansiyel zararı en aza indirir. Ayrıca, kimlik bilgisi yönetimi yükünü ortadan kaldırarak operasyonel verimliliği artırır ve güvenlik duruşunu önemli ölçüde güçlendirir. Bu sayede ekipler, altyapı güvenliğine daha az, iş değeri yaratmaya daha fazla odaklanabilir. OCI Workload Identity Federation, bu vizyonu gerçeğe dönüştüren güçlü bir mekanizmadır.

OCI Workload Identity Federation Nedir ve Nasıl Çalışır?

OCI Workload Identity Federation (İş Yükü Kimlik Federasyonu), dış bir kimlik sağlayıcısı (Identity Provider – IdP) ile OCI IAM (Identity and Access Management) arasında bir güven ilişkisi kurarak, iş yüklerinin OCI kaynaklarına kalıcı kimlik bilgileri olmadan erişmesini sağlayan bir güvenlik özelliğidir. Bu mekanizma, OIDC (OpenID Connect) protokolünü temel alır ve iş yüklerinin kendilerini doğrulamak için kısa ömürlü, kriptografik olarak imzalanmış jetonlar (token) kullanmasına izin verir.

Temel olarak, federasyon süreci şu adımları içerir:

1. Harici Kimlik Sağlayıcısı (External Identity Provider): GitHub Actions, Kubernetes Service Account’lar veya diğer OIDC uyumlu sağlayıcılar, iş yükünün kimliğini doğrular ve bu doğrulamanın bir kanıtı olarak bir OIDC jetonu oluşturur. Bu jeton, iş yükünün kimliği ve diğer ilgili nitelikler (örneğin, GitHub deposu adı, Kubernetes ad alanı) hakkında bilgiler içerir.
2. Güven Politikası (Trust Policy): OCI IAM’de, belirli bir harici kimlik sağlayıcısına güvenen ve hangi koşullar altında OCI kaynaklarına erişim izni verileceğini tanımlayan bir “Kimlik Sağlayıcı” nesnesi oluşturulur. Bu nesneye ek olarak, bir “Güven Politikası” (Trust Policy) tanımlanır. Bu politika, harici IdP’den gelen OIDC jetonunun hangi niteliklerini (örneğin, “repo:my-org/my-repo:ref:refs/heads/main” gibi GitHub Actions bağlamı) kontrol edeceğini ve bu niteliklere dayanarak OCI’da hangi “iş yükü kimliğinin” (workload identity) oluşturulacağını belirtir.
3. Jeton Değişimi (Token Exchange): İş yükü, harici IdP’den aldığı OIDC jetonunu OCI IAM’e sunar. OCI IAM, bu jetonu Güven Politikası’nda tanımlanan kurallara göre doğrular ve eğer jeton geçerliyse, iş yüküne OCI kaynaklarına erişim için kullanabileceği kısa ömürlü bir OCI oturum jetonu (session token) verir.
4. Kaynak Erişimi (Resource Access): İş yükü, aldığı OCI oturum jetonunu kullanarak OCI CLI, SDK’lar veya API’ler aracılığıyla OCI kaynaklarına (örneğin, Object Storage, Autonomous Database, Compute) erişim sağlar. Bu jetonun ömrü kısadır (genellikle birkaç dakika ila bir saat) ve süresi dolduğunda otomatik olarak yenilenmesi gerekir.

Bu mekanizma sayesinde, hassas API anahtarlarının veya hizmet hesabı kimlik bilgilerinin hiçbir zaman iş yükü ortamına dağıtılmasına gerek kalmaz. Güven, tamamen kriptografik olarak imzalanmış jetonlar ve OCI IAM’deki merkezi politikalar aracılığıyla yönetilir. Bu, güvenlik duruşunu önemli ölçüde güçlendirirken, kimlik bilgisi yönetim yükünü de ortadan kaldırır. İş yükleri, yalnızca ihtiyaç duydukları anda ve yalnızca ihtiyaç duydukları kaynaklara, geçici yetkilendirmelerle erişebilirler. Bu sayede, “en az ayrıcalık” ilkesi (principle of least privilege) en etkili şekilde uygulanmış olur.

GitHub Actions ile OCI Kaynaklarına Güvenli Erişim Nasıl Sağlanır?

GitHub Actions, modern CI/CD (Sürekli Entegrasyon/Sürekli Teslimat) süreçlerinin temel taşlarından biridir. Genellikle kod dağıtımı, altyapı provizyonu veya bulut hizmetleriyle etkileşim gibi görevleri otomatikleştirmek için kullanılır. Bu tür otomasyonlarda, GitHub Actions iş akışlarının OCI kaynaklarına güvenli bir şekilde erişmesi kritik öneme sahiptir. Geleneksel olarak, bu erişim için OCI kullanıcı anahtarları veya API anahtarları GitHub Actions sırları (secrets) olarak saklanırdı. Ancak bu durum, sızdırılma riski, anahtar döndürme zorlukları ve genel güvenlik endişeleri yaratır. OCI Workload Identity Federation, bu soruna zarif bir çözüm sunar.

Vaka Analizi: GitHub Actions ile OCI Object Storage’a Dosya Yükleme

Bir yazılım ekibi, yeni bir uygulama sürümünü derledikten sonra, derlenmiş dosyaları OCI Object Storage’daki bir depoya (bucket) otomatik olarak yüklemek istiyor. Bu işlem, GitHub Actions iş akışı tarafından gerçekleştirilecek. Ekip, kalıcı OCI kimlik bilgileri kullanmak yerine, Workload Identity Federation’ı kullanarak güvenliği artırmayı hedefliyor.

Adım 1: OCI IAM’de Bir Kimlik Sağlayıcı Oluşturma

İlk olarak, OCI konsolunda veya OCI CLI kullanarak GitHub Actions için bir OIDC Kimlik Sağlayıcı oluşturmamız gerekiyor. Bu sağlayıcı, GitHub’ın OIDC jetonlarını doğrulayacak ve ona güveneceğimizi belirtecek.

oci iam identity-provider create --protocol "OIDC" \
--name "GitHubActionsIdP" \
--description "GitHub Actions OIDC Identity Provider" \
--metadata-url "https://token.actions.githubusercontent.com/.well-known/openid-configuration" \
--tenant-id "ocid1.tenancy.oc1..aaaaaaaaxxxxxx"
  

Bu komut, GitHub Actions’ın OIDC yapılandırma URL’sini kullanarak bir IdP oluşturur. tenant-id kısmını kendi OCI kiracı OCID’nizle değiştirmeyi unutmayın.

Adım 2: OCI Politikası Tanımlama ve Güven İlişkisi Kurma

Şimdi, GitHub Actions iş akışımızın OCI’da hangi ayrıcalıklara sahip olacağını belirten bir OCI politikası oluşturmalıyız. Bu politika, GitHub’dan gelen OIDC jetonunun belirli niteliklerine dayanarak bir güven ilişkisi kuracak. Örneğin, yalnızca belirli bir depodan ve belirli bir daldan gelen iş akışlarının erişmesine izin verebiliriz.

# Bir dinamik grup oluşturulur, ancak federasyon için doğrudan bir dinamik grup oluşturmayız.
# Bunun yerine, bir ilke ile doğrudan IdP'den gelen kimlikleri yetkilendiririz.
# Aşağıdaki politika, "GitHubActionsIdP" sağlayıcısından gelen ve belirli bir repo'dan
# (my-org/my-repo) ve daldan (main) olan iş yüklerine Object Storage'a erişim izni verir.

# Bu politika, 'ocid1.tenancy.oc1..aaaaaaaaxxxxxx' kiracısında yer alan 'GitHubActionsIdP'
# kimlik sağlayıcısından gelen ve 'my-org/my-repo' deposundaki 'main' dalından
# yürütülen GitHub Actions iş yüklerinin 'my-bucket' adlı Object Storage
# kovasına 'nesne okuma' ve 'nesne yazma' yetkisi verir.
# 'sub' alanı, OIDC jetonundaki subject (konu) alanına karşılık gelir.
# GitHub Actions için bu genellikle 'repo:org/repo:ref:refs/heads/branch' formatındadır.

oci iam policy create --compartment-id "ocid1.compartment.oc1..aaaaaaaayyyyyy" \
--name "GitHubActionsObjectStorageAccess" \
--description "Allow GitHub Actions to upload objects to a specific bucket" \
--statements '["ALLOW FEDERATED-USER \'ocid1.identityprovider.oc1..aaaaaaaazzzzzz\' TO MANAGE objects IN compartment id ocid1.compartment.oc1..aaaaaaaayyyyyy WHERE ANY {request.principal.type = \'GitHubActionsIdP\', request.principal.sub = \'repo:my-org/my-repo:ref:refs/heads/main\'}"]'
  

Yukarıdaki politika örneğinde, ocid1.identityprovider.oc1..aaaaaaaazzzzzz sizin oluşturduğunuz GitHubActionsIdP’nin OCID’si olmalıdır. my-org/my-repo ve my-bucket değerlerini kendi GitHub organizasyonunuz/deponuz ve OCI Object Storage kovan adınızla değiştirin. ocid1.compartment.oc1..aaaaaaaayyyyyy ise kovanın bulunduğu bölmenin OCID’sidir.

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

Son olarak, GitHub Actions iş akışı dosyamızı (örneğin, .github/workflows/deploy.yml) OCI kaynaklarına erişmek için yapılandırmamız gerekiyor. GitHub Actions’ın OIDC jetonunu OCI’ye sunmasını sağlayacak ve OCI CLI’yi kullanarak Object Storage’a erişeceğiz.

name: OCI Object Storage Deployment

on:
  push:
    branches:
      - main

permissions:
  id-token: write # Bu izni GitHub Actions'ın OIDC jetonu alması için ekleyin
  contents: read

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Setup OCI CLI
        uses: oracle-actions/setup-oci-cli@v1
        with:
          release: 'latest'

      - name: Configure OCI CLI with Workload Identity Federation
        run: |
          # OCI CLI'yı Workload Identity Federation ile yapılandırın
          # Bu komut, GitHub Actions'ın OIDC jetonunu OCI'ya sunmasını sağlar.
          # OCI CLI otomatik olarak OIDC jetonunu alıp bir OCI oturum jetonuna dönüştürür.
          # OCI_REGION ve OCI_TENANCY_OCID ortam değişkenlerini ayarlayın.
          echo "OCI_REGION=${{ secrets.OCI_REGION }}" >> $GITHUB_ENV
          echo "OCI_TENANCY_OCID=${{ secrets.OCI_TENANCY_OCID }}" >> $GITHUB_ENV
          echo "OCI_AUTH=federated_token" >> $GITHUB_ENV # OCI CLI'ya federasyon kullanmasını söyleyin

      - name: Upload files to OCI Object Storage
        env:
          BUCKET_NAME: my-application-artifacts
          FILE_TO_UPLOAD: my-app-v1.0.0.zip # Kendi dosya adınızı buraya yazın
        run: |
          # Örnek bir dosya oluştur (gerçek uygulamada derleme çıktısı olacaktır)
          echo "Bu benim uygulama dosyam." > $FILE_TO_UPLOAD
          
          # OCI Object Storage'a dosya yükle
          oci os object put -bn $BUCKET_NAME --file $FILE_TO_UPLOAD --name $FILE_TO_UPLOAD
          echo "Dosya '$FILE_TO_UPLOAD' başarıyla '$BUCKET_NAME' kovasına yüklendi."
  

Bu iş akışı, id-token: write iznini kullanarak GitHub Actions’ın OIDC jetonunu almasını sağlar. Ardından, oracle-actions/setup-oci-cli@v1 eylemi OCI CLI’yi kurar. OCI_AUTH=federated_token ortam değişkeni, OCI CLI’ya kimlik doğrulaması için Workload Identity Federation kullanmasını söyler. OCI CLI otomatik olarak GitHub tarafından sağlanan OIDC jetonunu alır ve OCI IAM ile değiş tokuş yaparak kısa ömürlü bir oturum jetonu elde eder. Bu oturum jetonu daha sonra OCI Object Storage’a dosya yüklemek için kullanılır. Bu süreçte hiçbir kalıcı OCI API anahtarı veya şifresi GitHub Actions sırlarında saklanmaz, bu da güvenliği önemli ölçüde artırır.

Kubernetes İş Yükleri OCI Hizmetlerine Nasıl Erişir?

Kubernetes kümeleri, genellikle OCI Object Storage, OCI Autonomous Database veya OCI Container Registry gibi çeşitli OCI hizmetleriyle etkileşim kuran uygulamaları barındırır. Bu etkileşimler için Kubernetes podlarının OCI kaynaklarına kimlik doğrulaması yapması gerekir. Geleneksel yöntemler, OCI API anahtarlarını Kubernetes sırları (secrets) olarak depolamayı ve bunları podlara enjekte etmeyi içerir. Ancak bu yaklaşım, sır yönetimi karmaşıklığı, sızdırılma riski ve anahtar döndürme gibi güvenlik endişelerini beraberinde getirir. OCI Workload Identity Federation, Kubernetes podlarının kalıcı kimlik bilgileri olmadan OCI’ye güvenli bir şekilde erişmesini sağlayarak bu sorunlara modern bir çözüm sunar.

Vaka Analizi: Kubernetes Podu OCI Object Storage’dan Konfigürasyon Okuma

Bir mikro hizmet uygulaması, Kubernetes kümesinde çalışıyor ve başlangıçta OCI Object Storage’dan konfigürasyon dosyalarını okuması gerekiyor. Geliştirme ekibi, bu podun OCI’ye erişimi için sırları kullanmak yerine, Kubernetes Service Account’ını OCI Workload Identity Federation ile entegre ederek daha güvenli bir yöntem uygulamak istiyor.

Adım 1: OCI IAM’de Bir Kimlik Sağlayıcı Oluşturma (Kubernetes için)

Öncelikle, OCI IAM’de Kubernetes kümemiz için bir OIDC Kimlik Sağlayıcı oluşturmalıyız. Bu, Kubernetes kümesinin API sunucusunun OIDC keşif uç noktasını kullanacaktır.

# Kubernetes API sunucusunun OIDC keşif uç noktasını bulun.
# Genellikle 'https:///.well-known/openid-configuration' şeklindedir.
# OCI Container Engine for Kubernetes (OKE) kullanıyorsanız, bu URL OKE kümenizin detaylarında bulunur.

# Örnek bir OCI CLI komutu:
oci iam identity-provider create --protocol "OIDC" \
--name "KubernetesIdP" \
--description "Kubernetes Cluster OIDC Identity Provider" \
--metadata-url "https:///.well-known/openid-configuration" \
--tenant-id "ocid1.tenancy.oc1..aaaaaaaaxxxxxx"
  

<OKE_API_SERVER_IP_OR_HOSTNAME> kısmını kendi Kubernetes kümenizin API sunucusu adresiyle değiştirmeniz gerekmektedir. OKE kullanıyorsanız, bu bilgiyi OKE konsolundan alabilirsiniz.

Adım 2: OCI Politikası Tanımlama ve Güven İlişkisi Kurma

Şimdi, Kubernetes podlarımızın OCI’da hangi ayrıcalıklara sahip olacağını belirten bir OCI politikası oluşturmalıyız. Bu politika, Kubernetes Service Account’ından gelen OIDC jetonunun belirli niteliklerine dayanarak bir güven ilişkisi kuracak.

# Bu politika, 'KubernetesIdP' sağlayıcısından gelen ve belirli bir Kubernetes Service Account'ına
# (örneğin, 'my-namespace/my-service-account') sahip iş yüklerine Object Storage'a erişim izni verir.
# 'sub' alanı, OIDC jetonundaki subject (konu) alanına karşılık gelir.
# Kubernetes için bu genellikle 'system:serviceaccount:namespace:serviceaccountname' formatındadır.

oci iam policy create --compartment-id "ocid1.compartment.oc1..aaaaaaaayyyyyy" \
--name "KubernetesObjectStorageReader" \
--description "Allow Kubernetes pods to read objects from a specific bucket" \
--statements '["ALLOW FEDERATED-USER \'ocid1.identityprovider.oc1..aaaaaaaazzzzzz\' TO READ objects IN compartment id ocid1.compartment.oc1..aaaaaaaayyyyyy WHERE ANY {request.principal.type = \'KubernetesIdP\', request.principal.sub = \'system:serviceaccount:my-namespace:my-service-account\'}"]'
  

Yukarıdaki politika örneğinde, ocid1.identityprovider.oc1..aaaaaaaazzzzzz sizin oluşturduğunuz KubernetesIdP’nin OCID’si olmalıdır. my-namespace ve my-service-account değerlerini kendi Kubernetes ad alanınız ve hizmet hesabı adınızla değiştirin. ocid1.compartment.oc1..aaaaaaaayyyyyy ise kovanın bulunduğu bölmenin OCID’sidir.

Adım 3: Kubernetes Service Account ve Pod Tanımını Yapılandırma

Kubernetes tarafında, OCI’ye erişecek pod için bir Service Account oluşturmalı ve bu Service Account’ı pod tanımına atamalıyız. Kubernetes, pod’a otomatik olarak OIDC jetonunu enjekte edecektir.

# my-service-account.yaml
apiVersion: v1
kind: ServiceAccount
metadata:
  name: my-service-account
  namespace: my-namespace # Kendi ad alanınızı buraya yazın
  annotations:
    # Bu annotation, Kubernetes'in OIDC jetonunu pod'a enjekte etmesini sağlar.
    # Bu ad alanı, OCI IAM'de tanımladığınız kimlik sağlayıcısının adıdır.
    # Not: Bazı Kubernetes sürümlerinde bu annotation'a gerek kalmayabilir,
    # doğrudan pod'un OIDC jetonu alması sağlanabilir.
    # Ancak, OCI'nin beklediği belirli bir format için bu annotation'ı kullanmak iyi bir uygulamadır.
    # oracle.com/workload-identity-federation: "true" # Örnek bir annotation, OCI entegrasyonuna göre değişebilir
    # Daha yaygın olarak, Kubernetes'in kendisi jetonu bir dosya olarak bağlar.
    # OCI SDK'ları ve CLI, bu jetonu otomatik olarak bulup kullanabilir.
serviceAccountToken:
  expirationSeconds: 3600 # Jetonun geçerlilik süresi (örneğin 1 saat)
  audience: "oci" # OIDC jetonunun hedef kitlesi (OCI tarafından beklenen değer)
  

# my-app-pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: my-app-config-reader
  namespace: my-namespace # Kendi ad alanınızı buraya yazın
spec:
  serviceAccountName: my-service-account # Yukarıda oluşturduğumuz Service Account'ı kullanın
  containers:
  - name: config-reader
    image: busybox # Basit bir örnek için busybox kullanıyoruz
    command: ["sh", "-c"]
    args:
      - |
        echo "OCI CLI ve SDK'lar otomatik olarak OIDC jetonunu bulacaktır."
        echo "OCI_REGION ve OCI_TENANCY_OCID ortam değişkenlerini ayarlayın."
        # OCI SDK'ları veya CLI, /var/run/secrets/kubernetes.io/serviceaccount/token dosyasını otomatik olarak okuyabilir.
        # Bu jeton, OCI IAM'e sunularak kısa ömürlü bir oturum jetonu alınmasını sağlar.
        
        # OCI CLI'yı veya SDK'yı kullanarak Object Storage'dan dosya oku
        # Bu kısım, gerçek uygulamanızda OCI SDK'sını veya CLI'yı çağıracaktır.
        # Örneğin: oci os object get -bn my-config-bucket --name config.json --file /tmp/config.json
        echo "Konfigürasyon dosyası okunuyor..."
        # Gerçek uygulamada, OCI SDK'sını kullanarak Object Storage'a erişim sağlanır.
        # Örneğin, Python SDK'sı:
        # import oci
        # config = oci.config.from_file(file_location="~/.oci/config")
        # identity_client = oci.identity.IdentityClient(config)
        # auth = oci.auth.signers.InstancePrincipalsSecurityTokenSigner()
        # object_storage_client = oci.object_storage.ObjectStorageClient(config, signer=auth)
        # ...
        
        # Basit bir simülasyon:
        sleep 30
        echo "Konfigürasyon okuma simülasyonu tamamlandı."
  

Bu yapılandırmada, my-service-account adlı bir Service Account oluşturulur ve my-app-config-reader podu bu Service Account’ı kullanır. Kubernetes, bu podun dosya sistemine (/var/run/secrets/kubernetes.io/serviceaccount/token yoluna) Service Account için kısa ömürlü bir OIDC jetonu bağlar. OCI SDK’ları ve CLI, bu jetonu otomatik olarak algılayıp OCI IAM ile değiş tokuş ederek kısa ömürlü bir OCI oturum jetonu elde edebilir. Böylece, pod, OCI Object Storage’a kalıcı kimlik bilgileri olmadan güvenli bir şekilde erişebilir. Bu yöntem, Kubernetes ortamlarında OCI kaynaklarına erişim için hem güvenliği hem de yönetilebilirliği önemli ölçüde artırır.

Yapay Zeka (AI) Ajanları ve OCI Kimlik Federasyonu: Geleceğin Güvenliği

Yapay zeka (AI) ve makine öğrenimi (ML) modelleri, günümüzün veri odaklı dünyasında giderek daha merkezi bir rol oynamaktadır. Bu modeller, genellikle büyük veri kümelerine erişmek, OCI Data Science servisleri gibi özel AI/ML hizmetlerini kullanmak veya sonuçları OCI Object Storage’a kaydetmek gibi görevler için OCI kaynaklarıyla etkileşim kurar. Geleneksel kimlik bilgisi yönetimi yöntemleri, AI/ML iş yüklerinin dinamik ve genellikle kısa ömürlü doğası göz önüne alındığında yetersiz kalabilir. Özellikle otonom AI ajanları veya sunucusuz fonksiyonlar (OCI Functions) gibi ortamlarda, kalıcı kimlik bilgileri kullanmak önemli güvenlik riskleri ve yönetim yükleri yaratır. OCI Workload Identity Federation, AI ajanları için de güvenli, ölçeklenebilir ve yönetilebilir bir erişim kontrolü sağlar.

Vaka Analizi: OCI Functions Üzerinde Çalışan Bir AI Ajanı OCI Vision API’sini Kullanıyor

Bir şirket, yüklenen görselleri analiz etmek için OCI Functions üzerinde çalışan bir yapay zeka ajanı geliştiriyor. Bu ajan, görselleri aldıktan sonra OCI Vision API’sini çağırarak nesne tanıma veya metin çıkarma işlemleri yapıyor ve sonuçları OCI Object Storage’a kaydediyor. Bu ajanın OCI Vision ve Object Storage’a erişimi için kalıcı kimlik bilgileri kullanmak yerine Workload Identity Federation’ı kullanarak güvenliği sağlaması gerekiyor.

Adım 1: OCI IAM’de OCI Functions için Dinamik Grup ve Politika Oluşturma

OCI Functions, yerleşik bir Workload Identity Federation mekanizmasına sahiptir. Fonksiyonlar, “Instance Principals” (Örnek Asıl Kimlikler) adı verilen bir mekanizma aracılığıyla kendilerini doğrularlar. Bu, aslında OCI’nin kendi içinde yönettiği bir federasyon türüdür.

# Bir dinamik grup oluşturun. Bu grup, belirli bir bölmedeki tüm fonksiyonları içerecektir.
oci iam dynamic-group create \
--name "MyAIFunctionsDynamicGroup" \
--description "Dynamic group for AI Functions in my AI compartment" \
--matching-rule "ALL {resource.type = 'fnfunc', resource.compartment.id = 'ocid1.compartment.oc1..aaaaaaaayyyyyy'}"

# Bu dinamik grubun OCI Vision ve Object Storage'a erişmesine izin veren bir politika oluşturun.
oci iam policy create --compartment-id "ocid1.compartment.oc1..aaaaaaaayyyyyy" \
--name "AIFunctionsAccessPolicy" \
--description "Allow AI Functions to use OCI Vision and Object Storage" \
--statements '["ALLOW DYNAMIC-GROUP \'MyAIFunctionsDynamicGroup\' TO USE ai-vision-family IN compartment id ocid1.compartment.oc1..aaaaaaaayyyyyy", "ALLOW DYNAMIC-GROUP \'MyAIFunctionsDynamicGroup\' TO MANAGE objects IN compartment id ocid1.compartment.oc1..aaaaaaaayyyyyy"]'
  

Burada, ocid1.compartment.oc1..aaaaaaaayyyyyy fonksiyonlarınızın ve ilgili kaynakların bulunduğu bölmenin OCID’sidir. ai-vision-family OCI Vision API’leri için kullanılan bir yetkilendirme fiilidir.

Adım 2: OCI Function Kodunu Geliştirme

Şimdi, OCI Functions üzerinde çalışacak AI ajanının kodunu yazmalıyız. Bu kod, OCI SDK’larını kullanarak OCI Vision API’sini çağıracak ve sonuçları Object Storage’a kaydedecektir. Önemli olan nokta, kodun kimlik doğrulaması için özel bir API anahtarı veya şifre içermemesi, bunun yerine OCI SDK’larının otomatik olarak Instance Principals mekanizmasını kullanmasına izin vermesidir.

# Python örneği (fn_app.py)
import oci
import os
import io
import json

# OCI SDK, Instance Principals ile otomatik olarak kimlik doğrulaması yapar.
# Herhangi bir kimlik bilgisi manuel olarak sağlanmaz.
signer = oci.auth.signers.InstancePrincipalsSecurityTokenSigner()

# Vision istemcisi
vision_client = oci.ai_vision.AIServiceVisionClient({}, signer=signer)

# Object Storage istemcisi
object_storage_client = oci.object_storage.ObjectStorageClient({}, signer=signer)

def handler(ctx, data: io.BytesIO = None):
    try:
        body = json.loads(data.getvalue())
        image_url = body.get("image_url")
        bucket_name = body.get("bucket_name", os.environ.get("DEFAULT_BUCKET"))
        object_name = body.get("object_name")

        if not image_url or not bucket_name or not object_name:
            raise ValueError("image_url, bucket_name ve object_name gerekli.")

        # Görseli Object Storage'dan oku
        get_object_response = object_storage_client.get_object(bucket_name, object_name)
        image_content = get_object_response.data.content

        # OCI Vision API'sini kullanarak görseli analiz et
        analyze_image_details = oci.ai_vision.models.AnalyzeImageDetails(
            features=[
                oci.ai_vision.models.ImageTextDetectionFeature(),
                oci.ai_vision.models.ImageObjectDetectionFeature()
            ],
            image=oci.ai_vision.models.Image(
                source="INLINE",
                data=base64.b64encode(image_content).decode('utf-8')
            )
        )
        analyze_image_response = vision_client.analyze_image(analyze_image_details)
        
        # Analiz sonuçlarını Object Storage'a kaydet
        results_object_name = f"analysis_results/{object_name}.json"
        object_storage_client.put_object(
            bucket_name, 
            results_object_name, 
            json.dumps(analyze_image_response.data.to_dict(), indent=2)
        )

        return {"status": "success", "message": f"Görsel analiz edildi ve sonuçlar '{results_object_name}' olarak kaydedildi."}

    except Exception as e:
        import traceback
        traceback.print_exc()
        return {"status": "error", "message": str(e)}, 500
  

Bu Python kodu örneğinde, oci.auth.signers.InstancePrincipalsSecurityTokenSigner() kullanılarak kimlik doğrulaması yapılır. Bu imzalayıcı, fonksiyonun çalıştığı ortamdan otomatik olarak kısa ömürlü bir kimlik jetonu alır ve OCI hizmet çağrılarını imzalamak için kullanır. Geliştiricinin herhangi bir hassas kimlik bilgisini koda gömmesine veya ortam değişkenleri aracılığıyla yönetmesine gerek kalmaz. Bu, AI ajanlarının OCI kaynaklarına güvenli bir şekilde erişmesini sağlarken, geliştirme ve operasyonel karmaşıklığı en aza indirir. Bu tür bir federasyon, AI/ML iş yüklerinin hızla dağıtılması ve güvenli bir şekilde ölçeklenmesi için idealdir.

İleri Düzey Kullanım İpuçları ve En İyi Uygulamalar

OCI Workload Identity Federation’ı etkin bir şekilde kullanmak, sadece temel kurulum adımlarını takip etmekten öteye geçer. Güvenliği en üst düzeye çıkarmak ve yönetimi kolaylaştırmak için bazı ileri düzey ipuçları ve en iyi uygulamaları göz önünde bulundurmak önemlidir.

• En Az Ayrıcalık İlkesi (Principle of Least Privilege): Her zaman iş yüklerinin yalnızca ihtiyaç duydukları kaynaklara ve yalnızca ihtiyaç duydukları eylemleri gerçekleştirecek şekilde erişimini sağlayın. OCI politikalarınızda, request.principal.sub gibi OIDC jetonu niteliklerini kullanarak erişimi mümkün olduğunca daraltın. Örneğin, belirli bir GitHub deposu ve dalı veya belirli bir Kubernetes ad alanı ve hizmet hesabı için ayrı ayrı politikalar tanımlayın. Geniş kapsamlı MANAGE ALL RESOURCES gibi ifadelerden kaçının.
• Jeton Ömrü Yönetimi: OCI tarafından verilen oturum jetonlarının ömrü kısadır (genellikle 1 saat). OCI SDK’ları ve CLI, bu jetonları otomatik olarak yenileyecek şekilde tasarlanmıştır. Ancak, özel uygulamalar geliştiriyorsanız, jeton yenileme mekanizmalarını doğru bir şekilde uyguladığınızdan emin olun. Jeton ömrünü çok uzun tutmak, güvenlik riskini artırırken, çok kısa tutmak performansı etkileyebilir.
• Denetim (Auditing) ve İzleme: OCI Cloud Guard ve OCI Audit hizmetlerini kullanarak federasyon tabanlı erişimleri sürekli olarak denetleyin ve izleyin. Kimlik sağlayıcıdan gelen jeton değişimlerini ve OCI kaynak erişimlerini kaydedin. Anormal erişim denemelerini veya yetkisiz erişimleri tespit etmek için uyarılar ve alarmlar kurun. Bu, güvenlik olaylarına hızlı yanıt vermenizi sağlar.
• Çoklu Ortamlar İçin Federasyon Stratejileri: Birden fazla GitHub deposu, Kubernetes kümesi veya AI ortamı için federasyon kullanıyorsanız, her biri için ayrı kimlik sağlayıcıları veya daha granüler politikalar tanımlayarak yönetimi kolaylaştırabilirsiniz. Örneğin, her üretim ortamı için ayrı bir OIDC IdP oluşturmak veya IdP içinde farklı sub değerlerini kullanarak farklı ortamları ayırmak iyi bir yaklaşımdır.
• Kimlik Sağlayıcı URL’lerinin Güvenliği: Kimlik sağlayıcınızın (GitHub, Kubernetes) OIDC keşif uç noktası URL’sinin güvenli olduğundan ve manipüle edilemediğinden emin olun. Bu URL’ler, OCI’nin güven ilişkisini kurduğu kritik noktalardır.
• Ortam Değişkenleri ve SDK Kullanımı: Mümkünse, OCI_AUTH=federated_token gibi ortam değişkenlerini veya OCI SDK’larının yerleşik federasyon desteğini kullanın. Bu, kimlik doğrulama sürecini basitleştirir ve uygulamanızın kodunda hassas kimlik bilgileri barındırma ihtiyacını ortadan kaldırır.
• Hata Yönetimi ve Yeniden Denemeler: Federasyon jetonları geçici olduğundan, ağ sorunları veya geçici hizmet kesintileri nedeniyle jeton değişimi veya kaynak erişiminde hatalar oluşabilir. Uygulamalarınızda uygun hata yönetimi ve yeniden deneme (retry) mekanizmaları uygulayarak dayanıklılığı artırın.
• Otomatik Dağıtım (IaC): Kimlik sağlayıcılarını, politikaları ve diğer OCI kaynaklarını Terraform gibi Altyapı olarak Kod (Infrastructure as Code – IaC) araçlarıyla yönetin. Bu, yapılandırmaların tutarlı olmasını sağlar, insan hatasını azaltır ve dağıtım süreçlerini otomatize eder.

Bu en iyi uygulamaları takip ederek, OCI Workload Identity Federation’ın sunduğu güvenlik ve operasyonel avantajlardan tam olarak yararlanabilir, bulut ortamlarınızdaki iş yükleri için sağlam ve güvenli bir kimlik yönetimi çerçevesi oluşturabilirsiniz.

Sonuç

OCI Workload Identity Federation, modern bulut güvenliği paradigmasında önemli bir adımı temsil etmektedir. Geleneksel olarak kullanılan uzun ömürlü kimlik bilgilerinin getirdiği riskleri ortadan kaldırarak, GitHub Actions, Kubernetes iş yükleri ve yapay zeka ajanları gibi otomasyon ve dinamik sistemlerin OCI kaynaklarına kalıcı kimlik bilgileri olmadan, güvenli ve verimli bir şekilde erişmesini sağlar. Bu sayede, güvenlik duruşu güçlenir, yönetim yükü azalır ve “en az ayrıcalık” ilkesi çok daha etkin bir şekilde uygulanabilir hale gelir.

Bu makalede, Workload Identity Federation’ın temel çalışma prensiplerini, GitHub Actions ve Kubernetes ile adım adım entegrasyon örneklerini ve yapay zeka ajanları için nasıl kullanılabileceğini detaylı bir şekilde inceledik. Ayrıca, ileri düzey kullanım ipuçları ve en iyi uygulamalarla, bu teknolojinin potansiyelini tam olarak nasıl kullanabileceğinizi gösterdik. OCI Workload Identity Federation’ı benimsemek, yalnızca güvenlik risklerini azaltmakla kalmaz, aynı zamanda DevOps süreçlerini hızlandırır ve bulut altyapınızın genel güvenilirliğini artırır. Geleceğin bulut güvenliği, kalıcı kimlik bilgisi olmayan erişim üzerine inşa edilmektedir ve OCI, bu geleceği bugün sunmaktadır.

Sıkça Sorulan Sorular (SSS)

1. OCI Workload Identity Federation hangi OCI hizmetleriyle çalışır?

OCI Workload Identity Federation, OCI IAM tarafından yetkilendirilen tüm OCI hizmetleriyle çalışır. Bu, Object Storage, Autonomous Database, Compute (Sanal Makineler ve Bare Metal), Container Registry, Functions, Data Science ve diğer birçok OCI hizmetini kapsar. Temel olarak, bir OCI politikası aracılığıyla erişim izni verebildiğiniz her hizmete Workload Identity Federation ile erişebilirsiniz.

2. OCI Workload Identity Federation kullanmanın maliyeti nedir?

OCI Workload Identity Federation’ın kendisi için doğrudan bir maliyet yoktur. OCI IAM hizmetinin bir parçası olarak sunulur ve OCI aboneliğinizin kapsamında yer alır. Ancak, bu özelliği kullanmak için entegre ettiğiniz harici kimlik sağlayıcılarının (örneğin, GitHub Enterprise için bazı maliyetler olabilir) veya OCI kaynaklarının (örneğin, Object Storage, Compute) kullanımına ilişkin standart OCI maliyetleri geçerlidir.

3. Geleneksel anahtar yönetimine göre Workload Identity Federation’ın başlıca farkları nelerdir?

Başlıca fark, Workload Identity Federation’ın kalıcı, uzun ömürlü kimlik bilgileri (API anahtarları, şifreler) kullanmamasıdır. Bunun yerine, kısa ömürlü, kriptografik olarak imzalanmış jetonlar aracılığıyla kimlik doğrulama yapar. Bu, kimlik bilgilerinin sızdırılma riskini ortadan kaldırır, anahtar döndürme yükünü azaltır, “en az ayrıcalık” ilkesini daha etkin uygular ve genel güvenlik duruşunu önemli ölçüde güçlendirir. Geleneksel anahtar yönetimi daha fazla manuel müdahale ve risk içerir.

4. Hangi durumlarda OCI Workload Identity Federation kullanmalıyım?

Workload Identity Federation’ı özellikle şu durumlarda kullanmalısınız:

• CI/CD boru hatları (örneğin, GitHub Actions, GitLab CI) OCI kaynaklarına erişim gerektirdiğinde.
• Kubernetes kümelerinde çalışan uygulamaların OCI hizmetleriyle etkileşim kurması gerektiğinde.
• Sunucusuz fonksiyonlar (OCI Functions) veya diğer kısa ömürlü iş yüklerinin OCI kaynaklarına erişmesi gerektiğinde.
• Yapay zeka/makine öğrenimi iş yüklerinin OCI veri depolarına veya AI hizmetlerine güvenli erişim sağlaması gerektiğinde.
• Güvenliği artırmak, kimlik bilgisi yönetim yükünü azaltmak ve uyumluluk gereksinimlerini karşılamak istediğinizde.

5. Diğer bulut sağlayıcılarında OCI Workload Identity Federation’a benzer çözümler var mı?

Evet, büyük bulut sağlayıcılarının çoğu, iş yükleri için benzer kimlik federasyonu çözümleri sunmaktadır:

• AWS: IAM Roles for Service Accounts (IRSA) ile Kubernetes için ve OpenID Connect (OIDC) sağlayıcıları aracılığıyla GitHub Actions gibi diğer iş yükleri için benzer yetenekler sunar.
• Azure: Workload Identity Federation özelliği, Azure AD (Active Directory) ile GitHub Actions gibi dış IdP’ler arasında güven ilişkileri kurarak benzer işlevsellik sağlar.
• Google Cloud: Workload Identity, Kubernetes Service Account’larını Google Cloud Service Account’larına bağlayarak ve Workload Identity Federation ile dış kimlik sağlayıcılarını entegre ederek benzer bir yaklaşım sunar.

Bu çözümlerin hepsi, kalıcı kimlik bilgisi olmadan güvenli erişim sağlamak için OIDC standardını temel alır.

#OCI #CloudSecurity #IdentityFederation #GitHubActions #Kubernetes #AI #DevOps