Das Erstellen oder Aktualisieren von Gateway oder Deployment ist aufgrund fehlender IAM-Policys oder nicht zugänglicher zugehöriger Ressourcen nicht erfolgreich

Erfahren Sie, wie Sie Fehler beim Erstellen und Aktualisieren von Gateways beheben, die durch fehlende IAM-Policys oder nicht zugängliche zugehörige Ressourcen verursacht werden, wenn Sie den API Gateway-Service verwenden.

Eine Anforderung zum Erstellen oder Aktualisieren eines Gateways oder Deployments kann auch dann fehlschlagen, wenn der Anforderungstext gültig ist. Der Fehler kann auftreten, weil der Aufrufer, das Gateway oder eine referenzierte Ressource die Voraussetzungen für Mandant, Compartment, Tag oder zugehörige Ressource nicht erfüllt.

Vor der Fehlerbehebung

Prüfen Sie die folgenden Themen, bevor Sie Policys oder zugehörige Ressourcen aktualisieren:

Problemsymptome

Möglicherweise sehen Sie eines oder mehrere der folgenden Symptome:

  • Gateway konnte nicht erstellt oder aktualisiert werden, obwohl der Anforderungstext gültig ist.

  • Deployment kann nicht erstellt oder aktualisiert werden, obwohl das Zielgateway vorhanden ist.

  • Die Antwort enthält NotAuthorizedOrNotFound.

  • Die Antwort enthält RelatedResourceNotAuthorizedOrNotFound.

  • Der Aufrufer hat einige API-Gateway-Berechtigungen, der Vorgang ist jedoch weiterhin nicht erfolgreich.

  • Die Anforderung verwendet tagbasierte IAM-Bedingungen, und die Autorisierung verläuft weiterhin nicht erfolgreich.

Mögliche Gründe

Erstellungs- und Aktualisierungsvorgänge können mehr als die Policy erfordern, die den Zugriff auf API-Gateway-Ressourcen zulässt. Der Aufrufer muss auch Zugriff auf jede zugehörige Ressource haben, die von der Anforderung verwendet wird.

Häufige Ursachen sind die folgenden Probleme:

  • Dem Aufrufer fehlt manage api-gateway-family im Compartment, das das Gateway oder Deployment enthält.

  • Dem Aufrufer fehlt manage virtual-network-family im Compartment, das das Subnetz oder die zugehörigen Netzwerkressourcen enthält.

  • Das Deployment verwendet ein Feature wie Funktionen, Zertifikate, Certificate Authoritys oder Vault Secrets. Die erforderliche feature-spezifische Policy fehlt jedoch.

  • Die Anforderung referenziert eine Ressource in einem Compartment, das sich außerhalb des Policy-Geltungsbereichs befindet.

  • Eine tagbasierte IAM-Bedingung stimmt nicht mit der Zielressource oder der zugehörigen Ressource überein.

  • Die Anforderung verwendet eine falsche Oracle Cloud-ID (OCID) für das Gateway, das Subnetz, das Zertifikat, das Secret oder eine andere zugehörige Ressource.

Erforderliche Richtlinien überprüfen

Bestätigen Sie zunächst, dass der Aufrufer über die Kern-Policys verfügt, die für das gängigste HTTP-Back-End-Deployment-Szenario gelten.

Für Gateways und Deployments, die HTTP-Backend-Services verwenden, benötigt der Aufrufer in der Regel die folgenden Policys:

Allow group <group-name> to manage api-gateway-family in compartment <apigw-compartment>
Allow group <group-name> to manage virtual-network-family in compartment <network-compartment>

Diese Richtlinien decken nur den gängigen Fall ab. Wenn das Gateway oder Deployment zusätzliche Features verwendet, fügen Sie die Policy hinzu, die mit den einzelnen Features übereinstimmt.

