Çok Hesaplı Kurulum: Hesaplar Arası Çağrılar ve Veri Sınırı

101 ile 104 arasındaki bölümler bu iç servis katmanını tek bir AWS hesabının içinde seçti, protokollerini belirledi, kurdu ve güvenli kıldı. Çok takımlı yapılar orada kalmaz. Takım sınırı genelde bir hesap sınırının üzerine oturur ve bu tek hamle, katmanın altındaki yetkilendirme kurallarını baştan yazar. Aynı hesapta, API’nin resource policy’si ile çağıranın identity policy’si bir OR’dur: ikisinden biri çağrıya izin verebilir. Hesaplar arasında bunlar bir AND’e döner: ikisinin de açıkça izin vermesi gerekir ve sessizlik reddetmek demektir. Bu bölümdeki her şey o dönüşten çıkıyor: seçebileceğiniz iki ağ topolojisi, veri sınırını taşıyan politikalar ve organizasyon seviyesinde hiç yazamayacağınız o tek guardrail. Bu bölüm ölçüm değil, politika işi: POC dağıtılmadı ve aşağıdaki her kural AWS dokümantasyonuna sabitlendi.

Hesaplar arası çağrıda OR, AND’e dönüşür

Private bir API’ye gelen her çağrıda iki politika değerlendirilir: API’ye takılı resource policy ve çağıranın principal’ındaki identity policy. Bu ikisinin nasıl birleştiği, iki tarafın aynı hesabı paylaşıp paylaşmadığına bağlı ve API Gateway’in authorization flow sayfası her iki durumu da açıkça yazıyor (authorization flow).

Aynı hesapta kural gevşektir. AWS’in kendi cümlesi şu: “either the IAM user policies or the resource policy must explicitly allow the caller to proceed”. Tek bir evet yeter.

Hesaplar arası öyle değil. “If the caller and API owner are from separate accounts, both the IAM policies and the resource policy explicitly allow the caller to proceed.” Akılda tutulması gereken cümle ise şu: “If either is silent (neither allow nor deny), cross-account access is denied. This is because cross-account access requires that both the resource policy and the IAM policy or Amazon Cognito user pools authorizer explicitly grant access.”

Hata sessizce gelir, çünkü çağıran tarafta hiçbir şey değişmez. Execution role hâlâ aynı route ARN’i üzerinde execute-api:Invoke veriyordur. Handler hâlâ SigV4 ile imzalıyordur. Bir takım stack’ini kendi hesabına taşımıştır, o kadar. Artık her çağrı 403 dönüyordur. Üstelik iki politikadan hangisinin sessiz kaldığına dair hiçbir ipucu yoktur. Bu, sebebi kodda olmayan bir hata modu ve hesap sınırına özgü.

Hangi politikaların bozulduğu konusunda net olalım, çünkü 103. bölümdeki politika otomatik olarak bunlardan biri değil. Onun Allow statement’ı Principal: "*" kullanıyor; bu açık bir izindir ve hesaplar arasında da geçerlidir. İlk bozulan şey Deny’dır: yeni hesabın endpoint’i aws:SourceVpce listesinde yoktur, dolayısıyla politikanın kendi ikinci statement’ı o hesaptan gelen her çağrıyı reddeder. Sonra bozulan şey, daraltılmış her politikadır. Role ARN’lerini tek tek sayan bir resource policy, güvenlik incelemesinin tam da istediği biçimdir. O ARN’lerin hepsi tek bir hesaba aitse, politika o hesabın dışındaki her principal hakkında sessizdir. Dün sessizlik zararsızdı. Bugün bir reddediştir.

İki topoloji, biri çağıranı gizler

Önce şu endişeyi kaldıralım: yabancı bir endpoint’i politikada anmak eğreti bir çözüm değil, dokümante edilmiş tasarımdır. “Use a resource policy to grant your VPCs and VPC endpoints access to your private APIs. You can grant access to a VPC endpoint in any AWS account” (private API oluşturma). Resource policy sayfası da bir API’ye izin verilebilecek çağıranlar arasında aynı şeyi sayıyor: “Specified virtual private clouds (VPCs) or VPC endpoints (in any account)”. Yani provider’ın politikasındaki aws:SourceVpce değeri, meşru şekilde tüketici hesabın vpce- id’sini taşır.

