Google Cloud'da Permission Denied (403) Hatası Nasıl Çözülür (2026)

Google Cloud'da "Permission denied" ya da HTTP 403 hatası, hesabınızın o kaynak üzerinde istenen işlemi yapma izni olmadığını söyler. Hata iletisi eksik izni, kaynağı ve hesabı açıkça yazar. Önce bu üç bilgiyi alın, sonra Policy Troubleshooter ile nedenini görün ve gerekirse rolü verin ya da bir yöneticiden isteyin.

Bu hata neden oluşur

Google Cloud'da her işlem bir izne bağlıdır ve izinler rollerle verilir. Hata, çağrıyı yapan hesabın (kullanıcı ya da hizmet hesabı) o izne sahip olmadığı anlamına gelir. Google'ın izin hatası sayfasına göre gcloud ve REST arayüzü bu durumu şu biçimlerde bildirir:

ERROR: (gcloud.storage.buckets.list) PERMISSION_DENIED: EMAIL_ADDRESS does not have storage.buckets.list access

"error": { "code": 403, "message": "Permission 'storage.buckets.list' denied on resource" }

Hata iletisi eksik izni, erişilen kaynağı, kimliği doğrulanan hesabın e-posta adresini, benzersiz bir hata kimliğini ve Policy Troubleshooter bağlantısını içerir. Çözümün yarısı bu iletiyi dikkatle okumaktır.

Erişimi reddeden dört ayrı mekanizma vardır:

Permission denied hatası adım adım nasıl çözülür

1. Hata iletisinden eksik izni, kaynağı ve hesabı not edin. Konsolda iletideki hata kimliğini de kopyalayın.
2. Komut satırında hangi hesapla çalıştığınızı kontrol edin:

   gcloud auth list
   gcloud config get-value project

   Yanlış hesap ya da yanlış proje çoğu zaman sorunun kendisidir.
3. Policy Troubleshooter'ı açın. Konsolda hata kimliğini ya da hesap, kaynak ve izin bilgisini girip "Check access" düğmesine basın. Aracı kullanabilmek için kuruluş düzeyinde Security Reviewer (roles/iam.securityReviewer) rolü gerekir. Reddetme politikalarını görmek için Deny Reviewer (roles/iam.denyReviewer) rolü de gerekir.
4. Sonuca göre ilerleyin. Araç izin politikalarını, reddetme politikalarını ve Principal Access Boundary politikalarını inceler. Erişimin neden verilmediğini bunlardan hangisinin belirlediğini gösterir.
5. Rol eksikse, izni içeren en dar rolü hesaba ya da hesabın bulunduğu gruba verin. Rol atamak için genellikle roles/resourcemanager.projectIamAdmin gibi bir yetki gerekir.
6. Birkaç dakika bekleyip işlemi yeniden deneyin.

Komut satırından aynı kontrolü yapmak isterseniz Google'ın belgelediği komut şudur. Bu komut için Service Usage Consumer rolü de gerekir:

gcloud beta policy-intelligence troubleshoot-policy iam KAYNAK \
    --principal-email=EPOSTA \
    --permission=IZIN

Policy Troubleshooter sonucu nasıl okunur

Araç erişim durumunu bir değerle bildirir. ALLOW_ACCESS_STATE_GRANTED hesabın izne sahip olduğunu, ALLOW_ACCESS_STATE_NOT_GRANTED sahip olmadığını gösterir. Genel sonuç CANNOT_ACCESS ise erişim reddedilmiştir. Sonuç ayrıca bir reddetme politikasının ya da Principal Access Boundary politikasının erişimi engelleyip engellemediğini belirtir. Rol verilmiş görünüyorsa ama erişim yine yoksa bakmanız gereken yer burasıdır.

Rolü verme yetkim yoksa ne yapmalıyım

Erişim politikasını değiştirme yetkiniz yoksa yöneticiye iki bilgi göndermeniz yeterlidir: hata iletisindeki hata kimliği ve eksik izinlerin listesi. Konsolda eksik izin listesinin yanındaki "Request permissions" düğmesine basarsanız otomatik oluşturulmuş bir e-posta gönderebilir ya da iletiyi kopyalayıp kendi talep sisteminize yapıştırabilirsiniz. Yöneticiye "erişim yok" demek yerine bu bilgileri vermek, talebin dakikalar içinde karşılanmasını sağlar.

