Linden Consulting.
Security

Secrets Manager ResourceNotFoundException: Fehlende Secrets finden und beheben

2026-05-10 · 8 Min. Lesezeit

Ihre Anwendung ist gerade beim Start mit diesem Fehler abgestürzt:

ResourceNotFoundException: Secrets Manager can't find the specified secret.
(Service: AWSSecretsManager; Status Code: 400; Error Code: ResourceNotFoundException;
Request ID: a1b2c3d4-5678-90ab-cdef-EXAMPLE)

Oder Ihr CloudFormation-Stack hängt, weil eine dynamische Referenz auf ein Secret fehlschlägt:

Template error: instance of Fn::Sub references invalid resource attribute
'SecretString' for resource 'MyDatabaseSecret'

Die ResourceNotFoundException vom Secrets Manager klingt einfach, hat aber mindestens ein halbes Dutzend möglicher Ursachen. Das Secret existiert vielleicht, aber in der falschen Region. Es wurde möglicherweise gelöscht und befindet sich im Pending-Deletion-Fenster. Die IAM-Berechtigungen blockieren den Zugriff möglicherweise so, dass es als "nicht gefunden" erscheint. Lassen Sie mich jede Ursache und die genauen Befehle zur Diagnose durchgehen.

Schritt 1: Secret-Existenz verifizieren

Beginnen Sie mit der Suche nach dem Secret. Wenn Sie den genauen Namen kennen:

aws secretsmanager describe-secret \
  --secret-id my-app/database/credentials \
  --query '{Name:Name,ARN:ARN,DeletedDate:DeletedDate,RotationEnabled:RotationEnabled}' \
  --output table

Wenn dies ResourceNotFoundException zurückgibt, existiert das Secret mit diesem Namen nicht in dieser Region. Versuchen Sie, alle Secrets aufzulisten:

aws secretsmanager list-secrets \
  --query 'SecretList[*].{Name:Name,ARN:ARN,DeletedDate:DeletedDate}' \
  --output table

Schauen Sie genau auf die Ausgabe. Häufige Namens-Abweichungen, die ich in der Praxis sehe:

  • my-app/database/credentials vs my-app/Database/Credentials (Groß-/Kleinschreibung)
  • prod/my-app/db vs my-app/prod/db (Pfadsegment-Reihenfolge)
  • my-app-database-credentials vs my-app/database/credentials (Bindestriche vs Schrägstriche)

Ursache 1: Falsche Region

Dies ist die Nummer-eins-Ursache für ResourceNotFoundException, die ich antreffe. Secrets Manager ist ein regionaler Dienst. Ein Secret, das in us-east-1 erstellt wurde, existiert nicht in eu-west-1. Wenn Ihre Anwendung mit der falschen Region konfiguriert ist oder wenn Sie in eine neue Region deployt haben, ohne die Secrets zu replizieren, erhalten Sie diesen Fehler.

Prüfen Sie, welche Region Ihr SDK oder CLI ansteuert:

# Aktuelle CLI-Region prüfen
aws configure get region

# Secrets in einer bestimmten Region auflisten
aws secretsmanager list-secrets \
  --region us-east-1 \
  --query 'SecretList[?contains(Name, `my-app`)].{Name:Name,ARN:ARN}' \
  --output table

Wenn Sie das Secret in einer anderen Region finden, haben Sie drei Optionen:

  1. Anwendungskonfiguration korrigieren, um die richtige Region zu verwenden
  2. Secret replizieren in die Region, in der die Anwendung läuft:
aws secretsmanager replicate-secret-to-regions \
  --secret-id my-app/database/credentials \
  --add-replica-regions Region=eu-west-1
  1. Neues Secret erstellen in der Zielregion (geeignet, wenn die Secret-Werte je Region unterschiedlich sind, wie Datenbank-Endpoints)

Ursache 2: Secret wartet auf Löschung

Wenn Sie ein Secret im Secrets Manager löschen, wird es nicht sofort zerstört. Es geht in einen "Pending Deletion"-Zustand mit einem Wiederherstellungsfenster von 7 bis 30 Tagen. Während dieses Fensters existiert das Secret noch, aber jeder Versuch, seinen Wert zu lesen, gibt ResourceNotFoundException zurück.