Buradan ağı kurmanın iki yolu çıkıyor.

Topoloji A, tüketici hesabı başına bir endpoint. Her tüketici hesabı kendi VPC’sini ve kendi execute-api interface endpoint’ini çalıştırır; provider da her tüketicinin endpoint id’sini listeler. Bu, tek hesaplı tasarımın yaslandığı özelliği korur: endpoint id’si, imzayı kimin attığından bağımsız olarak, çağrının hangi hesaptan geldiğini provider’a söyler.

Bu düzen maliyet argümanında bir gedik de açıyor ve gediğin yeri dipnot değil, tam burası. 101. bölüm sabit maliyetin paylaşılmasına dayanıyordu: tek bir interface endpoint, iki AZ üzerinden ayda yaklaşık $14,60 ve VPC’deki bütün private API’lere hizmet ediyor. O paylaşım VPC başına. On iki VPC’li on iki hesap, on iki taban maliyeti öder; tek bir istek gelmeden ayda kabaca $175. İstek başına tarife değişmez ve GB başına işleme ücreti de çarpılmaz, çünkü trafik endpoint’ler arasında bölünür, kopyalanmaz. Çarpılan şey saatlik tabandır ve hesap başına doğrusal olarak çarpılır. Ayrı hesapları hak edecek kadar geniş bir yapı, tam da bunu hisseden yapıdır.

Topoloji B, paylaşılan network VPC’si. VPC’nin ve endpoint’in sahibi bir network hesabıdır; subnet’leri tüketici hesaplarla paylaşır ve onların Lambda’ları o subnet’lerde çalışır. Taban maliyet tekrar tek endpoint’e iner. Bunun ne kazandırdığını, ne götürdüğünü dokümante edilmiş iki gerçek belirliyor. Erişim çalışmaya devam eder: “You can connect to all AWS services that support PrivateLink using a VPC endpoint in a shared VPC” (VPC paylaşımı). Sahiplik ise devrolmaz: “You can’t create, describe, modify, or delete VPC endpoints in subnets that are shared with you” (interface endpoint oluşturma).

Sonucu dikkatle okuyun, çünkü bu bölümün en keskin yeri burası. Topoloji B’de her takımın çağrısı network hesabının endpoint’i üzerinden gelir. aws:SourceVpce hepsi için aynı id’ye çözülür. Anahtar artık çağıran takımı değil, ağı tanımlar. Endpoint id’sinin kimin çağırdığını söylediği varsayımı üzerine kurduğunuz her şey artık hiçbir şey söylemez.

Ağırlığı bu yüzden SigV4 principal’ı taşır. Takım kimliği aws:PrincipalArn, aws:PrincipalAccount veya aws:PrincipalOrgID üzerinden gelmek zorundadır ve bunlar bir AWS_IAM method’unda değerlendirilir. Bu, 104. bölümün son kullanıcının kimliğinden ayırdığı workload kimliğidir. Paylaşılan bir VPC altında sınırın elindeki tek kimlik de odur. Yalnızca ağa dayanan bir sınır burada zaten yeterli değildi. Topoloji B’de ise bir sinyal bile değil.

	Topoloji A: hesap başına endpoint	Topoloji B: paylaşılan network VPC’si
Endpoint saatlik tabanı	tüketici hesabı başına bir tane	network hesabında tek tane
aws:SourceVpce neyi tanımlar	çağıran hesabı	her takım için network hesabını
Endpoint policy sahibi	tüketici takım	network hesabı
Provider’daki vpce listesi	her yeni hesapla büyür	tek id, sabit
Takım kimliği nereden gelir	SigV4 principal, ağ ikinci sinyal	yalnızca SigV4 principal

Varsayılan olarak topoloji A’yı seçin. Ağ sinyalini korur, her tüketici takımın kendi endpoint policy’sinin sahibi olmasını sağlar ve etki alanını birbirinden bağımsız iki boyutta tarif edilebilir tutar. Topoloji B’ye iki durumda geçin. Birincisi: on iki hesaba yayılan endpoint tabanı katmanın faturasına hâkim olmaya başlamışsa. İkincisi: merkezî bir network takımı zaten paylaşılan subnet’lerin sahibiyse ve o tartışma kapanmışsa. Sınırın ağ yarısını daha düşük bir sabit maliyetle takas ediyor, tüketicinin kendi kapısını da başka birinin hesabına taşıyorsunuz. Bu takası bilerek yapın.

