View a markdown version of this page

Mit gezielten Aktionen arbeiten - AWS DevOps Agentin
Beispiel: Ausführung eines Maßnahmenplans, der sich aus einer Untersuchung ergibtVoraussetzungenAktivierung gezielter Aktionen in einem AgentenbereichRegistrierung einer erhöhten Rolle für AWS KontoOperationen, die der Agent nicht ausführen wirdTools zur Kategorisierung von Drittanbieter-IntegrationenGezielte Aktionen genehmigenÜberwachung und PrüfungFehlerbehebung

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Mit gezielten Aktionen arbeiten

AWS DevOps Der Agent kann auf Ihre verbundenen Dienste und AWS Konten reagieren, wenn ein Betreiber ihn ausdrücklich dazu auffordert. Beispielsweise kann ein Betreiber, der einen Vorfall untersucht, den Agenten bitten, den Status einer Ressource zu beschreiben. Mit den entsprechenden Genehmigungen und Genehmigungen kann der Betreiber den Agenten auch bitten, ein Problem direkt zu beheben.

Der Agent unterscheidet zwei Arten von Vorgängen:

  • Read-only Aktionen: Operationen, bei denen nur Informationen aus Ihren verbundenen Diensten und AWS Konten gelesen werden. Diese sind standardmäßig verfügbar.

  • Gezielte Aktionen: Operationen, die Ressourcen erstellen, ändern oder auf andere Weise verändern. Gezielte Aktionen sind erhöht: Sie sind standardmäßig deaktiviert und erfordern ein ausdrückliches mehrstufiges Opt-In sowie eine Genehmigung durch den Operator pro Aktion.

Das Sicherheitsmodell für gezielte Aktionen ist eine tiefgreifende Verteidigung. Die Funktion ist standardmäßig deaktiviert. Sie entscheiden sich auf unabhängigen Ebenen: Sie aktivieren gezielte Aktionen im Agentenbereich, registrieren eine IAM-Rolle pro Konto und kategorisieren jedes Tool. Jede gezielte Aktion erfordert die Zustimmung des Bedieners zum Zeitpunkt der Ausführung. Jede Genehmigung und die daraus resultierende Aktion sind dem genehmigenden Bediener zuzuschreiben. AWS CloudTrail

Bei Aktionen gegen AWS Ressourcen durchsetzt der Agent unabhängig von den von Ihnen erteilten Berechtigungen seine eigenen Richtlinien für die von ihm aufgerufenen AWS SDK-Operationen. Weitere Informationen zu diesen Schutzmaßnahmen finden Sie unter Operationen, die der Agent nicht ausführen wird.

Beispiel: Ausführung eines Maßnahmenplans, der sich aus einer Untersuchung ergibt

Dieses Beispiel zeigt die Gesamterfahrung für ein gängiges Szenario. Ein Betreiber überprüft den Plan zur Schadensbegrenzung einer Untersuchung oder eine Verbesserungsempfehlung. Der Operator bittet den Agenten, den Vorgang durchzuführen, ohne das Gespräch zu verlassen.

Ein Site Reliability Engineer (SRE) bittet den Agenten im Chat, nach Konten zu suchen, von denen aus SSH-Zugriff möglich ist0.0.0.0/0. Der Agent findet eine Sicherheitsgruppe mit einer Open-Ingress-Regel. Es wird eine Abhilfemaßnahme empfohlen: Beschränken Sie die Regel auf den internen Netzwerkbereich. Der Betreiber weist den Agenten an, sie anzuwenden.

  1. Der Agent schlägt die Änderung vor. Der Agent überprüft die Sicherheitsgruppe (eine schreibgeschützte Aktion). Er schlägt vor, die 0.0.0.0/0 Regel zu entfernen und eine Regel hinzuzufügen, die auf den internen Netzwerkbereich beschränkt ist. In dem Vorschlag werden der genaue API-Betrieb, die Zielsicherheitsgruppe, eine Risikobewertung, der erwartete Explosionsradius und Rollback-Schritte festgelegt.

  2. Der Betreiber prüft und genehmigt. Die Operation verändert eine Ressource, es handelt sich also um eine gezielte Aktion. Die Genehmigungsanforderung zeigt den Vorgang und seine Parameter. Der Bediener kann Parameter anpassen, z. B. 10.0.0.0/8 auf die Anfrage 10.1.0.0/16 einschränken oder sie ablehnen. Ohne ausdrückliche Genehmigung wird nichts ausgeführt.

  3. Der Agent wird unter bestimmten Anmeldeinformationen ausgeführt. Der Agent verwendet Anmeldeinformationen aus der registrierten erhöhten Rolle. Die Anmeldeinformationen beziehen sich auf den genehmigten Vorgang und die genehmigte Ressource und sind für ein begrenztes Fenster gültig. Die Genehmigung kann nicht für einen anderen Vorgang oder eine andere Ressource wiederverwendet werden.

  4. Die Aktion ist vollständig überprüfbar. Der Anruf wird AWS CloudTrail mit einer Quellidentität angezeigt, die ihn dem genehmigenden Operator zuordnet. CloudTrail zeichnet die genehmigten und ausgeführten Parameter auf.