Prüfen Sie, ob das Secret auf Löschung wartet:

aws secretsmanager describe-secret \
  --secret-id my-app/database/credentials \
  --query '{Name:Name,DeletedDate:DeletedDate,DeletionDate:DeletionDate}' \
  --output table

Wenn DeletedDate gesetzt ist, ist das Secret zur Löschung vorgemerkt. Sie können es wiederherstellen:

aws secretsmanager restore-secret \
  --secret-id my-app/database/credentials

Dies stellt das Secret und seinen Wert sofort wieder her. Der Restore-Befehl funktioniert jederzeit während des Wiederherstellungsfensters.

Um alle Secrets anzuzeigen, die auf Löschung warten:

aws secretsmanager list-secrets \
  --include-planned-deletion \
  --query 'SecretList[?DeletedDate!=`null`].{Name:Name,DeletedDate:DeletedDate}' \
  --output table

Ein häufiges Szenario: Jemand führt terraform destroy aus oder löscht einen CloudFormation-Stack, wodurch die Secrets gelöscht werden. Dann referenziert die Anwendung in einem anderen Stack oder Service sie noch. Das Secret existiert, ist aber nicht zugänglich.

Ursache 3: IAM-Berechtigungen tarnen sich als Nicht-Gefunden

Dies ist die trügerischste Ursache. Wenn dem aufrufenden IAM-Principal die Berechtigung secretsmanager:GetSecretValue fehlt, gibt Secrets Manager AccessDeniedException zurück. Aber wenn dem Principal secretsmanager:DescribeSecret oder secretsmanager:ListSecrets fehlt, kann er nicht einmal bestätigen, dass das Secret existiert, sodass es aussieht, als wäre das Secret nicht vorhanden.

Noch wichtiger: Wenn eine Resource-Policy auf dem Secret den Zugriff explizit verweigert, kann die Fehlermeldung irreführend sein. Manche Organisationen verwenden Resource-Policies, um Secrets auf bestimmte VPCs oder Principals einzuschränken, und die Ablehnung sieht in Anwendungsprotokollen wie ein Nicht-Gefunden-Fehler aus.

Prüfen Sie die IAM-Berechtigungen der aufrufenden Rolle:

# API-Aufruf simulieren, um Berechtigungen zu prüfen
aws iam simulate-principal-policy \
  --policy-source-arn arn:aws:iam::123456789012:role/my-app-role \
  --action-names secretsmanager:GetSecretValue \
  --resource-arns arn:aws:secretsmanager:us-east-1:123456789012:secret:my-app/database/credentials-AbCdEf \
  --query 'EvaluationResults[0].{Action:EvalActionName,Decision:EvalDecision}' \
  --output table

Prüfen Sie, ob das Secret eine Resource-Policy hat:

aws secretsmanager get-resource-policy \
  --secret-id my-app/database/credentials \
  --query 'ResourcePolicy' \
  --output text | python3 -m json.tool

Eine restriktive Resource-Policy sieht so aus — und sie blockiert den Zugriff für jeden, der nicht auf der Erlaubt-Liste steht:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Principal": "*",
      "Action": "secretsmanager:GetSecretValue",
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:PrincipalArn": [
            "arn:aws:iam::123456789012:role/my-app-role",
            "arn:aws:iam::123456789012:role/admin-role"
          ]
        }
      }
    }
  ]
}

Die Lösung: Korrekte Berechtigungen erteilen

Die IAM-Policy für die Anwendungsrolle sollte Folgendes enthalten:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "secretsmanager:GetSecretValue",
        "secretsmanager:DescribeSecret"
      ],
      "Resource": "arn:aws:secretsmanager:us-east-1:123456789012:secret:my-app/*"
    }
  ]
}

Beachten Sie den Wildcard am Ende des Resource-ARN. Secrets Manager hängt ein zufälliges 6-Zeichen-Suffix an den Secret-ARN an, sodass my-app/database/credentials zu my-app/database/credentials-AbCdEf wird. Wenn Sie den genauen ARN ohne Suffix angeben, greift die Policy nicht.

