- Newest
- Most votes
- Most comments
Here is a great explanation of how an EC2 instance assumes the role using instance profiles: Using an IAM role to grant permissions to applications running on Amazon EC2 instances.
You can also read about the advantages of using IAM roles instead of distributing the credentials manually.
And now back to your questions.
You are correct: you need to grant the required permissions to the EC2 instance by assigning it an IAM role with appropriate permissions (for accessing the Secrets Manager service and obtaining the stored secrets).
- Checking if a request is legitimate is not something that will be done specifically by the Secrets Manager service. This is a core functionality of AWS - every API call will be checked for validity. Every API request must be signed with credentials to access the AWS services. AWS will check if the credentials are valid and if they grant permissions to call that specific API.
- When you use the Java SDK and make a call to the Secrets Manager from an instance with a role assigned, the SDK will first call the AWS Security Token Service and obtain the credentials for you. This call will happen under the hood if you attach a role to your EC2 instance. The AWS STS will issue temporary credentials that will expire after some time. Those credentials will sign the subsequential request sent to the Secrets Manager, so this is how the call will be authenticated. For more information, you can read this blog post explaining what exactly happens on assuming a role.
- The Secrets Manager service will observe an API call coming from the EC2 service. There is no way to restrict the access to a single process only. All processes running on the EC2 instance with attached role will have all permissions that role grants.
- By using resource-based permission policies, you control which IAM roles and services have access to your secrets in Secrets Manager. However, this won't prevent the intruder from accessing the secrets if an instance with role assigned will be compromised. In that case, follow the security incident response best practices and isolate the instance. Since you haven't stored any long-term credentials on that instance, the compromised temporary credentials will soon expire, so the intruder will not be able to access the services anymore. You can also configure an automatic secrets rotation in Secrets Manager, so your database passwords will automatically change too (without needing to distribute them to all your instances).
- The API call to Secrets Manager will be signed by the credentials (Access Key Id/Secret Key) that link back to the role assigned to the instance.
- Not sure specifically about Tomcat, but the API signing is built into the AWS SDKs. And the SDKs know to check the instance metadata service to retrieve the credentials.
- It will just see the request signed by credentials asserting the role that was assumed by the instance and then have the policies that allow it to retrieve the secret.
- Yes, any process on that instance can call APIs with the credentials of the role assigned to the instance.
No, I don't think there is a solution to the problem you are describing, at some point your app needs the plaintext credentials. However, using Secrets Manager and EC2 Instance Profiles keeps your secrets and encryption keys out of config files and therefore out of any code repo. Focus on making sure the policy assigned to the role follows least privilege and restricting access to instance via network controls and login permissions.
Relevant content
- Accepted Answerasked a year ago
- Accepted Answerasked 2 years ago
- asked 2 years ago
- AWS OFFICIALUpdated 5 months ago
- AWS OFFICIALUpdated 4 months ago
- AWS OFFICIALUpdated 6 months ago