Right now I am passing the username and password in as environment variables. The variables are retrieved from a different file so the cloudformation stored using git does not contain the password and username which is good. But, right now they are stored in plaintext when looking at the lambda in the console.
What is the best practice for storing these credentials in the most cloud provider agnostic way? I basically just don't want to use KMS or any other key storing AWS service.
Just for completeness I have also considered storing the password in a dynamodb table. Then I would use IAM to be able to retrieve those credentials. But, those credentials are still stored in plaintext. If this is the best way to retrieve credentials is there a best way to encrypt it or this path not the best.
Thanks for all comments and advice.
We use AWS Secrets Manager for this exact situation. Works perfectly for us.
Related
I have an AWS account with full access to DynamoDB.
I am writing an application that uses DynamoDB. I would like to test this application backed by the real DynamoDB (and not any local compatible/mock solution). However, the test application is not as secure a real production-ready application, and there is a real risk that during my tests an attacker may break into the test machine. If my real AWS credentials (needed to write to DynamoDB) are on that machine, they may be stolen and the attacker can basically do anything that I can do on DynamoDB - e.g., create expensive VMs in my account next week and mine for bitcoin.
So I'm looking for an alternative to saving my real AWS credentials (access key id and secret access key) on the test machine.
I read about Amazon's signature algorithm v4, and it turns out that its signature process is actually two-staged: First a "signing key" is calculated from the full credentials and this signing key works only for a single day on a single service - and then this "signing key" is used to sign the individual messages. This suggests that I could calculate the signing key on a secure machine and send it to the test machine - and the test machine will only do the second stage of the signature algorithm, and will only be able to use DynamoDB and only for a single day.
If I could do this, this would solve my problem, but the problem is that I couldn't figure out how I can tell boto3 to only do the second stage of the signing. It seems it always takes the full credentials aws_access_key_id and aws_secret_access_key - and does both stages of the signature. Is there a way to configure it to only do the second stage?
Alternatively, is there a different way in AWS or IAM or something, where someone like me that has credentials can use them to create temporary keys that can be used only for a short amount of time and/or only one specific service?
create temporary keys that can be used only for a short amount of time and/or only one specific service
Yes, that's why AWS STS service exists. Specifically you can use GetSessionToken which:
Returns a set of temporary credentials for an AWS account or IAM user. The credentials consist of an access key ID, a secret access key, and a security token.
You can also create IAM roles, and used STS's AssumeRole for the same thing. Actually using IAM roles for instances is the most preferred way to give temporary permissions for the applications on EC2 instances. This way you don't have to use your own credentials at all.
I have access to an AWS console through One Login, in which I'm assigned a role to do my business. I want to set up the CLI tool but since I don't have my own user credentials, I'm a little unclear on how to generate the access and secret access key. I don't have the ability to create a user, although that would definitely be a dumb way to go even if I could. All my Googling says to look it up from the user page or use AWS SSO, neither of which are an option for me
You can generate temporary credentials. But this is not possible if you already use temporary credentials afaik.
https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html#using-temp-creds-sdk-cli
Best case would be:
Ask your SysOps or DevOps engineer to provide you CLI credentials.
I am connecting my app to third party email service using the registered API key.
Since it is a sensitive information I would like to store it in some encrypted place and retrieve it from there.
As I am already using AWS Lambda, so for this use-case is it better to use Dynamo DB or S3 bucket to store the API key?
Parameter store is also a good option. It is possible to store encrypted data and more easy to manage than via Secret Manager.
https://aws.amazon.com/en/systems-manager/features/
For just storing API key, both S3 and DynamoDB are not the best option.
The simplest solution will be SecureString in ParameterStore.
Alternatively, you can use lambda encrypted environment variable if you want to encrypt with a specific KMS key. Then in your lambda code you decrypt the env variable.
If you do the second approach in many lambdas, then consider put this code for decryption in a lambda layer.
For my future projects, I would store secrets in the SSM ParameterStore and then make the secrets available to my lambdas as encrypted during the deployment phase. The lambdas can then use the KMS key to decrypt it during runtime.
The parameter store has a 120 requests per second limit, this way we can prevent us from hitting the limit.
I have been working for the past week using Access and Secret keys that I generated for connecting REST API to DynamoDB and AWS CLI, today I just got told by the offshore team that I am not supposed to use Access and Secret keys at all that I'm supposed to use IAM roles and I have been researching how to do that but I'm stuck, has anyone here ever had the same issue?
If everything was done the way you said it in the question and also in your comment reply to #stdunbar, it is impossible to do so, those are the purpose of both secret and access keys, i dont think your offshore team knows what they are talking about
There are methods to acquire STS session keys (like when you assume a role) from AWS. One solution is Hashicorp Vault, but this requires the infrastructure has been configured to allow this. There are other methods that use the webui session to generate an STS token.
Ask your offshore team what method you should use to get a role based access session token. You were probably used to the cli asking for Access Key ID and Secret Key. The session key will come in three parts instead of two. The session access key id will start with ASIA instead of AKIA; the session secret access key is the same as its static counterpart; the session token is a very long string.
The easiest way to set these are to edit the credentials file in .aws/credentials. If you use aws configure you won't be prompted to set the session token. you could use aws configure set for each of the parts, if you don't already have profiles set up in your credential file you can just edit the default credential profile.
source:https://docs.aws.amazon.com/cli/latest/reference/configure/index.html
The point that they're (correctly) making is that your application should not include explicit credentials.
Instead, the application should be configured in Elastic Beanstalk with an IAM role. When the application runs and uses an AWS SDK, the SDK will be able to retrieve temporary credentials from the Beanstalk environment that it is running on.
You can read more at Managing Elastic Beanstalk Instance Profiles.
I've recently been looking into AWS KMS for storing database passwords and the like. However I've also seen that secure strings in Parameter store can be used for this. In both instances I believe I would need to use the AWS CLI to access these services.
However in a production environment where there might be multiple servers, how are we supposed to go about getting the AWS CLI installed and authenticated on our instances. It feels like the CLI credentials should also be stored in Parameter store creating a bit of a catch 22. As far as I'm aware these should form part of an AMI and I don't want them in source control either.
What's the best approach here?