Rol verdim ama hata sürüyor, neden

İlk neden bekleme süresidir. Google'ın erişim değişikliği sayfasına göre politika değişiklikleri genellikle 2 dakikada, bazen 7 dakika ya da daha uzun sürede yayılır. Grup üyeliği değişiklikleri genellikle birkaç dakika, bazen saatler sürebilir. Gruba eklemek çıkarmaktan, doğrudan grup değişikliği iç içe grup değişikliğinden daha hızlı yayılır.

Bekleme süresi dolduysa şunlara bakın:

• Rol yanlış düzeyde verilmiş olabilir. Proje düzeyinde verilen rol başka bir projedeki kaynağı kapsamaz.
• Seçtiğiniz rol, hatadaki izni gerçekten içermiyor olabilir. Rol dizininde izni arayıp doğrulayın.
• Bir reddetme politikası izni engelliyor olabilir. Politika, rol ne olursa olsun erişimi keser.
• Hizmet hesabı kullanıyorsanız rolün hizmet hesabına verildiğinden emin olun. Kendi kullanıcınıza verilen rol, hizmet hesabının yetkisini artırmaz.

Geçici erişim ve grup yöntemi ne zaman kullanılır

Google'ın çözüm sayfası, izin politikası hatası için üç yol sayar: uygun rolü doğrudan vermek, Privileged Access Manager üzerinde tanımlı bir yetkilendirmeye karşı gelen geçici erişim talebini onaylamak ya da kullanıcıyı gerekli rolleri zaten almış bir gruba eklemek. Kalıcı bir ihtiyaç yoksa geçici erişim, hesabın gereğinden uzun süre geniş yetkide kalmasını önler. Kalıcı bir ihtiyaç varsa grup yöntemi, rolü kişiye değil göreve bağlar. Konsoldaki hata penceresi de izni içeren önerilen rolleri doğrudan listeler ve tıklayarak verebilirsiniz.

Reddetme politikasından gelen hata nasıl giderilir

Policy Troubleshooter erişimin bir reddetme politikasıyla engellendiğini gösteriyorsa rol vermek sonuç getirmez. Google dört yol önerir: kullanıcıyı reddetme kuralında istisna hesap yapmak, bir istisna grubuna eklemek, kuraldan ilgili izni çıkarmak ya da kaynağı kuraldaki etiket koşuluyla dışarıda bırakmak. Principal Access Boundary kaynaklı engellerde ise politikaya kaynağı eklemek ya da hesabı muaf tutan bir koşul tanımlamak gerekir. Bu değişiklikler güvenlik kararıdır ve kuralı yazan yöneticinin onayından geçmelidir.

Çözülmezse neye bakmalı

Üstteki adımlar sonuç vermediyse kuruluş düzeyindeki kısıtlamalara ve hizmetin kendi izin modeline bakın. BigQuery gibi bazı hizmetlerin kendi erişim denetimi sayfaları vardır. Google, BigQuery için bu hataları ayrı bir sorun giderme sayfasında örnekleriyle anlatır. Kuruluş kaynak hiyerarşisinde yalnızca kuruluş yöneticisinin görebildiği politikalar varsa, Policy Troubleshooter bile tam sonucu göstermeyebilir. Bu durumda kuruluş yöneticisinden aracı sizin adınıza çalıştırmasını isteyin.

Bu hatadan korunmak için hangi düzen kurulmalı

Rolleri tek tek kullanıcılara değil gruplara verin. İşten ayrılan ya da görev değiştiren kişi için yalnızca grup üyeliği değişir. Gerekenden geniş rol (Owner, Editor) yerine izni içeren en dar rolü seçin. Hizmet hesaplarına ihtiyaçları kadar yetki tanıyın ve kimin hangi rolü neden aldığını bir tabloda tutun. Bu düzen hem hata sayısını azaltır hem de Google Cloud güvenlik denetimlerinde işinizi kolaylaştırır. Faturalama tarafında benzer bir yetki hatası yaşıyorsanız faturalama hesabı bağlı değil hatası yazımıza bakın.

IAM rollerinizi, grup yapınızı ve hizmet hesaplarınızı gözden geçirip erişim hatalarını kalıcı olarak azaltmayı sizin yerinize yapabiliriz. Bize ulaşın, mevcut Google Cloud yapınıza birlikte bakalım.