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.

Arbeiten mit kontinuierlicher Modernisierung

Quellenverwaltung

Verwenden Sie atx ct source Befehle, um Repositorys zu verbinden. Unterstützte Anbieter: GitHub, GitLab, Bitbucket, local.

GitHub Organisationen

Token: persönliches Zugriffstoken (klassisch) mit repo Gültigkeitsbereich. Read-only zur Analyse, vollständiges Repo zur Behebung.

atx ct source add --name name --provider github --org org --token pat

GitLab Gruppen und Benutzer

Token: persönliches Zugriffstoken mit api Gültigkeitsbereich.

atx ct source add --name name --provider gitlab --org group-or-user --token pat
# Self-hosted:
atx ct source add --name name --provider gitlab --org group-or-user --token pat --url https://gitlab.example.com

Bitbucket-Workspaces und -Projekte

Bitbucket Cloud — Bereiche:read:repository:bitbucket,,,. write:repository:bitbucket read:pullrequest:bitbucket write:pullrequest:bitbucket --emailBenötigt auch und. --username

atx ct source add --name name --provider bitbucket --org workspace --token api-token --email email --username username

Bitbucket-Rechenzentrum:

atx ct source add --name name --provider bitbucket --org project-key --token http-access-token --url https://bitbucket.example.com

Lokale Repositorys

atx ct source add --name name --provider local --path parent-directory

Konventionen für das Repository

Repositorys können Regeln durchsetzen, die einen Push am Ende einer Korrektur ablehnen — ein erforderliches Commit-Nachrichtenformat (GitLab Push-Regeln, Bitbucket-Commit-Hooks, GitHub Regelsätze), ein eingeschränkter Branch-Namespace oder ein bekannter Commit-Autor. Notiere diese Konventionen in der Quelle, sodass Behebungsbefehle und Ergebnis-Branches in der Form geschrieben werden, die für die Repositorys erforderlich ist. Jede Option ist sowohl für als auch verfügbar. atx ct source add atx ct source update

# Commit message format ({PLACEHOLDER} is replaced with a description of each change)
atx ct source update --name name --commit-message-template "fix: {PLACEHOLDER}"

# Branch namespace ({PLACEHOLDER} is replaced with the branch name AWS Transform generates)
atx ct source update --name name --branch-name-template "customized/{PLACEHOLDER}"

# Git committer identity (both options are required together)
atx ct source update --name name --git-committer-name "ATX Automation" --git-committer-email atx-automation@example.com

Übergeben Sie eine leere Zeichenfolge, um eine Vorlage zu entfernen oder das Committer-Paar zu löschen. Die Optionen gelten für Sicherheits- und Transformationsmaßnahmen sowie für lokale Quellen, deren Repositorys Sie manuell übertragen.

Verwaltung von Quellen

atx ct source list
atx ct source update --name name --token new-token
atx ct source remove --name name

atx ct source updateakzeptiert jede Kombination aus --token und den oben genannten Optionen der Repository-Konvention. Wenn keine Optionen übergeben werden, ist das ein Fehler. Sie können eine Quelle von jedem Computer aus aktualisieren, nicht nur von dem Host, auf dem sie ausgeführt wurdeatx ct source add.

Erkennung und Verwaltung von Repositorys

atx ct discovery scan --source name
atx ct discovery status --source name
atx ct discovery scan --source name --path new-directory

Nach der Entdeckung:

atx ct repository list
atx ct repository list --source name
atx ct repository list --labels "team:frontend,priority:high"
atx ct repository update --source name --repo "source::repo" --labels "team:frontend,priority:high"
atx ct repository update --source name --labels "migration:wave-1"

Analyse wird ausgeführt

Das --type Kennzeichen gibt an, welche Art von Analyse ausgeführt werden soll:

atx ct analysis run --type type --source name [--repo source::repo] [--wait]
atx ct analysis get --id id --json
atx ct analysis list --json
atx ct analysis list --status pending|running|complete|cancelled|failed --json
atx ct analysis list --type type --json
atx ct analysis cancel --id id
atx ct analysis delete --id id [--cascade-findings]

