Set up separate secrets for our staging server. #4677
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
jfly
commented
Oct 2, 2019
| @@ -12,11 +12,14 @@ def self.get_username_and_repo_root(recipe) | |||
| end | |||
|
|
|||
| def self.get_secrets(recipe) | |||
| if recipe.node.chef_environment.start_with?("development") | |||
| if recipe.node.chef_environment == "development" | |||
There was a problem hiding this comment.
We used to have multiple kinds of development environments, but that is long gone, so I took this opportunity to simplify things.
Previously, we shared secrets between our staging and prod server, which is a bad idea for all sorts of reasons. One of the biggest issues we've run into is when our staging server started syncing our google group mailing lists based off of the contents of the staging database (thewca#4039). We shouldn't have even been running that job on our staging server, but even if someone *did* try to run it on our staging server, the server should not have had the api key necessary to talk to our gsuite account! This change is a step in the right direction, but isn't perfect: - There's still a single chef secret that the staging server must have access to. With that secret, it would still be possible to decrypt the prod secrets and access prod stuff. - We're using the same S3 IAM credentials for staging and prod right now. Ideally we'd create separate IAM users with only the permissions they need to access the staging/prod S3 buckets.
jfly
force-pushed
the
separate-secrets-for-staging
branch
from
2140dc0
to
2ec4d0b
Compare
|
Merged! I'm going to try spinning up a fresh staging server now. |
|
That did not quite work =( See #4680. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Previously, we shared secrets between our staging and prod server, which
is a bad idea for all sorts of reasons. One of the biggest issues we've
run into is when our staging server started syncing our google group
mailing lists based off of the contents of the staging database
(#4039). We
shouldn't have even been running that job on our staging server, but
even if someone did try to run it on our staging server, the server
should not have had the api key necessary to talk to our gsuite account!
This change is a step in the right direction, but isn't perfect:
access to. With that secret, it would still be possible to decrypt the
prod secrets and access prod stuff.
now. Ideally we'd create separate IAM users with only the permissions
they need to access the staging/prod S3 buckets.