Verwenden Sie die folgenden feature-spezifischen Policys als Ausgangspunkt:

  • Bei einem Deployment, das OCI Functions als Backend-Service verwendet, erteilen Sie Zugriff auf die Funktionsressourcen:

    Allow group <group-name> to use functions-family in compartment <functions-compartment>
  • Gewähren Sie für eine benutzerdefinierte Domain, die ein Certificates-Servicezertifikat verwendet, Zugriff auf Zertifikatszuordnungen:

    Allow group <group-name> to manage certificate-associations in compartment <apigw-compartment>
  • Gewähren Sie für benutzerdefinierte Certificate Authoritys (CAs) oder CA-Bundles in einem Gateway-Truststore Zugriff auf Certificate Authority-Ressourcen:

    Allow group <group-name> to manage certificate-authority-family in compartment <apigw-compartment>
  • Erstellen Sie für Response-Cache-Zugangsdaten oder Authentifizierungsprovider-Zugangsdaten, die in Vaults im Vault-Service gespeichert sind, eine dynamische Gruppe für das Gateway, und erteilen Sie dem Gateway Zugriff zum Lesen des Secret Bundles:

    allow dynamic-group <dynamic-group-name> to read secret-bundles in compartment <secret-compartment>
  • Für den Zugriff auf ein bestimmtes Secret verwenden Sie eine Policy, die den Zugriff auf diese Secret-OCID begrenzt:

    allow dynamic-group <dynamic-group-name> to read secret-bundles in compartment <secret-compartment> where target.secret.id='<secret_ocid>'

Fehlerantwort prüfen

Mit der nicht erfolgreichen Antwort können Sie ermitteln, welcher Vorgang nicht erfolgreich war und welcher Autorisierungsfehler zurückgegeben wurde.

Zeichnen Sie die folgenden Antwortfelder auf:

  • operation_name

  • status

  • code

  • opc-request-id

Für dieses Problem enthält eine typische fehlgeschlagene Antwort die folgenden Werte:

  • operation_name: create_deployment

  • status: 404

  • code: NotAuthorizedOrNotFound

Behalten Sie den Wert opc-request-id bei, damit Sie die nicht erfolgreiche Anforderung mit Diagnose- und Supportdaten korrelieren können.

IAM-Policy-Geltungsbereich prüfen

Ordnen Sie den nicht erfolgreichen Vorgang dem Policy-Geltungsbereich zu, den der Vorgang erfordert.

Prüfen Sie für Vorgänge zum Erstellen oder Aktualisieren des Gateways die folgenden Anforderungen:

  • Der Aufrufer kann API-Gateway-Ressourcen im Compartment verwalten, das das Gateway enthält.

  • Der Aufrufer kann Netzwerkressourcen im Compartment verwalten, das das Subnetz und die zugehörigen Netzwerkressourcen enthält.

Prüfen Sie für Deployment-Erstellungs- oder -Aktualisierungsvorgänge die folgenden Anforderungen:

  • Der Aufrufer kann API-Gateway-Ressourcen im Compartment verwalten, das das Deployment enthält.

  • Der Aufrufer verfügt über jede spezifische Policy, die für die Deployment-Konfiguration erforderlich ist.

Wenn die Anforderung eine benutzerdefinierte Domain, ein CA-Bundle, ein Vault Secret oder ein Functions-Backend verwendet, prüfen Sie die entsprechende featurespezifische Policy.

Compartments und zugehörige Ressourcen prüfen

Eine Anforderung kann auch dann nicht erfolgreich ausgeführt werden, wenn die Haupt-API-Gateway-Policy vorhanden ist. Der Fehler kann auftreten, wenn eine zugehörige Ressource fehlt, nicht zugänglich ist oder außerhalb des Policy-Geltungsbereichs liegt.

Prüfen Sie, ob der Aufrufer gegebenenfalls auf die folgenden Ressourcen zugreifen kann:

  • Das Zielgateway.

  • Das Ziel-Deployment Compartment.

  • Das Subnetz, das vom Gateway referenziert wird.

  • Jede Zertifikatsressource.

  • CA-Bundle oder CA-Ressource.

  • Jeder Functions-Backend-Service.

  • Vault Secret, das vom Gateway oder Deployment-Ablauf benötigt wird.

Prüfen Sie, ob sich jede Ressource in einem Compartment befindet, das von der relevanten Policy abgedeckt wird.

Tag-basierte Policy-Bedingungen prüfen

Wenn der Mandant IAM-Bedingungen basierend auf Tags verwendet, prüfen Sie, ob die Tagbedingung mit dem Aufrufer und den einzelnen Zielressourcen übereinstimmt.

Typische tagbezogene Fehlerpunkte umfassen die folgenden Probleme:

  • Das Anforderungs-Principal-Gruppentag stimmt nicht mit dem Zielressourcentag überein.

  • Der Wert des Zielressourcentags stimmt nicht mit dem Policy-Ausdruck überein.

  • Die Ressource ist vorhanden, aber die Tagbedingung ergibt "false".

  • Ein erforderliches definiertes Tag fehlt in einer zugehörigen Ressource.

Stoppen Sie nicht, nachdem Sie bestätigt haben, dass eine Ressource vorhanden ist. Vergewissern Sie sich, dass die Ressourcentags auch der Policy entsprechen.