Wenn Sie es weglassen--repo, analysiert der Befehl jedes Repository unter--source. Um die Ausführung auf bestimmte Repositorys zu beschränken, übergeben Sie --repo (durch Kommas getrennt) — jeweils ein vollqualifiziertessource:: oder einen bloßen Namenrepo, der mit verwendet wird. --source

Um einen Lauf so zu kennzeichnen, dass er später leicht wiedergefunden werden kann, geben Sie oder weiter. --display-name "name" atx ct analysis run atx ct remote analysis Der Name wird in atx ct analysis list und angezeigtatx ct analysis get.

Benutzerdefinierte Analyse

Bei einer benutzerdefinierten Analyse wird eine Ihrer eigenen Transformationsdefinitionen anhand Ihrer Repositorys ausgeführt, um nach den Problemen zu suchen, die Sie interessieren. So führen Sie eine aus:

atx ct analysis run --type custom --transformation-name name --source source --repo source::repo --wait

Konfiguration mit -g Flag: Schlüsselwert, JSON oder Dateipfad.

Wenn der Befehl fehlschlägt, weil die Transformationsdefinition nicht gefunden wurde, überprüfen Sie den Namen mit. atx custom def list Transformationsdefinitionen sind für ein AWS Konto und eine Region spezifisch. Wenn sie aufgrund der Kategorie der Transformationsdefinition fehlschlägt, veröffentlichen Sie sie erneut mit--category analysis.

Verwaltung der Erkenntnisse

atx ct findings list --json
atx ct findings list --repo source::repo --source name --severity high|medium|low --type analysis-type --status open|dismissed|obsolete|change_ready --analysis-id id --fix-transform transform-name --json

Status suchen

atx ct findings update --id id --status dismissed --reason "reason"
atx ct findings update --id id --status open
atx ct findings batch-update --ids id1,id2 --status dismissed --reason "reason"
atx ct findings get --id id
atx ct findings delete --id id

Obsoleszenz feststellen

Re-analysis kennzeichnet behobene Ergebnisse als veraltet. Kann nicht erneut geöffnet werden. Zur Prüfung aufbewahrt.

Erstellung von Abhilfemaßnahmen

Drei Modi: ergebnisbasiert, TD Override, Direct TD. Verwenden Sie mit --transformation-name eine Ihrer eigenen Transformationsdefinitionen für die remediation Kategorie oder eine AWS verwaltete Transformation (siehe). Kategorien von Transformationsdefinitionen

atx ct remediation create --ids id1,id2 --name "name"
atx ct remediation create --ids id1,id2 --transformation-name TD
atx ct remediation create --transformation-name TD --repo source::repo

Ausgabe nach Anbieter: GitHub PR, GitLab MR, Bitbucket PR, Lokaler Zweig.

Lokale Ausführung mit --local Flagge.

atx ct remediation create --transformation-name TD --repo source::repo -g "additionalPlanContext=Upgrade to Node.js 22"
atx ct remediation list
atx ct remediation status --id id
atx ct remediation retry --id id
atx ct remediation cancel --id id
atx ct remediation delete --id id

Ausführung aus der Ferne

Standardmäßig werden Analysen und Problembehebungen auf Ihrem lokalen Computer ausgeführt. Bei größeren Portfolios können Sie die Arbeit auf die Remote-Infrastruktur auslagern. Sie können auf einer AWS Transform-managed Infrastruktur laufen, für die nichts bereitgestellt werden muss (nur Analysen), oder auf einer Infrastruktur, die Sie in Ihren AWS-Konto— persistenten Amazon EC2 EC2-Instance- oder AWS Batch-Jobs (Fargate) — bereitstellen und verwalten. Die atx ct remote Befehle stellen die vom Kunden verwaltete Infrastruktur bereit, führen, überwachen und zerstören. Unabhängig davon, wo die Ausführung stattfindet, erstellen Sie alle Ressourcen in Ihrem AWS-Konto System und Ihr Quellcode bleibt unter Ihrer Kontrolle.