Veri sınırını resource policy’ye yazmak

Çerçeveyi AWS’in kendi tanımı kuruyor: “A data perimeter is set of permission guardrails in your AWS environment which help ensure that only your trusted identities are accessing trusted resources from expected networks” (veri sınırları). Üç sınır, bu katmanda üç yer. Kimlik: API’nin resource policy’sinde aws:PrincipalOrgID. Kaynak: aws:ResourceOrgID koşullu bir SCP, böylece bir takımın Lambda’sı organizasyon dışındaki bir API’yi çağıramaz. Ağ: resource policy’de aws:SourceVpce ve ek olarak VPC endpoint policy.

API Gateway resource policy’lerinin condition key tablosu yetkilendirme tipine göre ayrılıyor ve bu ayrım önemli. AWS_IAM yetkilendirmesi altında aws:PrincipalOrgID, aws:PrincipalOrgPaths, aws:PrincipalAccount ve aws:PrincipalArn elinizde. Herhangi bir yetkilendirme tipiyle, yalnızca private API’lerde ise aws:SourceVpc, aws:SourceVpce ve aws:VpcSourceIp var (condition key’ler). Kimlik anahtarlarının elinizde olmasının tek sebebi, 103. bölümün AWS_IAM’i defaultMethodOptions içine koymasıdır. NONE yetkilendirmeli bir method’da koşullayacak principal yoktur. Bir de aws:PrincipalOrgID’nin neye bağlı olduğuna dikkat: bu anahtar “is included in the request context only if the principal is a member of an organization”.

O tabloda olmayanlar daha önemli. aws:SourceOrgID, aws:ResourceOrgID, aws:VpceOrgID, aws:VpceAccount ve aws:VpceOrgPaths yok. Yani bir API Gateway resource policy’si organizasyonumdaki herhangi bir hesaba ait herhangi bir VPC endpoint diyemez. Yalnızca somut endpoint id’lerini tek tek sayabilir. AWS bu anahtarlar konusunda genel olarak da temkinli. Veri sınırları sayfasında (veri sınırları) şu uyarıyı yapıyor: “we recommend that you use aws:VpceOrgID, aws:VpceOrgPaths, and aws:VpceAccount only if all services you want to restrict access to are currently supported. Using these condition keys with unsupported services can lead to unintended authorization results”.

Dolayısıyla politika işi ikiye böler: kimlik org anahtarından, ağ ise bir listeden gelir.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowOrgPrincipalsOnOneRoute",
      "Effect": "Allow",
      "Principal": "*",
      "Action": "execute-api:Invoke",
      "Resource": ["execute-api:/v1/POST/orders"],
      "Condition": {
        "StringEquals": { "aws:PrincipalOrgID": "o-abcd1234" }
      }
    },
    {
      "Sid": "DenyUnexpectedNetworks",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "execute-api:Invoke",
      "Resource": ["execute-api:/*"],
      "Condition": {
        "StringNotEquals": {
          "aws:SourceVpce": [
            "vpce-0a1b2c3d4e5f60000",
            "vpce-0a1b2c3d4e5f60001",
            "vpce-0a1b2c3d4e5f60002"
          ]
        }
      }
    }
  ]
}

Bunu tek bir kural değil, birbirinden bağımsız iki kapı olarak okuyun. Allow, organizasyondaki her principal’ı tek bir route’a kabul eder: kimlik sınırı budur ve hesaplar arası AND’in resource policy tarafını evete çeviren şey de budur. Deny, bilinen bir endpoint’ten gelmeyen her şeyi reddeder: ağ sınırı budur. İki statement birbirinin işini yapamaz. İkincisinin organizasyona koşullanmış bir ifade değil de elle güncellenen bir liste olmasının sebebi, tam olarak yukarıdaki eksiktir.

O liste, topoloji A’nın bakım maliyetidir. Her yeni tüketici hesabı bir id ekler ve id eklemek provider hesabında bir deploy demektir. On iki hesap demek, on iki satır demek; on üçüncüsü geldiğinde de bir değişiklik yönetimi adımı. Topoloji B bu listeyi tek ve sabit bir id’ye indirir. Cazibesinin önemli bir kısmı da budur. Yeter ki o tek id’nin artık size ne söylemediğini unutmayın.

