Cosign ile Container İmzalama: Sigstore Kurulum, Doğrulama ve Kubernetes Politika Rehberi 2026

Güncellendi: 25 Ağustos 2026

Cosign, Sigstore projesinin bir parçası olarak OCI container imajlarını, Helm chart'larını ve rastgele artefaktları kriptografik olarak imzalayıp doğrulamayı sağlayan açık kaynaklı bir araçtır. 2026 itibarıyla Cosign 2.4 serisi, anahtarsız (keyless) OIDC tabanlı imzalamayı, in-toto attestation'larını ve SLSA v1.0 provenance formatını yerel olarak destekleyerek modern tedarik zinciri güvenliği için fiili standart haline geldi. Bu rehberde Cosign kurulumundan Kubernetes'te imza zorunluluğuna kadar gerekli tüm adımları, kendi üretim ortamımda karşılaştığım tuzaklarla birlikte bir mimar gözüyle ele alıyorum.

• Cosign 2.4, Fulcio üzerinden OIDC tabanlı efemer sertifikalarla anahtarsız imzalamayı destekler; özel anahtar saklama yükünü ortadan kaldırır.
• İmzalar, SBOM'lar ve SLSA provenance dahil tüm attestation'lar Rekor şeffaflık günlüğüne kaydedilir; imza sonrası müdahale kanıtlanabilir hale gelir.
• Kubernetes'te Kyverno 1.13 veya Sigstore Policy Controller ile verifyImages kuralları imzasız imajları admission aşamasında bloklar.
• GitHub Actions'ta sigstore/cosign-installer ve id-token: write izniyle yaklaşık 30 satırlık iş akışı, tüm imajlara doğrulanabilir provenance ekler.
• Cosign vs Notary v2 vs Docker Content Trust karşılaştırmasında Cosign, OCI standartlarına bağlılık ve keyless destek nedeniyle üretimde en olgun seçenektir.
• SLSA Level 3 uyumluluğu için imzanın kendisi değil, üzerine eklenen build provenance attestation'ının doğrulanması zorunludur.

Cosign ve Sigstore nedir, nasıl çalışır?

Sigstore, yazılım artefaktlarının kaynağını ve bütünlüğünü doğrulanabilir kılmak için Linux Foundation altında geliştirilen bir açık kaynak ekosistemidir. Üç temel bileşenden oluşur: Cosign (imzalayıcı istemci), Fulcio (kısa ömürlü kod imzalama sertifika otoritesi) ve Rekor (append-only şeffaflık günlüğü). Cosign, bu üç bileşeni orkestre ederek klasik PKI'ın operasyonel yükünü (anahtar rotasyonu, HSM entegrasyonu, revocation) büyük ölçüde ortadan kaldırır.

Klasik akışta bir OCI imajını imzaladığınızda Cosign, imza manifestini <imaj-digest>.sig etiketiyle aynı registry'e yazar. Bu, ayrı bir imza altyapısı yönetme ihtiyacını ortadan kaldırır; imza, imajın yaşam döngüsüyle birlikte taşınır. 2026 sürümüyle birlikte Cosign, referrers API (OCI 1.1) desteğini varsayılan hale getirdi. Artık imza etiketleri --registry-referrers-mode bayrağıyla registry içinde otomatik olarak imaj digest'ine eşlenebiliyor. Mimar açısından bu, "imzayı hangi bucket'ta arayacağım?" sorusunu ortadan kaldıran önemli bir sadeleştirmedir.

Sigstore'un asıl yeniliği, X.509 sertifikalarını kısa ömürlü tutmasıdır: Fulcio, bir OIDC token karşılığında yalnızca 10 dakika geçerli bir sertifika verir. Sertifika süresi dolsa bile imza geçerliliğini korur, çünkü Rekor'a yazılan zaman damgası imzanın sertifika geçerliyken oluşturulduğunu kanıtlar. Bu yapı, çalınmış imzalama anahtarlarının uzun vadeli riskini teoride sıfıra indirir.