Mit den Befehlen für atx ct remote Analyse und Problembehebung wählen Sie aus, welche Repositorys mit --sources und --repos (beide durch Kommas getrennt) verarbeitet werden sollen. --sourceswählt jedes Repository in den genannten Quellen aus. --reposwählt bestimmte Repositorien aus, die jeweils wie folgt geschrieben sindsource:repo. Wenn Sie beide angeben, verarbeitet der Befehl die Vereinigung der beiden Gruppen: jedes Repository in den benannten Quellen plus die benannten Repositorys. Um eine Ausführung auf bestimmte Repositorys zu beschränken, geben Sie nur die Befehlsfolge weiter. --repos

Läuft auf AWS Transform-managed Infrastruktur (keine Bereitstellung)

Um eine Analyse remote auszuführen, ohne etwas bereitzustellen, verwenden Sie. --mode aws-managed Die Einreichung geht an AWS Transform, das die Analyse auf der AWS Transform-managed Infrastruktur durchführt. Es muss kein Stack bereitgestellt, kein Netzwerk konfiguriert und keine Anmeldeinformationen in AWS Secrets Manager gespeichert werden. Die Einreichung ist der Lauf. Wählen Sie die AWS Region aus, in der der Workload ausgeführt wird--region.

# Run an analysis on AWS Transform-managed infrastructure
atx ct remote analysis --type type --mode aws-managed --sources name [--repos repo1,repo2] [--region region]

# Poll the submission (there is no remote status command in this mode)
atx ct analysis get --id id --json

In diesem Modus werden nur Analysen ausgeführt. Die Problembehebung, der custom Analysetyp oder lokale Quellen werden nicht unterstützt. Da es keinen Stapel gibt, gelten die --stack-name --batch-name Optionen--existing-instance,, und nicht. --tags Eine einzige Einreichung deckt bis zu 100 Repositorien ab. Um größere Bereiche abzudecken, teilen Sie sie auf mehrere Einreichungen mit auf. --repos Im Gegensatz zu Amazon EC2- und Batch-Läufen überwachen Sie den Fortschritt atx ct analysis get eher mit alsatx ct remote status.

Netzwerk

Die Remote-Datenverarbeitung muss in privaten Subnetzen ausgeführt werden. Entdecken Sie bestehende Netzwerke oder erstellen Sie eine neue VPC, bevor Sie sie bereitstellen:

# List VPCs, private subnets, and security groups in the current account and Region
atx ct remote network discover
atx ct remote network discover --vpc vpc-id --json

# Create a new VPC with private subnets, a NAT gateway, and a security group
atx ct remote network create --cidr 10.1.0.0/16 --ack

--cidrist optional und ist standardmäßig auf. 10.1.0.0/16

Unabhängig davon, ob Sie Ihr eigenes Netzwerk mitbringen oder dieses verwendennetwork create, muss es die folgenden Anforderungen erfüllen:

Dimensionierung von Subnetzen und Parallelität

Bevor Sie die AWS Batch-Infrastruktur für eine große Repository-Flotte bereitstellen, sollten Sie Ihre privaten Subnetze entsprechend der Anzahl der Jobs dimensionieren, die parallel ausgeführt werden. Ein zu kleines Subnetz ist die häufigste Ursache für fehlgeschlagene Jobs in einer großen Serie.

Jeder AWS Batch-Job wird als eine Fargate-Aufgabe ausgeführt, die eine elastic network interface und daher eine private IPv4-Adresse benötigt. Die Zuweisung öffentlicher IP-Adressen ist deaktiviert, sodass eine private Adresse erforderlich ist. Ohne eine Adresse kann ein Job nicht gestartet werden. AWS Batch stellt einen Job, den es nicht platzieren kann, nicht in die Warteschlange. Der Job schlägt fehl.

Überprüfen Sie freie Adressen, bevor Sie sie bereitstellen

