I have a react app which is deployed using AWS Amplify. I'm using Google maps in my application and I wanted to know the right place to put the Google Maps API key. I have read about AWS Amplify Environment variables where we can save the api key in key-value pairs. Also, I know that we have AWS Secrets, which is for saving private data.
What is the right approach to save the API key in my use case? Is saving the api key in Amplify Environment variables safe enough? Or should I go for AWS secrets?
The google maps api best practices include (depends exactly what you are using):
Store API keys and signing secrets outside of your application’s source code.
Store API keys or signing secrets in files outside of your application's source tree.
Amplify Environment variables are suited to store:
Third-party API keys
since
As a best practice, you can use environment variables to expose these configurations. All environment variables that you add are encrypted to prevent rogue access, so you can use them to store secret information.
So you can use them, as their are native to Amplify. AWS Secrets Manager is not natively supported by amplify, and you would have to add extra code to your backend to to make use of them.
The important thing to note is that these Amplify Environment variables are only to be used by your backend service. Not by a front-end code.
Related
How in a work environment with different AWS environments say for example develop, staging and production is it best to store the AWS Access Key and Secret Key other than in the appsettings.json files in .Net Core? I know there is Secret Manager but not sure if that is the best way to store these two values. Looking for someone that may have done this specifically for production and how they handled this within their organization. Thanks for any information.
I believe that your application is running outside of AWS and that it needs to make API calls to AWS services, for example SQS. To make those API calls, your application needs AWS credentials.
Here are approaches for authenticating external applications in a machine-to-machine scenario. In your case, your client seems to need to be able to make arbitrary AWS service requests and that means using AWS signature v4 requests, signed using AWS credentials, which are ideally temporary, rotated credentials from STS rather than persistent credentials (such as IAM user credentials).
Typically, you would configure your application with a base set of IAM credentials that allow the application to assume an IAM role. That role itself, rather than the base credentials, would then give your application the permissions it needs to make SQS API calls etc.
The issue you face is how to securely store the base set of credentials. This is a problem that on-premise applications have had since day one, well before the cloud era, and there are various solutions, depending on the technology you're using.
Typically these credentials would be encrypted, not committed to code repos, and populated on the relevant, locked down application servers in some secure fashion. Some potentially useful resources:
Encrypting sections of a configuration file for an ASP.NET application
Use AWS Secrets Manager to store & read passwords in .Net Core apps
Securely store and retrieve sensitive info in .NET Core apps with Azure Key Vault
AWS Secret Manager securely stores your secrets until you retrieve them at runtime. If your going to be running your ASP.NET Core app in AWS, then AWS Secrets Manager is a great option, as it allows you to finely control the permissions associated with the AWS IAM roles running your apps.
Here are some faqs which were given from the AWS for secrets-manager service and which will clear your doubts also.
Here is the article which you can refer to for implementing secure secrets storage for .net core with AWS Secret Manager
I want to secure my secret variables for my django project, which is deployed on AWS Elastic Beanstalk.
I've seen others use environment variables and am wondering if this is secure. Or, is it more secure to use KMS? Thanks!
Usually if you have secrets you would store them in AWS Systems Manager Parameter Store or AWS Secrets Manager.
Then, instead of hard-coding the secrets' values in your .ebextensions or environment variables you would pass references to the parameter or secret in either AWS Systems Manager Parameter Store or AWS Secrets Manager.
This means that in your application, e.g. .ebextensions, in you would need to add extra logic to obtained the actual values from the secrets as well as you would have to modify instance role used by EB with permissions to do so.
I am having properties file specific for dev, test and other environments. I have to store this files in some secure place in aws. I am using AWS Native tools for build and deployment. Please let me know how to store these files in aws
There are many ways to deal with a secret in case of AWS, but one thing is clear it depends on the service where you will use and consume these secret.
But you explore these two
The simplest way is to use the Environment variable.
AWS Secrets Manager
s3 ( for keeping files)
One common approach is to pass your secret as an environment variables, but in case of AWS I will recommend to go with AWS Secrets Manager
AWS Secrets Manager is an AWS service that makes it easier for you to
manage secrets. Secrets can be database credentials, passwords,
third-party API keys, and even arbitrary text. You can store and
control access to these secrets centrally by using the Secrets Manager
console, the Secrets Manager command line interface (CLI), or the
Secrets Manager API and SDKs.
Basic Secrets Manager Scenario
The following diagram illustrates the most basic scenario. It shows
how you can store credentials for a database in Secrets Manager, and
then use those credentials in an application that needs to access the
database.
Compliance with Standards
AWS Secrets Manager has undergone auditing for the these standards and can be part of your solution when you need to obtain compliance certification.
You can explore this article to read and write secret.
If you need to maintain files, not only object then you can store in s3 and pull files during deployment. but better to enable server-side encprtion.
But I will prefer secret manager instead of s3 and environment variable.
You can for s3 here and here
Bajjuri,
As Adil said in answer,
AWS Secret Manager -- if you want to store data as key, value pairs.
AWS S3 -- if you want to store files securely.
Adding to his answer, you can use AWS CodeDeploy Environment
Variables to fetch the files according to the your environment.
Let's say you've CodeDeploy deployment group for dev environment with
name "DEV" and deployment group for prod environment with name "PROD",
you can use this variable in bash script and call it in life cycle
hooks of appspec file to fetch the files or secret accordingly.
I've been using this technique in production for long and it works like a charm.
Our products are deployed on AWS.
We use a few 3rd party services like Sendgrid and Twillio.
I know in Heroku I can easily set my API KEYS in the dashboard and then access my NODEJS project like this
process.env.SENDGRID_KEY
How do I achieve the same in AWS?
Where can I put my keys and refer to that?
Parameter Store is used on AWS to store sensitive data such as API keys. You can store your secrets using the console and use the AWS SDK to fetch the values in your applications.
For NodeJs, you can either use Javascript SDK or aws-param-store module to manage parameters.
Remember to attach required IAM permissions to the application host (EC2 instance/lambda).
I'm currently using AWS S3 credentials inside my application's code in a file ignored by git, but every developer has that file so it can work with images.
I want to hide those credentials from the developers, but still have the ability to use S3 in the development environment.
What are the best practices on that?
Should I replace S3 usage to local files in the development environment?
Give each of your developers IAM accounts with their own API keys, set your application to read the API keys from environment variables rather than from a config file. When the code runs on EC2 instances, use IAM roles so that you don't need to use API keys at all. If you're using AWS SDKs it will use role credentials by default.