Logo
AWS FinOps agenci AI IAM

AWS FinOps agent: AccessDenied, gdy agent próbuje zadziałać na podstawie wniosku o kosztach

Napraw AccessDenied, gdy agent FinOps na AWS próbuje zadziałać na podstawie wniosku o kosztach (zatrzymać instancję, usunąć wolumen, kupić zobowiązanie), oddzielając obserwację w modelu read-first od zawężonej, kontrolowanej przez człowieka ścieżki zapisu.

Jerzy Kopaczewski ·
Twój agent FinOps czyta dane o kosztach i zużyciu bez zarzutu: streszcza rachunek, oznacza bezczynne zasoby, wychwytuje anomalie. Jednak w chwili, gdy chce zadziałać na podstawie wniosku (zatrzymać instancję, usunąć niepodłączony wolumen, kupić Savings Plan), kończy się to błędem AccessDenied. W większości przypadków nie jest to usterka, którą naprawia się poszerzeniem uprawnień. To celowy projekt read-first działający zgodnie z zamiarem, a właściwą odpowiedzią jest świadomie ograniczona, kontrolowana przez człowieka ścieżka zapisu, a nie szerokie nadanie uprawnień.

Ten runbook dotyczy błędów dostępu IAM, gdy agent FinOps przechodzi od obserwacji do działania. Jak agent składa się w całość (obserwuje, rekomenduje, działa) i dlaczego liczą się stojące za nim runbooki, opisaliśmy w artykule AWS FinOps agent: koszt, funkcje i runbooki. W temacie bezpiecznego projektu warstwy zapisu i zatwierdzeń umów konsultację.

Objawy

An error occurred (AccessDeniedException) when calling the <Operation>
operation: User: arn:aws:sts::...:assumed-role/finops-agent-role is not
authorized to perform: <action> (np. ec2:StopInstances,
ec2:DeleteVolume, savingsplans:CreateSavingsPlan) on resource: <arn>
because no identity-based policy allows the <action> action

Widoczny wpływ:

  • Kroki odczytu i analizy agenta udają się bez problemu, Cost Explorer, zapytania do CUR i rekomendacje renderują się poprawnie
  • Zawodzi wyłącznie krok działania i tylko dla operacji zapisu lub zmiany
  • Błąd jest powtarzalny (każdy zapis odrzucony), a nie sporadyczny, co wskazuje na granicę polityki, a nie błąd przejściowy

Przyczyna

Dobrze zbudowany agent FinOps dostaje IAM w modelu read-first: szeroki dostęp do odczytu danych o kosztach i zużyciu oraz domyślnie niewielki dostęp do zapisu lub brak takiego dostępu. To właściwa postawa. Agent, który widzi rachunek, jest użyteczny, a agent, który może po cichu zmieniać infrastrukturę, by ten rachunek obniżyć, jest ryzykiem produkcyjnym. Dlatego AccessDenied przy akcji zwykle oznacza, że projekt osiągnął granicę, a nie że coś jest źle skonfigurowane.

Błąd sprowadza się do jednej z trzech sytuacji, a tylko jedna z nich to zwykła luka w uprawnieniach:

  1. Read-first zgodnie z projektem (przypadek najczęstszy). Rola wykonawcza celowo pomija akcje zapisu. Agent powinien rekomendować tę zmianę do zatwierdzenia przez człowieka, a nie ją wykonywać. Rozwiązaniem jest kontrolowana ścieżka zapisu, a nie szersza rola.
  2. Faktycznie zamierzona akcja bez adekwatnego uprawnienia. Zdecydowałeś, że ta konkretna, ograniczona akcja ma być zautomatyzowana (na przykład zatrzymywanie instancji oznaczonych auto-stop: true wedle harmonogramu). Pojedyncza akcja po prostu nie została jeszcze dodana do roli.
  3. Niedopasowanie tożsamości lub granicy. Permissions boundary, SCP albo niewłaściwa przyjęta rola blokują akcję, mimo że polityka oparta na tożsamości wygląda poprawnie.

Częste przyczyny:

  • Akcja zapisu nigdy nie nadana: rola ma zakres odczytu ce:*, cur:*, cloudwatch:Get*, ale nie ec2:StopInstances, ec2:DeleteVolume czy savingsplans:CreateSavingsPlan
  • Permissions boundary ogranicza rolę: akcja jest w polityce, lecz odrzuca ją boundary lub SCP w Organizations
  • Działa niewłaściwa rola: agent przyjął swoją rolę do odczytu dla kroku, który miał przyjąć osobną, zawężoną rolę do zapisu
  • Zbyt wąski zasób lub warunek: akcja jest dozwolona, ale ARN zasobu albo klucz warunku (tag, region) nie pasuje do celu