Endpoint policy tüketicinin kendi kapısı

AWS iki politikanın işini net ayırıyor: “VPC endpoint policies can be used together with API Gateway resource policies. The API Gateway resource policy specifies which principals can access the API. The endpoint policy specifies who can access the VPC and which APIs can be called from the VPC endpoint. Your private API needs a resource policy but you don’t need to create a custom VPC endpoint policy” (endpoint policy’ler).

Değerlendirme sırası sabit, endpoint’in ne görebildiği de öyle: “The identity of the invoker is evaluated based on the Authorization header value. The VPC endpoint policy is evaluated first, and then API Gateway evaluates the request, based on the type of authorization configured on the method request.” Geçerli bir SigV4 imzası varsa çağıran, doğrulanmış IAM kimliğidir. Authorization header’ı yoksa veya içinde bir bearer token varsa çağıran anonimdir. Yani Principal tabanlı bir endpoint policy ancak method AWS_IAM veya NONE iken iş görür. Route’a JWT taşıyan bir Lambda authorizer koyarsanız, endpoint policy’nin principal koşulları hiçbir şeyle eşleşmez.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "OrgOnlyApisFromOrgPrincipals",
      "Effect": "Allow",
      "Principal": "*",
      "Action": "execute-api:Invoke",
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "aws:ResourceOrgID": "o-abcd1234",
          "aws:PrincipalOrgID": "o-abcd1234"
        }
      }
    }
  ]
}

Asimetriye dikkat: aws:ResourceOrgID burada çalışıyor ve API Gateway resource policy condition key tablosunda hiç yok. Endpoint policy’yi API Gateway değil PrivateLink değerlendiriyor, dolayısıyla farklı bir condition key yüzeyi görüyor. Bu kapının yazılmaya değer olmasının büyük bir sebebi de o asimetri.

Üstelik bu, tüketicinin kendi hesabının kontrol ettiği tek kapı. Bir resource policy tek bir API’yi korur ve o API’nin sahibi takım tarafından yazılır. Endpoint policy’yi ise endpoint’in sahibi takım yazar ve hiçbir resource policy’nin ifade edemeyeceği bir şey söyleyebilir: benim fonksiyonlarım şu API’leri çağırabilir, başkasını değil; ve yalnızca organizasyonumun içinde. Bu, çağrılan tarafın değil, çağıranın etki alanı hakkında bir cümledir. Resource alanını * yerine bir API ARN listesine daraltın; o hesabın sahip olduğu her iç bağımlılığın allowlist’i tek dosyada elinize geçer.

Üç kısıt bu politikayı şekillendiriyor (endpoint policy kuralları). Politika bir Principal alanı içermek zorunda. Boyutu, boşluklar dahil 20.480 karakteri geçemiyor. Bir de sistem tarafından üretilen kimlikleri referans alan condition key’lerde, örneğin aws:SourceVpc’de, wildcard çalışmıyor. Son kural, ağ sınırının neden önek eşlemesiyle değil de tek tek sayılarak yazıldığının bir sebebi daha. Karakter sınırı ise tek tek sayılan ARN listesini eninde sonunda koşul tabanlı bir politikaya geri iten şeydir.

Topoloji B’nin bir sonucu da buraya düşüyor ve bunu kaçırmak maliyet sonucunu kaçırmaktan daha kolay. Endpoint paylaşılan bir network VPC’sinde duruyorsa tüketici bu politikayı hiç yazamaz: “You can’t create, describe, modify, or delete VPC endpoints in subnets that are shared with you”. Tüketicinin kendi kapısı, network takımına açılan bir talep kaydına dönüşür.

Merkezden zorlayamayacaklarınız

Refleks, guardrail’i AWS Organizations’a itmektir. Bu katmanda o refleksin yarısı yanlış.

Resource control policy’ler execute-api’yi kapsamıyor. RCP’lerin desteklediği servis listesinde yok (RCP’ler). AWS’in bu durum için verdiği talimat da net ve RCP sayfasında değil, veri sınırları sayfasında duruyor (veri sınırları): “To enforce data perimeter controls on resources that are currently not supported by RCPs, you can use resource-based policies that are attached to resources directly.”

