Een bedrijf test zijn incidentresponsplan voor gecompromitteerde credentials. Een database draait op een Amazon EC2-instance en de gevoelige databasecredentials worden opgeslagen als een secret in AWS Secrets Manager met rotatie ingeschakeld via een AWS Lambda-functie op basis van de generieke rotatiesjabloon. De EC2-instance en de Lambda-functie bevinden zich in hetzelfde private subnet. De VPC heeft een Secrets Manager VPC endpoint. De rotatie mislukt en CloudWatch Logs toont: “setSecret: Unable to log into database.” Het VPC endpoint functioneert zoals verwacht. Welke oplossing verhelpt de fout?

De foutmelding "Unable to log into database" geeft aan dat de Lambda-functie geen verbinding kan maken met de database op de EC2-instance. Dit is een netwerkprobleem. De correcte oplossing is het aanpassen van de security groups. De security group van de Lambda-functie moet uitgaande toegang tot de EC2-instance toestaan, en de security group van de EC2-instance moet inkomende toegang vanaf de security group van de Lambda-functie toestaan. Dit zorgt voor de benodigde netwerkcommunicatie tussen de Lambda-functie en de database. Het bewerken van de JSON-structuur van het secret (optie 1) lost geen netwerkconnectiviteitsprobleem op. Het handmatig forceren van rotatie via de CLI (optie 3) omzeilt het probleem, maar lost de onderliggende oorzaak van de mislukte automatische rotatie niet op. Het toevoegen van een internetgateway en NAT-gateway (optie 4) is overbodig en onnodig, aangezien er al een Secrets Manager VPC endpoint aanwezig is en de communicatie tussen de Lambda-functie en de EC2-instance binnen het private subnet moet plaatsvinden.