Naprawa

Krok 1: Rozstrzygnij, czy ta akcja w ogóle ma być automatyczna

Zanim dotkniesz IAM, odpowiedz na pytanie o nadzór: czy agent ma wykonywać tę akcję samodzielnie, czy rekomendować ją człowiekowi? Usuwanie wolumenów, zatrzymywanie instancji i kupowanie wieloletnich zobowiązań niosą realny blast radius. Domyślną odpowiedzią dla wszystkiego, co istotne, jest rekomendacja z kontrolą człowieka, co oznacza, że AccessDenied jest poprawny, a rozwiązanie leży w przepływie zatwierdzeń, a nie w roli.

Przejdź do kroku 2 tylko wtedy, gdy świadomie uznałeś, że tę konkretną, ograniczoną akcję można bezpiecznie zautomatyzować.

Krok 2: Nadaj pojedynczą akcję, ograniczoną do dokładnego zasobu

Jeśli akcja jest faktycznie zamierzona, dodaj tylko ją, nigdy wildcarda, i ogranicz ją przez ARN zasobu oraz, gdzie to możliwe, warunek tagu lub regionu, aby agent mógł dotykać wyłącznie zasobów wyraźnie do tego wyznaczonych.

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "FinOpsAgentScopedStop",
    "Effect": "Allow",
    "Action": "ec2:StopInstances",
    "Resource": "arn:aws:ec2:*:111122223333:instance/*",
    "Condition": {
      "StringEquals": { "aws:ResourceTag/finops-agent-managed": "true" }
    }
  }]
}

Lepiej przygotować osobną wąską rolę do zapisu, którą agent przyjmuje tylko dla zatwierdzonej akcji, pozostawiając domyślną rolę wykonawczą w trybie tylko do odczytu. Nie dodawaj zakresu zapisu do szerokiej roli do odczytu.

Krok 3: Sprawdź boundary lub SCP, jeśli nadanie nie zadziałało

Jeśli polityka oparta na tożsamości zezwala już na akcję, a ta nadal jest odrzucana, oznacza to, że rolę ogranicza permissions boundary lub SCP w Organizations. Potwierdź efektywne uprawnienia, zamiast czytać samą przypiętą politykę.

# Zasymuluj dokładną akcję na dokładnym zasobie, jako rola agenta
aws iam simulate-principal-policy \
  --policy-source-arn arn:aws:iam::111122223333:role/finops-agent-write-role \
  --action-names ec2:StopInstances \
  --resource-arns arn:aws:ec2:eu-west-1:111122223333:instance/i-0abc123 \
  --region us-east-1

Jeśli symulacja pokazuje implicitDeny z nazwą boundary lub SCP, rozwiązanie leży na tej warstwie, a nie w polityce roli.

Krok 4: Przesuń akcję pod kontrolę człowieka

Dla każdej akcji o produkcyjnym blast radius nadanie powinno znaleźć się za krokiem zatwierdzenia, tak aby agent proponował, a człowiek potwierdzał. To wzorzec z artykułu o agencie FinOps: agent obserwuje i analizuje, runbook koduje kontrole bezpieczeństwa, a człowiek zatwierdza wszystko, co zmienia infrastrukturę. Agent podłączony prosto do uprawnień zapisu pomija dokładnie ten krok, który chroni Cię przed incydentem.

Weryfikacja

Potwierdź, że agent potrafi wykonać jedną zatwierdzoną akcję na wyznaczonym zasobie i nadal nie może dotknąć niczego innego.

# Powinno się teraz udać dla wyraźnie otagowanego, wyznaczonego zasobu
aws sts get-caller-identity --region us-east-1
# Potwierdź, że działa rola do zapisu, a następnie wykonaj zatwierdzoną akcję
# na zasobie testowym z tagiem finops-agent-managed=true i sprawdź sukces.

# Kontrola negatywna: ta sama akcja na zasobie BEZ tagu musi być nadal odrzucana
aws iam simulate-principal-policy \
  --policy-source-arn arn:aws:iam::111122223333:role/finops-agent-write-role \
  --action-names ec2:StopInstances \
  --resource-arns arn:aws:ec2:eu-west-1:111122223333:instance/i-0notmanaged \
  --region us-east-1
# Oczekuj: implicitDeny, zakres się trzyma, agent dotyka tylko wyznaczonych zasobów.

Oczekiwany stan końcowy: agent czyta dane o kosztach jak wcześniej, wykonuje jedną zatwierdzoną akcję na wyznaczonych zasobach przez kontrolowaną ścieżkę z bramką zatwierdzenia i nadal ma odrzucany każdy inny zapis, a postawa read-first pozostaje nienaruszona.

Powiązane