Yıllardır var olan kurumlar genelde iki kimlik sistemi işletir: biri bulut sağlayıcısının (IAM rolleri, yürütme rolleri), diğeri kendilerinin; iç servisler bir isteğe cevap verirken asıl bu ikinciye bakar. Kendi kurduğun altyapıda kimliği istediğin gibi başlatabilirsin. Yönetilen hesaplamada ise sağlayıcı sürecine bir bulut kimliği verir ve başka bir şey vermez. Yazı bu boşluğu Amazon EMR üzerindeki Spark iş yükleri için nasıl kapattıklarını anlatıyor; ama ‘anlatılanların çok azı Spark’a ya da EMR’a özgü’.

Netflix'te servisler arası kimlik doğrulama Metatron adlı özel bir PKI üzerinde çalışıyor: her iş yükü kısa ömürlü bir X.509 sertifikası alıyor ve servisler karşılıklı TLS (mTLS) ile birbirini doğruluyor. Sertifikayı iş yükü kendisi isteyemiyor; kimlik servisi, isteyenin iddia ettiği iş yükü olduğuna kanaat getirdikten sonra veriyor. Bu doğrulamaya attestation deniyor. İkinci kavram Data Project: verinin sahiplik birimi; tabloların sahibi, yetkili kullanıcıları ve kendi kimliği var ve işler kendilerini başlatan kişi olarak değil Data Project olarak çalışıyor.

Tasarımın temeli Spark yığınının dışında verilmiş bir karar: her Data Project kimliği, özel bir IAM rolüne 1:1 eşleniyor ve bu eşlemeyi Data Project servisi kaydediyor. Eşleme ‘bu süreç R rolüyle çalışıyor’ (sağlayıcının dili) cümlesini ‘bu süreç W iş yükü’ (bizim dilimiz) cümlesine çevirmeyi mümkün kılıyor; yazıdaki tespit: iki kimlik sistemini köprülemenin zor kısmı protokol değil, bir eşlemeyi taahhüt edip yetkili tutmak. Bir AWS hesabı on binlerce rol tutamadığı için roller hesaplar arasında deterministik olarak bölünüyor.

Akış üç adım. (1) Kontrol düzlemi imzalı bir iddia üretir: Spark işlerini başlatma yetkisi yalnızca ona ait; Data Project'in rolünü çözüp iş yükü metadata'sını imzalıyor. (2) İş yükü bulut kimliğine sahip olduğunu kanıtlar: sürücü tarafındaki Spark eklentisi, rolün kimlik bilgileriyle sts:GetCallerIdentity isteğini imzalıyor ama göndermiyor ve ortaya kısa ömürlü bir ön-imzalı URL çıkıyor. URL'yi herkes çağırabilir, ama onu yalnızca rolün kimlik bilgilerine sahip olan üretebilir; ve cevap iş yükünden değil AWS'ten gelir, yani iş yükü cevap konusunda yalan söyleyemez. (3) Kimlik servisi iki kanıtı karşılaştırır: URL'yi AWS STS'e karşı çağırıp rolü okur (sağlayıcının beyanı), kontrol düzleminin imzasını doğrular (platformun beyanı), ikisinin tutarlı olduğunu görürse sertifikayı verir.

Tasarımın can alıcı noktası bu üçüncü adım: ikisi tek başına yetmez ve birbirini tamamlar. Sağlayıcının beyanı sahtelenemez ama eksik tanımlıdır (rol bir iş yükü değildir). Platformun beyanı iyi tanımlıdır ama tek başına doğrulanamaz. Birlikte: imza iş yükünün meşru biçimde gönderildiğini, URL ise gerçekten o olduğunu söylüyor. Uygulama kimliğini rol adından türetmek kırılgan bir dize eşleştirmesi olacağı için, uygulama kimliği imzalı metadata'dan alınıyor, sağlayıcının cevabı yalnızca doğrulama için kullanılıyor. Bunun bedeli bir ağ turu ve daha sıkı imzalama; kazancı çok daha net bir güven hikâyesi. Bir de fan-out problemi var: bir Spark uygulaması bir sürücü ve binlerce yürütücüden oluşuyor; hepsi ayrı attest ederse binlerce STS çağrısı bir saldırı gibi görünür ve sağlayıcı hız sınırlarına sert bir bağımlılık yaratır.