2
votes

We're trying to move some keys and secrets from .env to AWS Parameter Store for better security. We have two EC2 instances, one for production env and another one for staging env. Each instance has keys/values defined in .env file below public folder, so it's hidden from public access.

Keys in .env file are identical between production and staging env, just values are different. So the code to load these values were the same between production and staging. Now that we're trying to move these keys/values to AWS Paramter Store, and since Parameter Store is account level scope,

Is there a way to assign different values based on EC2 instance?

e.g.

secret = getSecretFromEnv('MY_KEY'); // different values are loaded depending on EC2 instance

has become (what we're trying to avoid doing)

if prod {
   secret = getSecureParameterFromAws('MY_PROD_KEY');
} else {
   secret = getSecureParameterFromAws('MY_STAGING_KEY');
}
1
The question is: "How does an instance know whether it is Production or Staging?" This could be based on a Tag, or perhaps the VPC it is in. Or do you have another way for the instance to "know" which environment it is in? - John Rotenstein
The problem is that code that is being written on staging will be deployed to production at some point, and since keys are unique per aws account meaning all instances share the same set of keys, the code has to differentiate environments to know which keys to use. Also developers working on staging instance can execute getSecureParameterFromAws('MY_PROD_KEY') to see what the values are on prod. - KoreanDude
My question is how the instances can "know" whether they are Production or Test, so that they can pull the right keys? You could, for example, add a tag to the instance. The instance could then retrieve its tag, and then request credentials associated with that tag. Or, they could be assigned different IAM permissions such that they have access to either Production or Test credentials, but not both. They could then attempt to retrieve both sets of credentials and then use the one that returns. The need is for some way of "knowing" their environment for this to happen. - John Rotenstein
Ah. Sorry. Now I understand. I totally overlooked the IAM section where they explained how to restrict params. So I pull env type from .env file and then retrieve parameters using SSM client. I still have to use different keys depending on the env type, but as long as the access to prod params from test env can be restricted, I think this is good enough. Thanks again. If you re-post your comment, I can select it as the answer. - KoreanDude

1 Answers

2
votes

There's two aspects here:

  • Knowing which environment to use
  • Restricting the environment that can be used

If the Production and Test systems are in separate AWS Accounts, then they can access parameters with the same key, since the values will be different.

If the systems are in the same AWS Account, then the code will need to know its own environment so that it requests the correct parameter (via a different key).

This information could be provided in a configuration file or, if both instances are identical, a Tag could be added to the instance. The code could check the tag on its own instance, and then retrieve the appropriate parameters.

This could be further enforced by restricting access to the parameters by assigning different IAM permissions to each instance. This way, the IAM Role is controlling which parameters they can access. The code could attempt to retrieve both parameters and then use whichever one was successfully returned, or the policy could simply be used to ensure that the right parameters are accessed.