Beim Provisioning wird die Subnetzkapazität nicht für Sie überprüft. Prüfen Sie selbst--json, welche Berichte availableIpCount für jedes Subnetz erstellt werden. Die Standard-Tabellenausgabe enthält diesen Wert nicht. Vergleichen Sie die kleinste Anzahl mit dem Parallelitätslimit für den Analysetyp, den Sie ausführen möchten.

atx ct remote network discover --vpc vpc-id --json

Parallelitätsgrenzen für jeden Analysetyp

AWS Transform begrenzt, wie viele Remote-Jobs gleichzeitig in einer AWS-Konto UND-Region ausgeführt werden. Das Limit hängt vom Analysetyp ab. Diese Grenzwerte gelten für alle Benutzer im Konto und für beide Rechenmodi. Sie begrenzen die Anzahl der Adressen, die ein Lauf verbrauchen kann. Um eine Änderung zu beantragen, wenden Sie sich an den AWS Support.

Minimale Subnetzgröße

Amazon VPC reserviert fünf Adressen in jedem Subnetz, sodass die nutzbare Anzahl fünf weniger ist als die Subnetzgröße — a /28 hat 11 nutzbare Adressen und a /24 hat 251. Einzelheiten finden Sie unter Subnetz-CIDR-Blöcke im Amazon VPC-Benutzerhandbuch.

Bei den Adressen, die jedes Subnetz benötigt, handelt es sich um die maximale Anzahl gleichzeitiger Jobs sowie um eine oder mehrere Adressen für jeden Schnittstellenendpunkt in diesem Subnetz sowie um alle anderen Netzwerkschnittstellen, die das Subnetz gemeinsam nutzen. Der Höchstwert für gleichzeitige Jobs ist der kleinere Wert aus der Anzahl der Repositorys in der Einreichung und dem Parallelitätslimit für den Analysetyp. Da das Limit die Gesamtzahl begrenzt, benötigt eine Flotte von 1.000 Repositorys nicht mehr Adressen als eine Flotte mit 128 Repositorys.

Die oben genannten Mindestwerte beinhalten Spielraum für Schnittstellen-Endpunkte und für die Adressreserven. AWS Erhöhen Sie die Größe, wenn sich andere Workloads das Subnetz teilen. A /25 ist nicht ausreichend für 128 gleichzeitige Jobs: Es bietet 128 Adressen, aber nur 123 verwendbare.

Wir empfehlen, Subnetze für die Ausführung per Fernzugriff zu reservieren. AWS Transform lässt Jobs bis zur letzten freien Adresse zu und kann keine anderen Workloads berücksichtigen, die Adressen im selben Subnetz beanspruchen.

Betrieb großer Flotten

In der Amazon EC2- und Batch-Infrastruktur, die Sie bereitstellen, deckt eine einzige Einreichung bis zu 1.000 Repositorys ab (AWS Transform-managed Durchläufe sind auf 100 begrenzt). Einsendungen, die das Limit überschreiten, werden abgelehnt, bevor ein Job gestartet wird. Um größere Flotten abzudecken, teilen Sie sie mit --repos auf und listen Sie die Repositorien in einer Quelle mit auf. atx ct repository list --source name --json

Durch die Aufteilung einer Flotte werden die benötigten Adressen nicht reduziert. Eingaben, die gleichzeitig ausgeführt werden, beziehen sich auf dieselben Subnetze, bis zum Parallelitätslimit für den Analysetyp.

Es gibt keine Option, die einschränkt, wie viele Repositorys gleichzeitig gescannt werden. Die CLI sendet jeden Job in einer Einreichung, und AWS Transform gibt Jobs bis zum Parallelitätslimit für den Analysetyp frei und speichert den Rest. Um einer großen Flotte gerecht zu werden, passen Sie die Größe der Subnetze an dieses Limit an oder reichen Sie sie in kleineren Gruppen ein.

