2

For our product we have decided to implement a Secret Management tool (AWS secrets manager) that will securely store and manage all our secrets such as DB credentials, passwords and API keys etc.

In this way the secrets are not stored in code, database or anywhere in the application. We have to provide the AWS credentials - Access Key Id and Secret access key to programmatically access the APIs of Secrets manager.

Now the biggest question that arises is, where to keep this Initial Trust – the credentials to authenticate the AWS secrets manager.? This is a bootstrapping problem. Again, we have to maintain something outside of the secret store, in a configuration file or somewhere. I feel If this is compromised then there is no real meaning to store everything in a Secret management tool.

I read the AWS SDK developer guide and understand that there are some standard ways to store AWS credentials like – storing them in environmental variables, credentials file with different profiles and by Using IAM roles for Amazon EC2 Instances.

We don’t run/host our application in Amazon cloud, we just want to use AWS secrets manger service from AWS cloud. Hence, configuring the IAM roles might not be the solution for us.

Are there any best practices (or) a best place to keep the initial Trust credentials?

Dale K
  • 25,246
  • 15
  • 42
  • 71
Suriyakanth
  • 269
  • 4
  • 13
  • Late breaking news, AWS launched [IAM Roles Anywhere](https://aws.amazon.com/about-aws/whats-new/2022/07/aws-identity-access-management-iam-roles-anywhere-workloads-outside-aws/) which lets you authenticate from outside AWS using certificates. If you have already setup PKI and issue host certificates, you can use those certificates as the root of trust. – JoeB Jul 14 '22 at 03:41

2 Answers2

3

If you're accessing secrets from EC2 instance, ECS docker container, Lambda function, you can use Roles with policy that allows access to Secrets Manager.

if IAM Role is not an option, You can use Federation Login to get temporary credentials (IAM Role) with policy that allows access to Secrets Manager.

Tomasz Breś
  • 481
  • 2
  • 5
  • There is an [AWS security blog](https://aws.amazon.com/blogs/security/how-to-implement-federated-api-and-cli-access-using-saml-2-0-and-ad-fs/) post that might be a good starting point. – JoeB Sep 06 '19 at 18:02
1

As @Tomasz Breś said, you can use federation if you are already using an on-premis Auth system like Active directory or Kerberos.

If you do not have any type of credentials already on the box, you are left with two choices: store your creds in a file and use file system permissions to protect them, or use hardware like an HSM or TPM to encrypt or store your creds.

In any case, when you store creds on the box (even AD/Kerberos), you should ensure only the application owner has access to that box (in the case of a stand alone app and not a shared CLI). You should also harden the box by turning off all un-necessary software and access methods.

JoeB
  • 1,503
  • 7
  • 9
  • @Tomasz-bres, Thanks for your comments. I read about SAML based federation and understand it is possible. Now, I have one more question - To get the SAML assertion from my IDP I need to provide my ad_username and ad_password. So, make programattica calls to AWS services I first need to get the SAML assertion programattically.. How to fetch SAML Assertion from ADFS for AWS STS in Java?? Secondly, again I'm storing some credentials in my application which now becomes my initial trust – Suriyakanth Sep 09 '19 at 10:25