Yani organizasyonumun dışındaki hiçbir principal API’lerimi çağıramaz diyen, organizasyon seviyesinde bir ifade yok. API başına yazılan resource policy, derinlemesine savunma için eklenen bir ekstra değil. Bu API’lerin kimlik ve ağ sınırının yazılabileceği tek yer orası ve bu, onun statüsünü yükseltiyor: eksik bir resource policy bir sertleştirme boşluğu değil, sınırın tamamının yokluğudur. Platform takımının işi, her private API’nin bir resource policy taşıdığını garanti etmektir. Bu garanti de organizasyonda değil, pipeline’da durur. RestApi politikasız kaldığında synth’i düşüren bir CDK aspect’i yazabilirsiniz; platform takımının deploy etmediği bir hesapta bunu işaretleyen bir Config kuralı da aynı işi görür.

Kimlik tarafı ise merkezden çalışıyor. Bir SCP, bir takımın principal’larının organizasyon dışındaki bir API’yi çağırmasını engelleyebilir; veri sınırı modelindeki kaynak sınırı budur:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyApiCallsOutsideOrg",
      "Effect": "Deny",
      "Action": "execute-api:Invoke",
      "Resource": "*",
      "Condition": {
        "StringNotEquals": { "aws:ResourceOrgID": "o-abcd1234" }
      }
    }
  ]
}

Bunu aws:SourceVpce üzerinde bir ağ koşuluyla genişletebilirsiniz; anahtarın bulunmadığı isteklerin yanlışlıkla yakalanmaması için StringNotEqualsIfExists kullanın. Anahtar yalnızca istek bir VPC endpoint’ten geçtiğinde dolar; IfExists biçiminin orada opsiyonel olmamasının sebebi de bu.

Bir eksik daha, açıkça söylüyorum, çünkü yanlış bir güvence bilinen bir boşluktan kötüdür. IAM Access Analyzer, API Gateway resource policy’lerini analiz etmiyor. execute-api ne external-access ne de internal-access destekli kaynak listesinde geçiyor (Access Analyzer kaynakları). Fazla geniş bir private API politikası düşünün: wildcard principal taşıyor, organizasyon koşulu yok ve deny listesi sessizce eşleşmeyi bırakmış. Organizasyonunuzun tam bu iş için aldığı araç onu işaretlemeyecek. Onu code review’da yakalayın ya da kontrolü kendiniz yazın.

API’ye kalıcı bir ad verin

API id’si bir adres değildir. API’yi yeniden oluşturun, abc123.execute-api.us-east-1.amazonaws.com başka bir şeye döner. Her çağıranın environment değişkeni, her tüketicinin IAM politikasındaki her route ARN’i ve o id’yi anan her endpoint policy artık yanlıştır. Hesaplar arasında o çağıranlar, grep edemeyeceğiniz repo’ların içindedir.

Private custom domain name’ler bunu kapatıyor. “You can create a custom domain name for your private APIs. Use a private custom domain name to provide API callers with a simpler and more intuitive URL” (private custom domain name’ler). Çok hesaplı bir yapı için işe yarayan bir ayrıntı da şu: “Custom domain names for private APIs don’t need to be unique across multiple accounts.” Böylece sözleşme orders.internal.example.com olur ve API id’si onun arkasında bir uygulama detayına iner.

Kurulumda public bir custom domain’den daha çok parça var ve hepsini başlamadan bilmekte fayda var. Provider’ın bir ACM sertifikasına ihtiyacı olur: RSA-2048 ya da ECDSA P-256 veya P-384; wildcard sertifikalara izin var ama wildcard domain adlarına yok. TLS bir ayar düğmesi değil: “You can’t set a minimum TLS version for your private custom domain name. All private custom domain names have the security policy of TLS-1-2.” Tüketicinin ise kendi VPC endpoint’i ile domain arasında bir domain name access association kurması gerekir. AWS bunun için “takes about 15 minutes to be ready” diyor. Adın çözülmesi için de bir Route 53 private hosted zone gerekir. Sınır da katı: “You can’t send traffic from a private custom domain name to a public API.”