Die CLI begrenzt die Anzahl der gleichzeitigen Verbindungen, die sie zum Analysedienst öffnet. Bei sehr umfangreichen Einsendungen, die Sie möglicherweise socket usage at capacity auf stderr sehen, handelt es sich bei dieser Meldung um eine Information, nicht um einen Fehler. Wenn das Limit für offene Dateien Ihrer Shell auf oder unter dem Grenzwert liegt, warnt die CLI einmal beim Start. Erhöhen Sie das Limit (zum Beispielulimit -n 4096) oder senken Sie das Limit mit der ATX_MAX_SOCKETS Umgebungsvariablen.

Auswahl von Amazon EC2 für eingeschränkte Netzwerke

Amazon EC2 verwendet insgesamt eine private IP-Adresse im ersten Subnetz, das Sie passieren, unabhängig davon, wie viele Worker die Instance ausführt. Wenn freie Adressen knapp sind, vermeidet Amazon EC2 das Problem vollständig.

Der Kompromiss ist Parallelität: --workers akzeptiert 1—5, sodass eine Amazon EC2 EC2-Instance maximal 5 Repositorys parallel ausführt. Verwenden Sie AWS Batch für Flotten, die mehr benötigen. Für security Analysen liegt das Kontenlimit ebenfalls bei 5, sodass AWS Batch für diesen Typ keine zusätzliche Parallelität bietet.

Größe --workers--instance-type, und --volume-size Zeitpunkt der Bereitstellung. Der Instanzspeicher muss mindestens 2 GB für jeden Worker plus 4 GB für das Betriebssystem betragen. atx ct remote updatebehält diese Werte bei. Wenn Sie sie ändern, müssen Sie sie herunterfahren und erneut bereitstellen, wodurch die Instanz ersetzt und ihr Volume gelöscht wird.

Bereitstellen der Infrastruktur

Stellen Sie den Amazon EC2- oder AWS Batch-Stack bereit. Lassen Sie es aus--execute, um eine Vorschau der Vorlage oder des Changesets anzuzeigen, und fügen Sie es hinzu, um es anzuwenden. --execute

Beim Provisioning werden der Computing-Stack für den von Ihnen ausgewählten Modus sowie die Dispatcher- und Scheduler-Stacks erstellt:

Standardmäßig sind Amazon EC2 EC2-Stacks benannt atx-runner und AWS Batch-Stacks sind benannt. AtxInfrastructureStack Um mehr als einen Stack desselben Modus auszuführen, geben Sie jedem einen eindeutigen Namen, wenn Sie Folgendes bereitstellen: verwenden --stack-name (nur Amazon EC2; der Name muss mit beginnenatx-runner) oder --suffix um allen Ressourcennamen ein Suffix anzuhängen. Gehen Sie für update Analysen oder Problembehebungen per Fernzugriff --stack-name zu einem Stack mit benutzerdefiniertem Namen über. detect Wenn Sie ihn weglassen, verwenden sie den Standardnamen (atx-runnerfür Amazon EC2, AtxInfrastructureStack für AWS Batch). teardownbenötigt immer. --stack-name --workersLegt auf Amazon EC2 die Anzahl der parallel Worker-Container (1-5, Standard 5) fest und dimensioniert die Instance.

# Preview, then deploy an EC2 stack
atx ct remote provision --mode ec2 --vpc vpc-id --subnets subnet-a,subnet-b
atx ct remote provision --mode ec2 --vpc vpc-id --subnets subnet-a,subnet-b --execute --ack

# Deploy a Batch stack
atx ct remote provision --mode batch --vpc vpc-id --subnets subnet-a,subnet-b --securityGroup sg-id --execute --ack

# Update to the latest template (--stack-name optional; defaults to the standard stack name)
atx ct remote update --mode ec2|batch [--stack-name stack-name] --execute --ack

# Tear down (--stack-name required)
atx ct remote teardown --mode ec2|batch --stack-name stack-name --execute --ack

Container-Image

Wenn Sie Remote-Analysen und -Abhilfemaßnahmen durchführen, werden sie in einem Container-Image ausgeführt. Wenn Sie eine Remote-Umgebung bereitstellen, verwendet sie standardmäßig das öffentliche AWS Transform-Image,public.ecr.aws/d9h8z6l7/aws-transform:latest. AWS Batch legt es als Jobdefinitionsbild fest. Amazon EC2 verwendet es als Runner-Image.