Container imzalama neden kritik bir güvenlik katmanıdır?

Bir mimar olarak "önce ne kırılır?" sorusuyla başlıyorum. Container tedarik zincirinde tipik saldırı yüzeyi şudur: geliştirici makinesi, CI runner, build cache, base image, registry ve nihayet cluster. Bu yolun herhangi bir noktasında bir saldırgan katmanı değiştirirse (typosquatting, kötü niyetli maintainer, ele geçirilmiş CI token), imzasız bir dağıtımda cluster'ınız zehirlenmiş kod çalıştırır. 2020'deki SolarWinds ve 2023'teki 3CX olayları, imzasız artefaktların blast radius'unun neden bütün üretim ortamına yayıldığını somut biçimde gösterdi.

Cosign imzası bu blast radius'u iki noktada daraltır. İlki doğrulama noktasında: Kubernetes admission controller, imzasız veya beklenmedik bir kimlikle imzalanmış imajı asla scheduler'a iletmez. İkincisi denetlenebilirlik: Rekor'a yazılan her imza, hangi CI iş akışının, hangi commit'in ve hangi kimliğin imajı ürettiğini kanıtlar. Böylece insident sonrası "bu imaj gerçekten bizim mi?" sorusuna dakikalar içinde cevap alırsınız.

2026 itibarıyla ABD federal ajansları için CISA'nın SLSA v1.0 uyumluluk hedefi Level 3 seviyesinde konumlanmış durumda. SLSA Level 3, build provenance'ın kriptografik olarak imzalanmış ve non-falsifiable olmasını gerektirir; bu da pratikte Cosign + keyless OIDC + Rekor kombinasyonunu neredeyse zorunlu kılıyor. Tedarik zinciri güvenliğini Trivy ile container görüntü tarama süreciyle birlikte kurguladığınızda, "sadece taranmış" değil "hem taranmış hem imzalı" imajları dağıtabilirsiniz.

Cosign kurulumu ve ilk imzalama adımları

Cosign 2.4.x tek statik Go binary'sidir. Sistem paketleri, brew, apt veya doğrudan GitHub Releases üzerinden kurulur. Debian/Ubuntu için önerdiğim yol şu:

# Cosign 2.4.1 (Ağustos 2026), resmi imza doğrulanmış binary
COSIGN_VERSION=2.4.1
curl -sSLo cosign https://github.com/sigstore/cosign/releases/download/v${COSIGN_VERSION}/cosign-linux-amd64
sudo install -m 0755 cosign /usr/local/bin/cosign
cosign version
# GitVersion: v2.4.1
# GoVersion:  go1.22.5

Kurulum sonrası ilk adım, imza kimliğinize karar vermektir. İki yol var: anahtar tabanlı (yerel cosign.key + cosign.pub çifti) veya anahtarsız (OIDC üzerinden efemer sertifika). Üretim için neredeyse her zaman keyless öneriyorum. Ancak air-gapped ortamlarda anahtar tabanlı yaklaşım kaçınılmazdır. Aşağıda her iki yol için minimum çalışan örnek var:

# --- Anahtar tabanlı imzalama ---
cosign generate-key-pair
# cosign.key ve cosign.pub üretilir
# ÖNEMLİ: cosign.key HSM veya KMS ile korunmalı; yerel dosya sistemi tek başına yeterli değil

# İmaj imzalama (registry'e push edilmiş bir imaj olmalı)
cosign sign --key cosign.key ghcr.io/example/api:v1.2.3

# Doğrulama
cosign verify --key cosign.pub ghcr.io/example/api:v1.2.3

Cosign, tag yerine her zaman digest ile çalışır; dahili olarak tag'i çözer, digest'i imzalar. Bu, tag'in daha sonra farklı bir imaja overwrite edilmesi durumunda bile eski imzanın geçersiz olmasını sağlar. Denetlenebilirlik için CI pipeline'ınızın Cosign'a doğrudan @sha256:... geçmesi bu davranışı açık ve kayıt altına alınabilir hale getirir.

