Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Set up separate secrets for our staging server. #4677

Merged
merged 1 commit into from Oct 3, 2019

Conversation

@jfly
Copy link
Member

commented Oct 2, 2019

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:

  • 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 jfly requested a review from viroulep 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"

This comment has been minimized.

Copy link
@jfly

jfly Oct 2, 2019

Author Member

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
(#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 jfly force-pushed the jfly:separate-secrets-for-staging branch from 2140dc0 to 2ec4d0b Oct 3, 2019
Copy link
Member

left a comment

LGTM!

@jfly jfly merged commit 51d7053 into thewca:master Oct 3, 2019
2 checks passed
2 checks passed
continuous-integration/travis-ci/pr The Travis CI build passed
Details
coverage/coveralls Coverage remained the same at 95.947%
Details
@jfly jfly deleted the jfly:separate-secrets-for-staging branch Oct 3, 2019
@jfly

This comment has been minimized.

Copy link
Member Author

commented Oct 3, 2019

Merged! I'm going to try spinning up a fresh staging server now.

@jfly

This comment has been minimized.

Copy link
Member Author

commented Oct 3, 2019

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
Projects
None yet
2 participants
You can’t perform that action at this time.