Um ein anderes Image auszuführen — z. B. ein privates Amazon ECR-Image, das zusätzliche Sprachen oder Tools --image-uri bündelt — gilt bei der Bereitstellung Folgendes:

# Batch: provision with a custom image
atx ct remote provision --mode batch --vpc vpc-id --subnets subnet-a,subnet-b --securityGroup sg-id --image-uri account-id.dkr.ecr.region.amazonaws.com/repo:tag --execute --ack

# EC2: provision with a custom image
atx ct remote provision --mode ec2 --vpc vpc-id --subnets subnet-a,subnet-b --image-uri account-id.dkr.ecr.region.amazonaws.com/repo:tag --execute --ack

Speichern von Quellanmeldedaten

Remote-Container klonen Ihre Repositorys mithilfe von Tokens, die in AWS Secrets Manager gespeichert sind. Registrieren Sie ein Token für jede SCM-Quelle, bevor Sie eine Fernanalyse oder -behebung ausführen:

atx ct remote credentials --source name --token token
atx ct remote credentials --source name --remove

Wird remote ausgeführt

Bei der Remote-Analyse wird ein Container für jedes Repository ausgeführt. Bei der Remediation wird für jedes Ergebnis ein Container ausgeführt. Verwenden Sie--sources, und--repos, --labels um den Fan-Out zu steuern, --stack-name und/oder --tags um auszuwählen, welcher bereitgestellte Stack verwendet werden soll.

# Run analysis across a source on Batch
atx ct remote analysis --type type --mode batch --sources name [--repos repo1,repo2] [--labels "team:frontend"]

# Run remediation for specific findings on EC2
atx ct remote remediation --mode ec2 --ids id1,id2
atx ct remote remediation --mode ec2 --sources name --min-severity high

Läufe überwachen und verwalten

# Check whether infrastructure is deployed
atx ct remote detect --mode ec2|batch

# Track a submission (Batch by batch ID, EC2 by group ID)
atx ct remote status --batch batch-id --stack-name name
atx ct remote status --group ec2-group-id --wait

# Resume a partially-failed Batch run (re-submits only incomplete repos).
# On resume, --batch-name takes the existing batch ID reported by "remote status --batch".
atx ct remote analysis --type type --mode batch --sources name --resume-incomplete --batch-name batch-id

# Cancel a running submission
atx ct remote cancel --mode batch --batch batch-id --stack-name name
atx ct remote cancel --mode ec2 --group ec2-group-id

Planung wiederkehrender Analysen

atx ct scheduleDient zum automatischen Ausführen von Analysen in wiederkehrenden Abständen. Sie können Analysen planen, aber keine Korrekturen. Job Joboptionen spiegeln sich wideratx ct remote analysis. Zeitpläne können remote ausgeführt werden, und zwar auf eine von zwei Arten:

Der --recurrence Wert akzeptiertdaily, weekly:DAY (zum Beispielweekly:MONDAY), oder monthly:N wo ein Tag zwischen 1 und 28 N liegt. Die Zeitpläne auf der AWS Transform-managed Infrastruktur werden in UTC ausgeführt.

# AWS Transform-managed schedule (no infrastructure; requires an execution role)
atx ct schedule create --name name --mode aws-managed --execution-role role-arn --recurrence daily --type type --sources name [--repos repo1,repo2]

# Customer-managed schedule (EventBridge Scheduler dispatching to your EC2 or Batch stack)
atx ct schedule create --name name --mode ec2|batch --recurrence weekly:MONDAY --type type --sources name [--repos repo1,repo2]

# Manage schedules of either type by their schedule ID (from schedule list)
atx ct schedule list
atx ct schedule get schedule-id
atx ct schedule disable schedule-id
atx ct schedule enable schedule-id
atx ct schedule delete schedule-id

Um die Analysen anzuzeigen, die ein Zeitplan ausgeführt hat, verwenden Sieatx ct analysis list --schedule-id schedule-id, wodurch die ausgelösten Läufe des Zeitplans zurückgegeben werden, wobei die neuesten zuerst angezeigt werden.