Yetkilendirme zinciri bir halka uzuyor ve tasarım dokümanına yapıştırılacak cümle şu: “You must create a separate resource policy for your private API and for your private custom domain name. To invoke a private custom domain name, an API consumer needs access from the private custom domain name resource policy, the private API resource policy, and any VPC endpoint policies or authorization on the private API.” Üç değil, dört şeyin aynı fikirde olması gerekiyor. Yenisini unutmak kolay, çünkü bir servisi değil bir adı koruyor.

Paylaşım da geçici bir çözüm değil, birinci sınıf bir akış. “We recommend that you use AWS RAM to share your private custom domain name” ve organizasyonun içinde el sıkışma adımı ortadan kalkıyor: “If the API provider and the API consumer are in the same organization using AWS Organizations, the resource share between provider and consumer is automatically accepted” (domain name access association’lar).

Takası dürüstçe adlandıralım. Domain adı sabittir ama domain’in ARN’i üretilmiş bir domain-name-id eki taşır. Domain’i yeniden oluşturun, o ARN değişir. Bu da değişim yükünü her çağıranın konfigürasyonundan alıp RAM paylaşımına ve onu referans alan endpoint policy’lere taşır. Yeniden oluşturmanın yükü yok olmaz, yer değiştirir. Daha az sayıda şeye ve daha az takıma düşer; asıl satın aldığınız iyileşme de bu yoğunlaşmadır.

Adresleme hakkında iki gerçek daha buraya ait, çünkü paylaşılan endpoint’i doğrudan ilgilendiriyorlar. AWS’in best practice’i şu: “Use a single VPC endpoint to access multiple private APIs” ve “Turn on private DNS for your VPC. When you turn on private DNS for your VPC, you can invoke your API within a VPC without passing the Host or x-apigw-api-id header” (private API’ler). Tek endpoint’in arkasındaki çok sayıda API çakışmaz, çünkü API id’si hostname’in içindedir ve endpoint onları header olmadan ayırt eder. İyi haber budur ve paylaşılan endpoint’i baştan uygulanabilir kılan da odur.

Tuzak aynı sayfada: “If you turn on private DNS, you can’t access the default endpoint for public APIs.” execute-api için private DNS’i açık olan bir VPC, public API Gateway endpoint’lerine varsayılan hostname’leri üzerinden artık ulaşamaz. Aynı fonksiyonlar API Gateway üzerinde barınan üçüncü parti bir API’yi de çağırıyorsa o çağrı çalışmayı bırakır. Dokümante edilmiş çözüm, private DNS’i kapatıp her private API için bir private hosted zone oluşturmaktır; bu da tüketici hesapta daha çok hareketli parça demektir. Anahtarı çevirmeden önce bakın, sonra değil.

Sık yapılan hatalar

1. Bir takım kendi hesabına taşındığında tek hesaplı resource policy’nin olduğu gibi geçerli kalacağını varsaymak. Hesaplar arası çağrı iki tarafta da açık izin ister, yeni endpoint id’sinin ağ listesine girmesi gerekir ve aynı hesaptaki role ARN’lerini sayan her politika artık çağıran hakkında sessizdir.
2. Paylaşılan bir network VPC’sinde aws:SourceVpce’yi takım kimliği olarak kullanmak. Her takım aynı endpoint id’siyle gelir; anahtar ağı tanımlar, başka bir şeyi değil. Takım kimliği SigV4 principal’ından gelir.
3. Organizasyona ölçeklenen bir ağ anahtarı beklemek. API Gateway resource policy condition tablosunda aws:VpceOrgID yok; endpoint listesi tek tek sayılır ve elle bakılır.
4. RCP’nin execute-api’yi koruyacağını beklemek. Desteklenen bir servis değil; sınırın var olduğu tek yer API başına resource policy’dir.
5. Takıma, fazla geniş bir API resource policy’yi IAM Access Analyzer’ın yakalayacağını söylemek. API Gateway her iki analyzer’da da desteklenen bir kaynak tipi değil.
6. Principal tabanlı bir endpoint policy’nin arkasına bearer token’lı bir authorizer koymak. SigV4 olmadan çağıran anonimdir ve principal koşulları hiçbir zaman eşleşmez.
7. Fonksiyonları public API Gateway API’lerini de çağıran bir VPC’de private DNS’i açmak. Varsayılan public endpoint o VPC’den çözülmeyi bırakır.
8. API id’sini hesaplar arasında sabit bir adres saymak. Private custom domain name kullanın ve domain’i yeniden oluşturmanın RAM paylaşımını ve endpoint policy’leri hâlâ çalkaladığını unutmayın.