Ursache 4: Secret-Version-Staging-Labels

Secrets Manager unterstützt Version-Staging-Labels wie AWSCURRENT, AWSPREVIOUS und benutzerdefinierte Labels. Wenn Ihre Anwendung eine bestimmte Version anfordert, die nicht existiert, erhalten Sie ResourceNotFoundException.

Prüfen Sie die verfügbaren Versionen:

aws secretsmanager describe-secret \
  --secret-id my-app/database/credentials \
  --query 'VersionIdsToStages' \
  --output json

Dies gibt etwa Folgendes zurück:

{
  "a1b2c3d4-5678-90ab-cdef-111111111111": ["AWSCURRENT"],
  "a1b2c3d4-5678-90ab-cdef-222222222222": ["AWSPREVIOUS"]
}

Wenn Ihre Anwendung ein Staging-Label wie AWSCURRENT anfordert und das Secret keine Versionen mit diesem Label hat (was bei einer fehlgeschlagenen Rotation passieren kann), schlägt der Aufruf fehl.

Versuchen Sie, das Secret mit dem Standard-Label abzurufen:

aws secretsmanager get-secret-value \
  --secret-id my-app/database/credentials \
  --version-stage AWSCURRENT \
  --query '{Name:Name,VersionId:VersionId,CreatedDate:CreatedDate}' \
  --output table

Ursache 5: Rotations-Lambda schlägt lautlos fehl

Wenn die Secret-Rotation konfiguriert ist, aber die Rotations-Lambda fehlschlägt, kann das Secret in einem inkonsistenten Zustand landen. Der Rotationsprozess erstellt eine neue Version mit dem Label AWSPENDING, aber wenn die Lambda fehlschlägt, bevor sie es zu AWSCURRENT befördert, kann das Secret unzugänglich werden.

Prüfen Sie die Rotationskonfiguration und den Status:

aws secretsmanager describe-secret \
  --secret-id my-app/database/credentials \
  --query '{RotationEnabled:RotationEnabled,RotationLambdaARN:RotationLambdaARN,LastRotatedDate:LastRotatedDate,LastChangedDate:LastChangedDate}' \
  --output table

Prüfen Sie die CloudWatch-Logs der Rotations-Lambda auf Fehler:

# Lambda-Funktionsname aus dem ARN abrufen
aws secretsmanager describe-secret \
  --secret-id my-app/database/credentials \
  --query 'RotationLambdaARN' \
  --output text

# Aktuelle Lambda-Aufrufe prüfen
aws logs filter-log-events \
  --log-group-name /aws/lambda/my-app-secret-rotation \
  --start-time $(date -d '24 hours ago' +%s000) \
  --filter-pattern "ERROR" \
  --query 'events[*].{Time:timestamp,Message:message}' \
  --output table

Wenn die Rotation feststeckt, können Sie sie abbrechen und das Secret manuell aktualisieren:

aws secretsmanager cancel-rotate-secret \
  --secret-id my-app/database/credentials

Ursache 6: CloudFormation-Dynamic-References auf nicht-existierende Secrets

CloudFormation unterstützt dynamische Referenzen auf Secrets Manager mit der Syntax {{resolve:secretsmanager:secret-name}}. Wenn das referenzierte Secret nicht existiert, wenn der Stack erstellt oder aktualisiert wird, schlägt die Stack-Operation fehl.

Häufige Probleme:

  • Das Secret wird in einem anderen Stack erstellt, der noch nicht deployt wurde
  • Der Secret-Name im Template stimmt nicht mit dem tatsächlichen Secret-Namen überein
  • Das Secret wurde außerhalb von CloudFormation gelöscht

Verifizieren Sie, dass der Secret-Name mit dem übereinstimmt, was CloudFormation erwartet:

# Template auf Secret-Referenzen prüfen
aws cloudformation get-template \
  --stack-name my-app-stack \
  --query 'TemplateBody' \
  --output text | grep -i "secretsmanager"

Schritt-für-Schritt-Diagnose-Workflow