Der gleiche Ablauf gilt, wenn Sie einen Plan zur Schadensbegrenzung oder eine Verbesserungsempfehlung einer Untersuchung prüfen und den Agenten bitten, einen Schritt auszuführen. Der Agent wandelt den Schritt in einen spezifischen Arbeitsvorschlag um und bittet um Genehmigung, bevor er tätig wird.

Der gleiche Ablauf gilt für Tools von Drittanbietern. Ein Operator, der das Alarmgeräusch analysiert, fordert den Agenten auf, den Schwellenwert für eine Grafana-Alarmregel zu erhöhen. AWS DevOps Der Agent stuft dieses Tool als mutierend ein, und das Team hat es aktiviert, um erhöhten Zugriff auf die Integration zu gewähren. Der Agent stellt eine Genehmigungsanfrage, in der das Tool und die Parameter aufgeführt sind. Nach der Genehmigung ruft der Agent das Tool über die Integration auf. AWS DevOps Der Agent ordnet die Aktion dem genehmigenden Operator zu.

Bevor gezielte Aktionen aktiviert werden oder wenn keine erhöhte Rolle registriert ist, prüft der Agent dennoch anhand von Aktionen, die nur gelesen werden können. Es bietet manuelle Schritte zur Problembehebung anstelle einer ausführbaren Änderung.

Voraussetzungen

