Dfyjkt

I'm trying to figure out the security benefit to moving service authenticators to a secrets store.

It's obviously a bad idea to keep database authenticators in code or in app server configs.

AWS Secrets Manager makes it easy to encrypt secrets and have AWS automatically rotate credentials, which is a good thing. Clearly, there's security benefit to rotating the db authenticator. If someone were to somehow steal a db authenticator, Secrets Manager may be rotating it daily or more frequently and if it's old you're out of luck.

However, if your app server gets compromised, would it not have the AWS keys necessary to query Secrets Manager? Ditto for your source code (i.e., some kind of credential that leads to the db u/p is stored somewhere). And of course that app server has an IAM role attached to it that allows this query, as well as network traffic grants to access the database.

How is this really that much different from having the database authenticator stored on the app server? Is it simply that by accessing the Secrets Manager programmatically via your code (via the SDK), someone would have to compromise both your source code AND an app server in order to have the password and the proper path within the VPC (e.g., inbound security group rules, route table, etc.) to get to the data?

I think I'm missing something here!

The short answer is that Secrets Manager allows you to not have to store passwords in your source code or in configuration files that have to be distributed to your servers. However, as you point out, if your hosts are compromised all bets are off and nothing will prevent the attacker from reading your secrets from memory.

As to the AWS credentials, if this is an EC2 instance, you would also want use roles for EC2 so that AWS automatically rotates and delivers your credentials to the host.