Anahtarsız imzalama: Fulcio, Rekor ve OIDC akışı

Keyless mode, Cosign'ın modern kullanım şeklidir. Akış şu şekilde işler: (1) Cosign, OIDC provider'dan (Google, GitHub, GitLab, Kubernetes SA token) bir ID token alır, (2) tokeni Fulcio'ya sunar, (3) Fulcio, token'daki subject'i (örn. https://github.com/example/repo/.github/workflows/release.yml@refs/tags/v1.2.3) sertifika SAN alanına yazarak 10 dakikalık bir X.509 üretir, (4) Cosign bu sertifikayla imza atar ve imza + sertifika + inclusion proof'u Rekor'a kaydeder.

Yerel geliştirici makinesinde ilk keyless imzalama şöyledir:

# Cosign, tarayıcı üzerinden OIDC akışı başlatır
cosign sign ghcr.io/example/api@sha256:9b7c...

# Beklenen çıktı:
# Generating ephemeral keys...
# Retrieving signed certificate...
# Successfully verified SCT...
# tlog entry created with index: 148920334
# Pushing signature to: ghcr.io/example/api

# Doğrulama: kimin, hangi iş akışıyla imzaladığını da kontrol ediyoruz
cosign verify \
  --certificate-identity-regexp "^https://github.com/example/repo/.github/workflows/.+" \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com \
  ghcr.io/example/api@sha256:9b7c...

--certificate-identity-regexp ve --certificate-oidc-issuer bayrakları kritiktir. Bunları belirtmezseniz Cosign, imzayı yalnızca kriptografik olarak doğrular; imzalayanın kim olduğunu doğrulamaz. Bir saldırgan kendi GitHub hesabından imza atsa bile kriptografik doğrulama geçer, ancak identity regex sizin repo'nuza uymadığında doğrulama başarısız olur. Politikanın en az işlem karşılığı en yüksek etki noktası burasıdır: her cosign verify çağrısı identity kısıtı içermek zorundadır.

OIDC federasyonu ile CI kimliği

GitHub Actions, GitLab CI, CircleCI ve Kubernetes 1.28+ hepsi OIDC token verir. Fulcio, bu token'daki subject alanını doğrudan sertifika SAN'ına kopyalar. Böylece imzalayan kimlik değişmez, insan müdahalesi gerekmez ve anahtar hiçbir yerde saklanmaz. Örneğin GitHub Actions için id-token: write izni yeterlidir; ayrı bir secret yönetimine ihtiyaç kalmaz.

SBOM ve in-toto attestation'ları Cosign ile bağlama

İmza sadece "bu imaj bizden geldi" der. Modern tedarik zinciri güvenliği bunun ötesinde yapılandırılmış metadata talep eder: SBOM (imajdaki tüm paketler), build provenance (imaj hangi commit'ten, hangi runner'da üretildi), test sonuçları, güvenlik tarama raporları. Cosign, bu metadataları attestation olarak imzalanmış in-toto zarflarına sarar ve registry'e iliştirir.

# 1) Syft ile SPDX formatında SBOM üret
syft ghcr.io/example/api@sha256:9b7c... -o spdx-json > sbom.spdx.json

# 2) SBOM'u attestation olarak imajla ilişkilendir (keyless)
cosign attest --predicate sbom.spdx.json --type spdxjson \
  ghcr.io/example/api@sha256:9b7c...

# 3) Doğrulama: kim tarafından, hangi tipte attestation atıldı?
cosign verify-attestation \
  --certificate-identity-regexp "^https://github.com/example/repo/.+" \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com \
  --type spdxjson \
  ghcr.io/example/api@sha256:9b7c...