Hesaplar arası kurulum, tek hesaplı tasarımın bir varyantı değil. Aynı sözdizimini giymiş farklı bir yetkilendirme kuralı. Varsayılan üç koşulda geçerli. Provider’ın resource policy’si kimlik tarafında organizasyonu adıyla anıyor, ağ tarafında endpoint id’lerini sayıyor. Her tüketici hesabı kendi endpoint’inin ve kendi endpoint policy’sinin sahibi. Ve çağıranlar API’ye üretilmiş bir id ile değil, private custom domain name ile ulaşıyor. Hesap başına düşen endpoint tabanı, endpoint id’sinin size söylediği şeyden ağır basmaya başladığında paylaşılan network VPC’sine geçin ve kimliğin artık tamamen SigV4’ün işi olduğunu kabul edin. Üretilecek ilk çıktı listedir: bugün hangi hesap hangi API’yi çağırıyor. O liste, resource policy’lerinizin birazdan ihtiyaç duyacağı sayımdır ve uzunluğu, topoloji B lehine veya aleyhine argümanın kendisidir.

Katman artık hesaplara yayılıyor ve sınır yazıya döküldü. Tasarım henüz gerçek trafikle karşılaşmadı. 106. bölüm, katman o trafiği taşımaya başladığında nelerin bozulduğunu anlatıyor: artık ön kapınızla paylaştığı throttle kovası, kaldırdığı retry’lar ve elden çıkardığı döngü dedektörü.

Kaynaklar

• API Gateway authorization flow - Bu bölümün omurgası: aynı hesapta OR, hesaplar arasında iki politikanın da açıkça izin vermesi şartı ve “if either is silent… cross-account access is denied”.
• Create a private API - “You can grant access to a VPC endpoint in any AWS account.” Resource policy’de yabancı bir endpoint’i anmak, amaçlanan tasarımdır.
• API Gateway resource policies - Bir API’ye izin verilebilecek çağıranlar arasında “Specified virtual private clouds (VPCs) or VPC endpoints (in any account)” maddesini sayar.
• Condition keys for API Gateway resource policies - Desteklenen iki liste ve endpoint id’lerini tek tek saymaya zorlayan eksikler: aws:VpceOrgID ve benzerleri.
• VPC endpoint policies for private APIs - İki politika arasındaki iş bölümü, değerlendirme sırası ve Principal tabanlı bir endpoint policy’yi bearer token’ın arkasında işlevsiz bırakan anonim çağıran kuralı.
• Control access to VPC endpoints using endpoint policies - Bir endpoint policy’nin üç kısıtı: zorunlu Principal alanı, boşluklar dahil 20.480 karakter sınırı ve sistem tarafından üretilen kimlikleri referans alan condition key’lerde wildcard kullanılamaması.
• Private REST APIs in API Gateway - Çok sayıda private API için tek endpoint, Host header ihtiyacını kaldıran private DNS ve onunla gelen public endpoint tuzağı.
• Private custom domain names - Sertifika tipleri, sabit TLS-1-2 politikası ve bir tüketicinin domain üzerinden çağırmak için sağlaması gereken üç politikalık zincir.
• Domain name access associations - AWS RAM paylaşım akışı, organizasyon içinde otomatik kabul ve association’ın hazır olması için gereken yaklaşık 15 dakika.
• Create an interface VPC endpoint - “You can’t create, describe, modify, or delete VPC endpoints in subnets that are shared with you.” Endpoint policy’yi network hesabına taşıyan cümle.
• VPC sharing service behavior - PrivateLink’in paylaşılan bir VPC’den çalıştığını doğrular; topoloji B’yi baştan mümkün kılan şey budur.
• Data perimeters on AWS - Kimlik, kaynak ve ağ sınırı modeli; ayrıca RCP’lerin ulaşamadığı yerde resource-based policy’lere dönme talimatı.
• Resource control policies - execute-api’nin bulunmadığı desteklenen servis listesi; hiçbir org guardrail’inin bu API’leri kapsayamamasının sebebi.
• IAM Access Analyzer supported resource types - API Gateway hem external-access hem internal-access listesinde yok. Fazla geniş bir API resource policy’yi yakalamasını beklemeyin.