Gatewaynetzwerkkonfiguration prüfen

Wenn der nicht erfolgreiche Vorgang ein Gateway erstellt oder aktualisiert, prüfen Sie, ob das Gateway das erwartete Subnetz und den erwarteten Endpunkttyp referenziert.

Prüfen Sie die folgenden Anforderungsfelder:

  • gateway.subnetId

  • gateway.endpointType

Prüfen Sie die folgenden Netzwerkanforderungen:

  • Das Subnetz ist vorhanden.

  • Das Subnetz ist regional.

  • Das Subnetz befindet sich im erwarteten Compartment.

  • Der Endpunkttyp entspricht dem beabsichtigten öffentlichen oder privaten Design.

  • Der Aufrufer ist berechtigt, das Subnetz und die zugehörigen Netzwerkressourcen zu verwenden.

Anforderungskontext validieren

Rufen Sie für ein vorhandenes Gateway die Gatewaydetails direkt ab:

oci api-gateway gateway get --gateway-id <gateway_ocid>

Prüfen Sie mit der Antwort die folgenden Werte:

  • Das Gateway existiert.

  • Das Gateway befindet sich im erwarteten Compartment.

  • Das Gateway verwendet das gewünschte Subnetz.

  • Das Gateway verwendet den erwarteten Endpunkttyp.

Wenn der nicht erfolgreiche Vorgang ein Deployment erstellt, prüfen Sie, ob die Anforderung auf das gewünschte Gateway und Compartment abzielt.

Policy und Ressourcenzugriff korrigieren

Wenden Sie den Fix an, der mit der nicht erfolgreichen Autorisierungs- oder Ressourcenzugriffsprüfung übereinstimmt.

Verwenden Sie die folgenden Fixes als Richtlinie:

  • Fügen Sie manage api-gateway-family hinzu, oder korrigieren Sie es, wenn dem Aufrufer API-Gateway-Ressourcenberechtigungen fehlen.

  • Fügen Sie manage virtual-network-family hinzu, oder korrigieren Sie es, wenn dem Aufrufer keine Subnetz- oder Netzwerkberechtigungen fehlen.

  • Fügen Sie use functions-family hinzu, oder korrigieren Sie es, wenn das Deployment Functions verwendet.

  • Fügen Sie manage certificate-associations hinzu, oder korrigieren Sie es, wenn das Gateway Zertifikatsverknüpfungen verwendet.

  • Fügen Sie manage certificate-authority-family hinzu, oder korrigieren Sie es, wenn das Gateway benutzerdefinierte CAs oder CA-Bundles verwendet.

  • Erstellen oder korrigieren Sie die dynamische Gatewaygruppe und die Policy read secret-bundles, wenn das Gateway Secrets lesen muss.

  • Korrigieren Sie den Compartment-Geltungsbereich, wenn eine Ressource außerhalb des zulässigen Compartments liegt.

  • Korrigieren Sie die Tagwerte oder die IAM-Bedingung, wenn die tagbasierte Autorisierung nicht erfolgreich ist.

  • Korrigieren Sie die falsche OCID in der Anforderung.

Häufige Ursachen-Checkliste

Bevor Sie die Anforderung wiederholen, bestätigen Sie Folgendes:

  • Der Aufrufer kann API-Gateway-Ressourcen verwalten.

  • Der Anrufer kann Netzwerkressourcen verwalten.

  • Der Aufrufer verfügt über die für die Anforderung erforderliche feature-spezifische Policy.

  • Jede dynamische Gatewaygruppe verfügt über den erforderlichen Secret-Zugriff.

  • Alle referenzierten Ressourcen sind vorhanden.

  • Alle referenzierten Ressourcen befinden sich in den erwarteten Compartments.

  • Alle tagbasierten Bedingungen stimmen überein.

  • Die Anforderung verwendet die richtigen OCIDs.

Lösung überprüfen

Nachdem Sie IAM-Policys, Tagbedingungen oder den zugehörigen Ressourcenzugriff korrigiert haben, wiederholen Sie denselben Gateway- oder Deployment-Vorgang.

Prüfen Sie die folgenden Ergebnisse:

  • Der Vorgang gibt nicht mehr NotAuthorizedOrNotFound oder RelatedResourceNotAuthorizedOrNotFound zurück.

  • Das Gateway oder Deployment tritt in den erwarteten Lebenszyklusstatus ein.

  • Die Anforderung ist während der Autorisierung oder Validierung der zugehörigen Ressource nicht mehr erfolgreich.