Aynı prensiple SLSA build provenance ekleyebilirsiniz. GitHub Actions'ın actions/attest-build-provenance action'ı, Cosign'ı arka planda çalıştırarak SLSA v1.0 uyumlu provenance üretir; bu attestation'ı Rekor'a kaydeder ve sonrasında cosign verify-attestation --type slsaprovenance1 ile doğrulayabilirsiniz. Container tarama sonuçlarını attestation olarak eklemek istiyorsanız, Trivy'nin taradığı imajlar için trivy image --format cyclonedx çıktısını --type cyclonedx ile ekleyebilirsiniz.

Kubernetes'te Cosign imza zorunluluğu (Kyverno ve Policy Controller)

İmza atmak yeterli değil; kümenin imzasız imajları reddetmesi gerekir. 2026'da iki yaygın seçenek var: Kyverno 1.13 ve Sigstore Policy Controller (eski adıyla policy-controller/cosigned). Ben yeni projelerde Kyverno tercih ediyorum, çünkü aynı controller network policy, PSA replacement ve mutating rules gibi diğer politikaları da yönetiyor; operasyonel yüzey azalıyor.

Aşağıdaki Kyverno ClusterPolicy, ghcr.io/example/* altındaki her imajın belirli bir GitHub Actions iş akışıyla imzalanmış olmasını zorunlu kılar:

apiVersion: kyverno.io/v2beta1
kind: ClusterPolicy
metadata:
  name: require-signed-images
spec:
  validationFailureAction: Enforce
  webhookConfiguration:
    failurePolicy: Fail
  rules:
    - name: verify-cosign-signature
      match:
        any:
          - resources:
              kinds:
                - Pod
      verifyImages:
        - imageReferences:
            - "ghcr.io/example/*"
          attestors:
            - entries:
                - keyless:
                    subject: "https://github.com/example/repo/.github/workflows/release.yml@refs/heads/main"
                    issuer: "https://token.actions.githubusercontent.com"
                    rekor:
                      url: https://rekor.sigstore.dev
          mutateDigest: true
          verifyDigest: true
          required: true

Bu politikanın operasyonel karakteri şudur: mutateDigest: true, Kyverno'ya tag'leri deploy anında digest'e resolve ettirir. Böylece imzayı doğrulamak için Kyverno'nun kontrol ettiği imaj referansı, kubelet'in sonradan çektiği imajla birebir aynıdır; TOCTOU (time-of-check to time-of-use) saldırılarını engeller. required: true ise imaj Cosign imzasına sahip değilse pod'u tamamen reddeder; unsigned'a fallback yoktur.

Namespace bazlı istisnalar

Genellikle kube-system, ingress-nginx gibi upstream namespace'lerin imzasız imaj çalıştırmasına izin vermek gerekir. Bunu exclude bloğu ile yapabilirsiniz. Ancak "istisna listesi" ile "istisnasız enforcement" arasındaki dengeyi düzenli olarak gözden geçirmenizi öneririm. Blast radius perspektifinden, imzasız çalışabilen her namespace potansiyel bir yatay hareket noktasıdır.

CI/CD pipeline'ında Cosign entegrasyonu

GitHub Actions için minimum çalışan iş akışı aşağıdadır. Buildx ile imajı üretir, GHCR'e push eder ve OIDC token'ıyla keyless imzalar:

name: build-sign-push
on:
  push:
    tags:
      - "v*"

permissions:
  contents: read
  packages: write
  id-token: write   # OIDC, keyless Cosign için ZORUNLU

jobs:
  build:
    runs-on: ubuntu-24.04
    steps:
      - uses: actions/checkout@v4

      - uses: docker/login-action@v3
        with:
          registry: ghcr.io
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}

      - uses: docker/setup-buildx-action@v3

      - id: build
        uses: docker/build-push-action@v6
        with:
          push: true
          tags: ghcr.io/${{ github.repository }}:${{ github.ref_name }}

      - uses: sigstore/[email protected]
        with:
          cosign-release: v2.4.1

      - name: Sign image with keyless cosign
        env:
          IMAGE: ghcr.io/${{ github.repository }}@${{ steps.build.outputs.digest }}
        run: cosign sign --yes "$IMAGE"

      - name: Attach SBOM attestation
        env:
          IMAGE: ghcr.io/${{ github.repository }}@${{ steps.build.outputs.digest }}
        run: |
          syft "$IMAGE" -o spdx-json > sbom.spdx.json
          cosign attest --yes --predicate sbom.spdx.json --type spdxjson "$IMAGE"

--yes bayrağı, Cosign'ın "bu işlem Rekor şeffaflık günlüğüne kalıcı olarak yazılacak, devam edilsin mi?" onay istemesini bastırır ve CI için gereklidir. Rekor'a yazılan her giriş herkese açık olduğundan, iş akışı adının ve repo isminin şeffaflık günlüğünde görüneceğini unutmayın; özel repo isimleri hassassa OIDC subject'i redact eden bir private Sigstore instance düşünmelisiniz.

Aynı iş akışında bir güvenlik testi de eklemek istiyorsanız, imzalama adımından önce Falco için custom kural taraması veya Trivy CVE taraması ekleyebilirsiniz. Başarısız tarama, imzalama adımına ulaşmaz; yani üretime hiçbir zaman zayıf bir imaj imzalanmış olarak gitmez.

Cosign vs Notary v2 vs Docker Content Trust

Bu üç çözüm arasındaki farkları anlamadan seçim yapmak, ileride migrasyon maliyetine dönüşür. Aşağıdaki tablo 2026 itibarıyla üretim ortamında değerlendirmeniz gereken boyutları özetliyor:

Özellik	Cosign / Sigstore	Notary v2 (notation)	Docker Content Trust
OCI 1.1 uyumu	Tam (referrers API)	Tam (yerel tasarım)	Yok (eski tag şeması)
Anahtarsız (OIDC) imzalama	Evet (Fulcio)	Deneysel	Hayır
Şeffaflık günlüğü	Rekor (varsayılan)	Yok	Yok
Attestation desteği (SBOM/SLSA)	Yerel (in-toto)	OCI artifact üzerinden	Yok
Kubernetes admission entegrasyonu	Kyverno, Policy Controller	ratify (CNCF sandbox)	Yok
Endüstri kabulü (2026)	Yüksek (GitHub, GitLab, AWS, Google)	Orta (Azure ACR odaklı)	Düşük (deprecated akış)
Air-gapped kullanım	Private Sigstore instance	Doğrudan destek	Notary v1 gereksinimi

Kararı sadeleştirmek için: internet erişimi olan modern bir CI'da çalışıyorsanız Cosign + Fulcio + Rekor tercih edin. Azure ACR ağır bir stack üzerinde çalışıyorsanız notation, ACR'ın yerel entegrasyonu nedeniyle daha az sürtüşme yaratabilir. Docker Content Trust'ı bugün yeni bir sistemde açmak için hiçbir teknik gerekçe kalmadı. Notary v1 sunucusu deprecated ve OCI referrers desteği yok.

Sık yapılan hatalar ve sorun giderme

Cosign'ı üretime çıkardığımda en sık gördüğüm dört hata var. Bunları başta önlemek, ileride pipeline'ı geceyarısı debug etmekten çok daha ucuz.

1) "no matching signatures", verify identity eksik

En yaygın hata. cosign verify çağrınızda --certificate-identity veya --certificate-identity-regexp ve --certificate-oidc-issuer bayraklarından biri eksikse, Cosign 2.x hata verir. Bunu asla shell script içinde || true ile bastırmayın; identity doğrulaması, keyless imzalamanın tek güvenlik anahtarıdır.

2) Rekor yazma hataları CI'ı düşürüyor

Rekor arada yavaşlar veya bakım penceresine girer. Bunu tolere etmek için --rekor-url ile alternatif bir mirror kullanabilir veya kısa süreliğine COSIGN_EXPERIMENTAL=1 cosign sign --tlog-upload=false ile yerel imzalama yapabilirsiniz. Ancak bu imzalar sonradan Rekor'a upload edilmezse denetim zincirinde eksik kalır.

3) Kyverno policy pod'u başlatamıyor: "failed to verify image"

Genellikle imagePullSecrets ile Kyverno namespace'i eşleşmiyordur; Kyverno registry'e ulaşamıyor demektir. Kyverno controller pod'unun ghcr.io için secret referansına sahip olduğundan emin olun. Ayrıca subject regex'i kaçırılmış karakter içerebilir; @, ., / karakterlerini regex'te escape etmeyi unutmayın.

4) İmaj tag'i overwrite edildi, imza artık geçerli değil

Cosign imzaları digest'e bağlıdır, tag'e değil. Birisi ghcr.io/example/api:latest tag'ini yeni bir imaja işaret ettirdiyse, eski imza yeni digest için geçerli değildir. Bu, bir bug değil özelliktir, ancak "neden pod başlatılamıyor?" hatasına yol açar. Çözüm: production manifest'lerinizde her zaman @sha256:... digest kullanın; tag'e bel bağlamayın. systemd unit sandboxing için de aynı prensip geçerlidir: değişebilen referansları güvenlik sınırı olarak kullanmayın.

Sıkça Sorulan Sorular

Cosign ne için kullanılır?

Cosign, OCI container imajlarını, Helm chart'larını ve rastgele artefaktları kriptografik olarak imzalamak ve doğrulamak için kullanılan açık kaynaklı bir Sigstore aracıdır. Ayrıca SBOM, SLSA build provenance ve güvenlik tarama sonuçlarını imzalanmış attestation'lar olarak imaja iliştirebilir. Ana kullanım senaryosu, tedarik zinciri saldırılarına karşı Kubernetes cluster'larında imza zorunluluğu uygulamaktır.

Anahtarsız (keyless) imzalama gerçekten güvenli mi?

Evet. Keyless imzalama, uzun ömürlü özel anahtar saklama riskini ortadan kaldırır. Fulcio'nun verdiği sertifika sadece 10 dakika geçerlidir; imzanın kendisi ise Rekor şeffaflık günlüğündeki zaman damgası sayesinde süresiz doğrulanabilir kalır. Güvenlik zayıflığı asıl OIDC provider'ınızın uzlaşmasında ortaya çıkar, bu nedenle GitHub Actions gibi OIDC issuer'ların korunması eskiden anahtarları korumak kadar kritiktir.

Cosign ile Notary v2 arasındaki temel fark nedir?

Cosign, OIDC tabanlı keyless imzalama ve Rekor şeffaflık günlüğü ile birlikte gelir; Notary v2 (notation) ise klasik PKI'ya dayanır ve keyless desteği hâlâ deneyseldir. Cosign'ın attestation ekosistemi (in-toto, SLSA, SBOM) daha olgundur, Notary v2 ise Azure Container Registry ile daha sıkı entegre çalışır. Yeni projelerde çoğu ekip Cosign'ı tercih etmektedir.

Kubernetes'te imza zorunluluğunu nasıl aktive ederim?

En yaygın iki yol Kyverno 1.13 ve Sigstore Policy Controller'dır. Kyverno için bir ClusterPolicy tanımlayıp verifyImages kuralı içinde keyless subject ve issuer alanlarını belirtmeniz yeterlidir. Bu politika Enforce modunda çalıştığında, imzasız veya yanlış kimlikle imzalanmış imajları içeren pod'lar admission aşamasında reddedilir.

Air-gapped bir ortamda Cosign kullanılabilir mi?

Evet, ancak public Sigstore altyapısı yerine private bir Sigstore instance kurmanız gerekir. Bu, kendi Fulcio ve Rekor servislerinizi çalıştırmayı, güvendiğiniz bir OIDC provider bağlamayı ve Cosign istemcilerini --fulcio-url, --rekor-url, SIGSTORE_ROOT_FILE gibi bayraklarla yönlendirmeyi içerir. Alternatif olarak anahtar tabanlı imzalama (bir HSM veya KMS ile) tamamen offline çalışır.