Bevor Sie gezielte Aktionen verwenden können, benötigen Sie Folgendes:

  • Ein Agentenbereich in AWS DevOps Agent mit mindestens einer Verknüpfung zu einem AWS Konto oder einer unterstützten Drittanbieter-Integration.

  • Berechtigungen zur Aktualisierung des Agentenbereichs und seiner Verknüpfungen, z. B. über die AWS DevOps Agentenkonsole oder API.

  • Berechtigungen im Zielkonto zur Erstellung einer IAM-Rolle und zur Definition ihrer Vertrauens- und Berechtigungsrichtlinien für gezielte Aktionen gegen AWS Konten.

  • iam:PassRolearn:aws:iam::<account-id>:role/*In Ihrem eigenen Konto sind Sie berechtigt, die Rolle in der Assoziation zu registrierenaidevops.amazonaws.com, wenn der Bedingungsschlüssel auf iam:PassedToService gesetzt ist. Ein umfassenderer iam:PassRole Zuschuss erfüllt ebenfalls diese Anforderung.

  • Zugriff auf den Agentenbereich für die Betreiber, die gezielte Aktionen genehmigen.

Aktivierung gezielter Aktionen in einem Agentenbereich

Gezielte Aktionen müssen im Agentenbereich aktiviert werden, bevor eine andere Konfiguration mit erhöhten Rechten wirksam wird. Dies ist die primäre Steuerung für gezielte Aktionen. Wenn es deaktiviert ist, haben erhöhte Rollenregistrierungen und erhöhte Tool-Opt-ins keine Wirkung. Versuche, eine Konfiguration mit erhöhten Rechten zu registrieren, werden möglicherweise abgelehnt.

Aktivieren von in der Konsole

  1. Öffnen Sie die AWS DevOps Agentenkonsole.

  2. Wählen Sie Ihren Agentenbereich.

  3. Navigieren Sie zu den Einstellungen für den Agentenbereich und aktivieren Sie gezielte Aktionen.

  4. Bestätigen Sie die Änderung.

Aktivierung über die API

Sie aktivieren gezielte Aktionen über den Agentenbereichpreferences. Dieses Feld ist eine typisierte Zuordnung von Präferenzschlüsseln zu booleschen Werten. Sie haben es auf und gesetzt. CreateAgentSpace UpdateAgentSpace

Das folgende Beispiel ermöglicht gezielte Aktionen mit der AWS CLI.

aws devops-agent update-agent-space \
    --agent-space-id <your-agent-space-id> \
    --preferences elevatedActionsEnabled=true

Das preferences Feld weist das folgende Verhalten auf:

  • Wenn Sie ein preferences angeben, wird der gesamte Satz UpdateAgentSpace ersetzt, sodass ausgelassene Einstellungen auf ihre Standardwerte zurückgesetzt werden.

  • Wenn Sie das preferences Feld weglassen, bleiben die aktuellen Werte unverändert.

  • Die Einstellung elevatedActionsEnabled ist optional, da die Voreinstellung standardmäßig auf eingestellt ist. false

  • Die Angabe eines unbekannten Einstellungsschlüssels schlägt mit ValidationException fehl.

  • Das Ändern einer Einstellung wird sofort wirksam und entspricht dem Umschalten auf der Konsole.

  • Beim Aufrufen wird die aktuelle preferences Map GetAgentSpace zurückgegeben, die die Einstellung bestätigt.

Registrierung einer erhöhten Rolle für AWS Konto

Für jedes zugeordnete AWS Konto können Sie optional eine erweiterte Rolle registrieren. Das Monitorkonto und alle Quellkonten unterstützen jeweils eine Registrierung mit erhöhten Rollen. Eine erhöhte Rolle ist eine IAM-Rolle in Ihrem Konto, die der AWS DevOps Agent übernimmt, um gezielte Aktionen in Ihrem Namen auszuführen. Sie registrieren die Rolle, indem Sie die AWS Konfiguration agentElevatedRoleArn der Assoziation festlegen.

Beachten Sie Folgendes, wenn Sie eine erweiterte Rolle registrieren:

  • Die Registrierung pro Konto ist optional. Wenn Sie keine erhöhte Rolle für ein Konto registrieren, sind für dieses Konto nur schreibgeschützte Aktionen verfügbar.

  • Wir empfehlen eine erkennbare Benennungskonvention, DevOpsAgent-ElevatedAction-* damit erhöhte Rollen leicht zu überprüfen sind. Für den Dienst ist kein bestimmter Name erforderlich.

  • Die Berechtigungsrichtlinie der Rolle wird vom Kunden verwaltet. Beschränken Sie sie auf die Aktionen, die der Agent ausführen kann. Die Rolle definiert die Obergrenze dessen, was der Agent jemals in Ihrem Konto tun kann. Es handelt sich nicht um einen Dauerzuschuss. Jede gezielte Aktion erfordert zusätzlich die Genehmigung des Bedieners zum Zeitpunkt der Ausführung, und die Sitzung des Agenten ist weiter auf den spezifischen genehmigten Vorgang beschränkt.

Erstellung der Vertrauensrichtlinie

Die erhöhte Rolle muss dem AWS DevOps Agent-Dienstprinzipal vertrauen. Bei der Validierung wird der Pfad „Rolle übernehmen“ ausgeführt. AWS DevOps Der Agent verwendet drei STS-Aktionen, wenn er die Rolle übernimmt. Die Vertrauensrichtlinie muss alle drei: sts:AssumeRolests:SetSourceIdentity, und zulassensts:TagSession. Wenn Sie sts:SetSourceIdentity oder weglassensts:TagSession, schlagen gezielte Aktionen zum Zeitpunkt der Anmeldeinformationen fehl, auch wenn der Validierungsstatus lautet. valid

Das folgende Beispiel zeigt eine Vertrauensrichtlinie für eine erhöhte Rolle. 111122223333Ersetzen Sie es durch Ihre AWS Konto-ID und us-east-1 durch die AWS Region Ihres Agentenbereichs.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "aidevops.amazonaws.com"
      },
      "Action": [
        "sts:AssumeRole",
        "sts:SetSourceIdentity",
        "sts:TagSession"
      ],
      "Condition": {
        "StringEquals": {
          "aws:SourceAccount": "111122223333"
        },
        "ArnLike": {
          "aws:SourceArn": "arn:aws:aidevops:us-east-1:111122223333:agentspace/*"
        }
      }
    }
  ]
}

Die aws:SourceArn Bedingungen aws:SourceAccount und schützen vor dem verwirrten Stellvertreterproblem. Sie stellen sicher, dass die Rolle nur im Namen Ihrer eigenen Agentenbereiche übernommen werden kann. Die Region in der aws:SourceArn Bedingung muss mit der Region Ihres Agentenbereichs übereinstimmen. Wenn Sie Agentenbereiche in mehreren Regionen betreiben, verwenden Sie einen Platzhalter für die Region (arn:aws:aidevops:*:111122223333:agentspace/*) oder den spezifischen Agent-Space-ARN.

Erteilen von Berechtigungen für die erweiterte Rolle

Die Berechtigungsrichtlinie für die erweiterte Rolle definiert die Obergrenze dessen, was der AWS DevOps Agent jemals durch gezielte Aktionen in Ihrem Konto tun kann. Der Agent arbeitet niemals an dieser Obergrenze. Jede gezielte Aktion erfordert die Zustimmung des Bedieners. Die für eine genehmigte Aktion ausgestellten Anmeldeinformationen unterliegen einer Sitzungsrichtlinie. Die Sitzungsrichtlinie beschränkt sie auf den spezifischen Vorgang und die Ressourcen, die der Betreiber genehmigt hat. Der Agent erstellt die Sitzungsrichtlinie nur anhand einer kuratierten Liste unterstützter AWS IAM-Aktionen, die der Agent verwaltet. AWS DevOps Eine Aktion außerhalb dieser Liste kann niemals Teil einer Sitzungsrichtlinie sein. Um die Liste zu durchsuchen, öffnen Sie die Konfigurationsseite in der AWS DevOps Agent-Konsole. Wählen Sie im Abschnitt Agentenaktionen die Option Unterstützte Aktionen anzeigen aus. Sie haben zwei Optionen für die Berechtigungsrichtlinie.

Option 1: Hängen Sie die AWS verwaltete Richtlinie an. AWS DevOps Der Agent stellt die AIDevOpsAgentActionsPolicy verwaltete Richtlinie bereit. Ihr ARN lautet arn:aws:iam::aws:policy/AIDevOpsAgentActionsPolicy. Das Richtliniendokument im Codeformat finden Sie im AWS Managed Policy Reference Guide.

Die verwaltete Richtlinie weist die folgenden Merkmale auf:

  • Sie gewährt weitreichende Berechtigungen: alle Aktionen, für alle Ressourcen. Sie schließt Dienste zur Identitäts-, Anmelde- und Organisationsverwaltung aus. Die ausgeschlossenen Dienste sind account:*cognito-identity:*,iam:*,identitystore:*,organizations:*, ram:* rolesanywhere:*sso:*, und. sts:* Daher kann die Rolle keine Identitäten verwalten oder weiteren Zugriff erhalten.

  • Sie ermöglicht eine kleine Anzahl schreibgeschützter Aktionen, die von diesen Diensten zurückgesendet werden können:account:GetAccountInformation,account:GetGovCloudAccountInformation,account:GetPrimaryEmail,account:ListRegions, iam:ListRolesorganizations:DescribeEffectivePolicy, organizations:DescribeOrganization und. sts:DecodeAuthorizationMessage

  • In der Obergrenze sind Aktionen zum Löschen von Klassen enthalten. Der Agent selbst lehnt Löschvorgänge ab, unabhängig von den Berechtigungen der Rolle. Weitere Informationen zu den Vorgängen, die der Agent ablehnt, finden Sie unter Vorgänge, die der Agent nicht ausführen wird.

  • Die Richtlinie definiert nur die Obergrenze. Gültige Berechtigungen für eine einzelne Aktion werden bei der Ausführung auf den genehmigten Vorgang beschränkt.

Option 2: Schreiben Sie eine vom Kunden verwaltete Richtlinie. Wenn Sie eine strengere Obergrenze wünschen, als die verwaltete Police vorsieht, schreiben Sie Ihre eigene Police. Beschränken Sie sie auf genau die Aktionen und Ressourcen, mit denen der Agent Kontakt aufnehmen soll, und ordnen Sie sie der Rolle zu. Folgen Sie dem Prinzip der geringsten Rechte: Beginnen Sie mit den Vorgängen, von denen Sie erwarten, dass sie von den Bedienern genehmigt werden, und erweitern Sie sie nur bei Bedarf. Gezielte Aktionen, die die Rolle nicht zulässt, schlagen bei der Ausführung fehl, auch wenn sie genehmigt wurden.

Bei beiden Optionen können Sie mithilfe von Service Control Policies (SCPs) und Berechtigungsgrenzen weiter einschränken, was der Agent tun kann. Diese Kontrollen gelten für die erweiterte Rolle wie für jede andere Rolle in Ihrem Konto. Weitere Informationen zur Festlegung des Geltungsbereichs des Agentenzugriffs finden Sie unter. Beschränkung des Agentenzugriffs in einem AWS Account

Lebenszyklus der Validierung

Wie die Überprüfung der Vertrauensrichtlinie ausgeführt wird, hängt vom Kontotyp ab.

  • Überwachen Sie das (primäre) Konto. Die Validierung erfolgt synchron. AWS DevOps Der Agent validiert die Rolle, wenn Sie sie speichern. Das Ergebnis ist verfügbar, wenn die Seite neu geladen wird oder der API-Aufruf zurückkehrt. agentElevatedRoleArnStatusspiegelt valid oder invalid sofort wider.

  • Quellkonten (sekundäre Konten). Die Validierung erfolgt asynchron. Nachdem Sie eine erhöhte Rolle registriert haben, passiert Folgendes:

    1. Der Verein akzeptiert die Registrierung sofort und meldet sich agentElevatedRoleArnStatus alspending-confirmation.

    2. AWS DevOps Der Agent validiert die Rolle, indem er den Pfad „Rolle übernehmen“ ausübt.

    3. Der Status geht in den Status über, valid wenn die Validierung erfolgreich ist oder invalid fehlschlägt.

Die Rolle wird erst dann für gezielte Aktionen verwendet, wenn ihr Status lautetvalid.

Fragen Sie bei Quellkonten die Verknüpfung mit GetAssociation oder ab ListAssociations und markieren Sie das agentElevatedRoleArnStatus Feld. Die Validierung ist in der Regel innerhalb weniger Minuten abgeschlossen.

Operationen, die der Agent nicht ausführen wird

Unabhängig von den Berechtigungen, die Sie gewähren, setzt der Agent seine eigenen Richtlinien für die AWS SDK-Operationen durch, die er als gezielte Aktionen aufruft. Diese Schutzmaßnahmen gelten nur für Aktionen gegen Ressourcen. AWS Die Tool-Klassifizierung gilt stattdessen für Tools von Drittanbietern. Weitere Informationen zur Tool-Klassifizierung finden Sie unter Kategorisieren von Tools für Integrationen von Drittanbietern. Diese Leitplanken gelten auch dann, wenn die Richtlinien der übergeordneten Rolle den Betrieb zulassen. Die Genehmigung durch den Betreiber hat keinen Vorrang vor ihnen.

  • Ressourcen löschen. Der Agent lehnt Löschklassenoperationen ab, z. B. das Löschen einer Instanz, eines Buckets, einer Tabelle, einer Funktion oder eines Stacks. Der Operator löscht Ressourcen selbst mit seinen eigenen Anmeldeinformationen.

  • Ändern Sie die Berechtigungsgrenzen. Der Agent lehnt Operationen ab, die IAM-Berechtigungsgrenzen setzen oder entfernen: iam:PutRolePermissionsBoundary iam:DeleteRolePermissionsBoundaryiam:PutUserPermissionsBoundary, undiam:DeleteUserPermissionsBoundary. Grenzen sind ein Steuerelement, das Ihr Unternehmen verwendet, um den Agenten einzuschränken, sodass der Agent sie nicht ändern kann.

  • Erforderlichiam:PassRole. Standardmäßig unterstützt der Agent keine Operationen, die eine IAM-Rolle an einen AWS Dienst übergeben. Beispiele hierfür sind das Starten einer Instance mit einem Instanzprofil oder das Erstellen einer Lambda-Funktion mit einer Ausführungsrolle. Das Starten einer Aufgabe mit einer Aufgabenrolle ist ein weiteres Beispiel. Wenn Sie eine Rolle weitergeben, kann das, was ein Dienst in Ihrem Namen tut, indirekt erweitert werden.

Wenn der Agent angewiesen wird, eine dieser Operationen auszuführen, lehnt er dies ab und erklärt, warum. Wo es möglich ist, werden stattdessen die manuellen Schritte beschrieben.

Diese Leitplanken ergänzen die Kontrollen, über die Sie verfügen: die Berechtigungsrichtlinie der erweiterten Rolle, SCPs und die Berechtigungsgrenzen für die erweiterte Rolle.

Tools zur Kategorisierung von Drittanbieter-Integrationen

Third-party und MCP-Integrationen bieten Tools in drei Kategorien an, anhand derer festgelegt wird, ob der Agent das Tool aufrufen kann und welche Genehmigung erforderlich ist. AWS DevOps Der Agent weist systemeigenen Integrationen feste Klassifizierungen zu. Sie weisen sie für vom Kunden konfigurierte MCP-Server zu.

Klassifizierung Bedeutung Behavior
READ_ONLY Das Tool liest nur Informationen. Verfügbar als schreibgeschützte Aktion.
MUTATIVE Das Tool kann Ressourcen erstellen oder ändern. Erfordert die Aktivierung gezielter Aktionen und die Zustimmung des Operators pro Aktion im Chat.
DESTRUCTIVE Das Tool kann Ressourcen löschen oder irreversibel ändern. Der Agent ruft niemals Tools in dieser Klassifizierung auf.

Customer-configured MCP-Server

Für MCP-Serverzuordnungen (einschließlich der SigV4-Variante) klassifizieren Sie die Tools selbst anhand einer Liste von toolDetails Einträgen pro Tool. Jeder Eintrag hat ein und ein. name toolClassification

  • Jeder name muss exakt mit einem Eintrag in der Liste der aktivierten Tools der Assoziation übereinstimmen. Eine Nichtübereinstimmung wird bei der Registrierung zurückgewiesen.

  • Werkzeuge ohne eine gespeicherte Klassifizierung sind standardmäßig aufREAD_ONLY. Wenn Sie eine MCP-Serverzuordnung programmgesteuert über ein AWS SDK, die AWS CLI oder einen direkten API-Aufruf registrieren oder aktualisieren und Sie nichts angebentoolDetails, behandelt der AWS DevOps Agent jedes Tool in dieser Zuordnung als. READ_ONLY Der Agent führt schreibgeschützte Tools aus, ohne eine Genehmigung einzuholen. Um vor der Ausführung eines Tools, das Ressourcen erstellt oder ändert, die Genehmigung des Bedieners einzuholen, klassifizieren Sie dieses Tool explizit als. MUTATIVE Die Konsole fordert Sie auf, jedes erkannte Tool zu klassifizieren. Programmatische Aufrufer müssen sich selbst einrichten. toolDetails

  • Werkzeugnamen sind 1—128 Zeichen lang. Sie können bis zu 500 Werkzeuge pro Zuordnung klassifizieren.

Weitere Informationen zum Verbinden von MCP-Tools und zum Zulassen von Listen finden Sie unter. MCP-Server verbinden

Native Integrationen (Datadog, Grafana)

Bei nativen Integrationen wie Datadog und Grafana werden die Klassifizierungen vom Agenten festgelegt. AWS DevOps Sie geben keine Klassifizierungen an. Sie können diese Klassifizierungen nicht überschreiben. Stattdessen wählen Sie bestimmte mutierende Tools in through ausenabledElevatedTools, einer Liste von Werkzeugeinträgen.

  • Nur Tools, als die der AWS DevOps Agent sie klassifiziert, MUTATIVE können aktiviert werden.

  • Tools, die als DESTRUCTIVE (z. B.grafana_delete_alert_rule) klassifiziert sind, können niemals aktiviert werden.

Gezielte Aktionen genehmigen

Gezielte Aktionen sind von Menschen abhängig. Wenn der Agent feststellt, dass ein Vorgang, zu dessen Ausführung er angewiesen wurde, eine Ressource verändert, führt er den Vorgang nicht direkt aus. Stattdessen passiert Folgendes:

  1. Der Agent bittet um Genehmigung und präsentiert dem Bediener das spezifische Tool, den Vorgang und die Zielressource.

  2. Der Bediener prüft die Anfrage und genehmigt sie oder lehnt sie ab.

  3. Wenn dies genehmigt wird, führt der Agent den Vorgang aus. Jede Genehmigung bezieht sich nur auf das spezifische Tool, den Vorgang und die angeforderte Ressource. Sie bleibt für ein begrenztes Zeitfenster gültig und kann nicht für einen anderen Vorgang oder eine andere Ressource wiederverwendet werden.

AWS DevOps Der Agent stellt Anfragen zur Genehmigung von Operatoren nur im Chat. Wenn der Agent außerhalb des Chats ein sich veränderndes Tool aufruft, beispielsweise während einer autonomen Untersuchung, schlägt der Anruf fehl, anstatt eine Genehmigungsanfrage zu stellen. AWS DevOps Der Agent führt niemals ein mutierendes Tool ohne Genehmigung aus.

Genehmigungen und die daraus resultierenden Aktionen sind dem genehmigenden Operator in zuzuordnen. AWS CloudTrail

Der Genehmigungsablauf in der API

  • SendMessagestreamt eine Genehmigungsanfrage. Die Anforderung identifiziert das Tool, den Vorgang und die Zielressource mit Interrupt-Identifikatoren für die Wiederaufnahme. Nehmen wir als laufendes Beispiel an, ein Operator arbeitet in einem KI-Assistenten wie Claude. Der Operator fordert ihn auf, die Warteschlange mit unleserlichen Briefen zu löschen. arn:aws:sqs:us-east-1:111122223333:my-app-dlq Claude ruft den AWS DevOps Agenten SendMessage an, und der Antwortstream enthält eine Genehmigungsanfrage, in der das Tooluse_aws, der Vorgang sqs:PurgeQueue und der Warteschlangen-ARN sowie die Identifikatoren toolUseId identifiziert werden. interruptId approvalId

  • Der Operator zeichnet die Entscheidung mit UpdateApprovalAction auf. Der Betreiber stimmt mit einem endgültigen Umfang zu oder lehnt ihn mit einem optionalen Grund ab. Hier leitet Claude die Anfrage an den Operator weiter und ruft dann UpdateApprovalAction mit einem Tool use_aws auf, wobei er finalPattern an action: APPROVED und an den argumentPins Warteschlangen-ARN operation sqs:PurgeQueue angeheftet resource_arn wird.

  • Der endgültige Umfang kann die Anfrage zwar einschränken, aber niemals erweitern.

  • Der Bediener markiert eine Genehmigung für den einmaligen Gebrauch oder legt ein Zeitfenster von bis zu 4 Stunden für die Wiederverwendung fest. Das Löschen einer Warteschlange ist ein einmaliger Vorgang, daher markiert der Bediener diese Genehmigung als einmalige Verwendung (singleUse: true, nein). ttlSeconds

  • Der Client setzt die unterbrochene Konversation fort, indem er SendMessage erneut anruft und die Entscheidung im Anhang anfügt. In diesem Beispiel setzt Claude userActionResponse das,, APPROVAL_ACTION und die Entscheidung toolUseId ein und liefert approvalAction mit. interruptId approvalId APPROVED AWS DevOps Der Agent löscht dann die Warteschlange.

  • Der Genehmigungszyklus ist PENDING dann APPROVED (einlösbar) oder REJECTED (endgültig). Eine APPROVED Genehmigung wird erteilt, REDEEMED nachdem sie verbraucht wurde. Sie kann auch REVOKED vor der Verwendung erteilt werden. Hier erfolgt die Anfrage, PENDING während der Operator entscheidet, APPROVED nach der Entscheidung und REDEEMED nachdem der Agent die Warteschlange geleert hat.

Jeder Mitarbeiter kann diesen Ablauf auf die gleiche Weise steuern, egal ob es sich um einen KI-Assistenten wie Claude, einen Slack-Bot oder einen Custom Operations Client handelt: Rufen Sie anSendMessage, leiten Sie die Genehmigungsanfrage an einen Mitarbeiter weiter, notieren Sie die Entscheidung mit UpdateApprovalAction und setzen Sie das Gespräch mit ihm fort. SendMessage

Überwachung und Prüfung

  • Status der Rollenvalidierung — Überwachen agentElevatedRoleArnStatus Sie Ihre AWS Verbände (über GetAssociation oderListAssociations), um sicherzustellen, dass erhöhte Rollen weiterhin gültig valid sind.

  • AWS CloudTrail— Gezielte Aktionen, die in Ihren AWS Konten ausgeführt wurden, werden unter angezeigt CloudTrail. Die Sitzung mit übernommener Rolle trägt eine Quellidentität, die die Aktion dem genehmigenden Operator zuordnet. Sie können jede gerichtete Aktion bis zu dem Menschen zurückverfolgen, der sie genehmigt hat.

Fehlerbehebung

Eine registrierte Rolle bleibt erhaltenpending-confirmation. Dies gilt für Quellkonten (sekundäre Konten), bei denen die Validierung asynchron erfolgt. Die Validierung ist normalerweise innerhalb weniger Minuten abgeschlossen. Wenn sich der Status nicht ändert, stellen Sie sicher, dass die Rolle existiert, und registrieren Sie den Rollen-ARN erneut, um die Validierung erneut auszulösen.

Der Rollenstatus lautetinvalid. Die Überprüfung der Vertrauensrichtlinie ist fehlgeschlagen. Prüfen Sie, ob:

  • Die Vertrauensrichtlinie benennt den AWS DevOps Agentendienstprinzipal.

  • Die Vertrauensrichtlinie erlaubt alle erforderlichen STS-Aktionen (sts:AssumeRolests:SetSourceIdentity, undsts:TagSession), nicht nursts:AssumeRole.

  • Die aws:SourceAccount Bedingung entspricht dem Konto, dem der Agentenbereich gehört.

  • Die Region in der aws:SourceArn Bedingung entspricht der Region des Agentenbereichs (oder verwendet einen Platzhalter für die Region).

Korrigieren Sie die Vertrauensrichtlinie und registrieren Sie die Rolle erneut.

Gezielte Aktionen schlagen fehl, obwohl der Rollenstatus lautetvalid. Der valid Status spiegelt die Validierungsprüfung zum Zeitpunkt der Registrierung wider. Wenn die Vertrauensrichtlinie nach der Validierung geändert wurde oder ihre aws:SourceArn Bedingung an eine andere Region als den Agentenbereich gebunden ist, kann der Live-Aufruf zur Rollenübernahme trotzdem fehlschlagen. Vergleichen Sie die Vertrauensrichtlinie anhand der obigen Checkliste.

ValidationExceptionbei der Registrierung einer erhöhten Rolle. Gezielte Aktionen müssen im Agentenbereich aktiviert sein, bevor Sie eine Konfiguration mit erhöhten Rechten registrieren können. Aktivieren Sie zuerst gezielte Aktionen im Agentenbereich und registrieren Sie dann die Rolle.

Bei der Bereitstellung toolDetails stimmen die Werkzeugnamen nicht überein. Jeder Name in toolDetails muss exakt mit einem Werkzeugnamen in der Liste der aktivierten Werkzeuge der Assoziation übereinstimmen, einschließlich Groß- und Kleinschreibung. Vergleichen Sie die beiden Listen, korrigieren Sie etwaige Abweichungen, und versuchen Sie es erneut.