Um die Scheduler-Rolle und die Zeitplangruppe zu entfernen, die von kundenverwalteten Zeitplänen verwendet werden, führen Sie den Befehl aus. atx ct schedule teardown --execute

Ausführungsrolle für AWS Transform-managed Zeitpläne

Ein mit erstellter Zeitplan --mode aws-managed erfordert einen --execution-role ARN, den AWS Transform bei jeder Ausführung des Zeitplans annimmt. Konfigurieren Sie die Rolle wie folgt:

Die folgende Inline-Richtlinie gewährt dem AWS Secrets Manager Zugriff, den geplante Läufe zum Abrufen von Quell-Clone-Anmeldeinformationen benötigen. Fügen Sie sie der Ausführungsrolle neben der AWSTransformCustomFullAccessverwalteten Richtlinie hinzu region und account-id ersetzen Sie sie durch die AWS Region und das Konto, in denen der Zeitplan ausgeführt wird.

{
  "Version": "2012-10-17", 
  "Statement": [
    {
      "Sid": "AtxSourceCredentials",
      "Effect": "Allow",
      "Action": [
        "secretsmanager:GetSecretValue",
        "secretsmanager:DescribeSecret"
      ],
      "Resource": "arn:aws:secretsmanager:region:account-id:secret:atx/*"
    }
  ]
}

Tagging und Zugriffskontrolle

Mit dieser Option können Sie Tags (durch Kommas getrennte key=value Paare) auf Quellen, Analysen und Problembehebungen anwenden. --tags Tags werden auch für Remote-Infrastrukturen, gespeicherte Anmeldeinformationen und Netzwerkressourcen unterstützt. Mit Tags können Sie Ressourcen organisieren. In Kombination mit IAM-Tag-Bedingungen implementieren Tags eine attributebasierte Zugriffskontrolle (ABAC), sodass Teams nur auf die Ressourcen zugreifen, die ihre Tags enthalten.

atx ct source add --name name --provider github --org org --token pat --tags team=platform,env=prod
atx ct analysis run --type type --source name --tags team=platform
atx ct remediation create --ids id1,id2 --tags team=platform

Standardmäßig werden Ressourcen mit den von Ihnen definierten Tags gekennzeichnet. ~/.aws/atx/settings.json Fügen Sie die Tags hinzu, die Sie auf jede Ressource unter anwenden möchtenapplyTags, und sie werden zu Ihren Standard-Tags.

{
  "applyTags": [
    { "team": "alpha" }
  ]
}

AWS Transformieren Sie die Webanwendung

Verwenden Sie die AWS Transform-Webanwendung, um Analysen zu erstellen und auszuführen, Ergebnisse zu überprüfen, Abhilfemaßnahmen zu ergreifen und generierte Pull-Requests in Ihren Codequellen nachzuverfolgen.

Bevor Sie die Webanwendung verwenden können, muss Ihre Organisation Ihre Benutzeridentität für den Zugriff auf AWS Transform aktivieren. Weitere Informationen zur Einrichtung von AWS Transform finden Sie unter AWS Transform einrichten.

Anmelden

Gehen Sie wie folgt vor, um auf die AWS Transform-Webanwendung zuzugreifen.

Infrastrukturmodi

Wenn Sie eine Analyse erstellen, wählen Sie einen der folgenden Infrastrukturmodi:

Um die Infrastruktur des Kunden zu verwenden, öffnen Sie die Registerkarte Einstellungen. Verwenden Sie die Links zur AWS CloudFormation Schnellerstellung, um die folgenden Stacks der Reihe nach bereitzustellen:

Informationen zur CLI-based Bereitstellung und Netzwerkkonfiguration finden Sie unterAusführung aus der Ferne.

Arbeitsablauf „Erste Schritte“

Chatten Sie direkt von der Webanwendung aus mit AWS Transform, um Fragen zu Ihren Analysen, Ergebnissen oder Abhilfemaßnahmen zu stellen.