Wenn Sie auf ResourceNotFoundException stoßen, arbeiten Sie diese Checkliste der Reihe nach ab:

  1. Secret-Name verifizieren — auf Tippfehler, Groß-/Kleinschreibung, Pfadsegment-Reihenfolge prüfen
  2. Region prüfen — ist das Secret in derselben Region wie die Anwendung?
  3. Auf Pending Deletion prüfen — describe-secret nutzen, um zu sehen, ob DeletedDate gesetzt ist
  4. IAM-Berechtigungen testen — simulate-principal-policy verwenden oder get-secret-value mit einer Admin-Rolle versuchen
  5. Resource-Policy prüfen — eine Deny-Policy kann sich als Nicht-Gefunden tarnen
  6. Version-Staging-Labels verifizieren — sicherstellen, dass AWSCURRENT existiert
  7. Rotationsstatus prüfen — eine fehlgeschlagene Rotation kann das Secret unzugänglich machen
# Schnelles Diagnose-Skript — alle Prüfungen auf einmal
SECRET_ID="my-app/database/credentials"
REGION="us-east-1"

echo "=== Secret beschreiben ==="
aws secretsmanager describe-secret \
  --secret-id $SECRET_ID \
  --region $REGION 2>&1

echo "=== Resource-Policy ==="
aws secretsmanager get-resource-policy \
  --secret-id $SECRET_ID \
  --region $REGION 2>&1

echo "=== Secret-Wert abrufen ==="
aws secretsmanager get-secret-value \
  --secret-id $SECRET_ID \
  --region $REGION \
  --query '{VersionId:VersionId,CreatedDate:CreatedDate}' 2>&1

Präventions-Best-Practices

  1. Konsistente Namenskonventionen verwenden. Übernehmen Sie einen Standard wie {environment}/{application}/{secret-type} und erzwingen Sie ihn mit einer IAM-Policy, die nur das Erstellen von Secrets erlaubt, die dem Muster entsprechen.

  2. CloudTrail-Logging aktivieren für Secrets-Manager-API-Aufrufe. So können Sie nachverfolgen, wer ein Secret gelöscht hat und wann:

aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=EventName,AttributeValue=DeleteSecret \
  --start-time 2026-05-01T00:00:00Z \
  --query 'Events[*].{Time:EventTime,User:Username,Resource:Resources[0].ResourceName}' \
  --output table
  1. Das Löschungs-Wiederherstellungsfenster auf 30 Tage setzen (Maximum) in der Produktion, um genug Zeit zur Wiederherstellung zu haben:
aws secretsmanager delete-secret \
  --secret-id my-app/database/credentials \
  --recovery-window-in-days 30

  1. Cross-Region-Replikation nutzen für Secrets, die in mehreren Regionen benötigt werden, anstatt doppelte Secrets manuell zu erstellen.

  2. Secret-Zugriff in CI/CD testen. Fügen Sie einen Pre-Deployment-Schritt hinzu, der verifiziert, dass die Anwendung alle erforderlichen Secrets lesen kann, bevor neuer Code ausgerollt wird.

  3. Infrastructure as Code verwenden, um Secrets und ihre Resource-Policies zusammen zu verwalten. Das verhindert Drift zwischen dem, was die Anwendung erwartet, und dem, was tatsächlich existiert.

Hilfe beim Secrets Management nötig?

Secrets-Manager-Fehlkonfigurationen können Deployments blockieren und Sicherheitslücken schaffen. Wenn Sie mit Rotationsfehlern, Cross-Account-Secret-Zugriff oder dem Aufbau einer konsistenten Secrets-Management-Strategie über Ihre AWS-Accounts hinweg kämpfen, können wir helfen. Kontaktieren Sie uns für eine kostenlose AWS-Beratung — wir überprüfen Ihre Secrets-Architektur und identifizieren Lücken, bevor sie Produktionsausfälle verursachen.

Brauchen Sie Hilfe mit Ihrer AWS-Infrastruktur?

Buchen Sie ein kostenloses 30-Minuten-Gespräch.

Kostenloses Erstgespräch buchen