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

Provide a way to the validation key and data bag secret from S3 #237

Closed

Conversation

eherot
Copy link
Contributor

@eherot eherot commented Sep 17, 2014

No description provided.

@jeffbyrnes
Copy link

👍

1 similar comment
@atironati
Copy link

👍

@adamedx
Copy link

adamedx commented Sep 22, 2014

@jkeiser, can you take a look? This adds cloud bootstrap features for the following:

  1. Storing the validation key in the cloud's storage.
  2. Storing the databag secret in cloud storage.
    Does this seem to be a generically applicable use case across clouds?

@eherot, one concern I have is that the validation key is not encrypted and there's no guarantee access to the storage isn't wide open. This could be remedied with a separate knife ec2 configure validator that creates a key with narrow permissions for this purpose.

@adamedx
Copy link

adamedx commented Sep 22, 2014

@danielsdeleo, @mcquin, what do you think of the data bag feature here. Is this consistent with usage of the new data bag features of knife?

@eherot
Copy link
Contributor Author

eherot commented Sep 22, 2014

@adamedx as far as I'm concerned, security of the key is the responsibility of the uploader (who would also be setting the access policies). For us, requiring yet another key to decrypt the validation key would sort of defeat the purpose of this distribution model. We (and I suspect many other software services startups) already trust S3 with a great deal of our most sensitive data, so the idea of storing a plain-text private key there didn't seem like much of a leap.

@adamedx
Copy link

adamedx commented Sep 22, 2014

mostly agreed on security of key @eherot, but I'm wondering if we could add an additional subcommand to automate the uploading of the key so that it is has minimal accessibility. At a minimum, we should provide instructions for that (i.e. what's a good example command line for uploading the key, and the recommended permissions on the bucket, etc.).

Once you get into that territory though the next step is to automate.

@eherot
Copy link
Contributor Author

eherot commented Sep 22, 2014

@adamedx I'd be more in favor of simply updating the docs to describe the recommended permission sets to use. I'll go ahead and submit that change.

@jeffbyrnes
Copy link

@adamedx part of the trick here is that everyone does assigning permissions a bit differently, and we can only choose a single set of permissions to provide as part of said automation.

I'd agree with @eherot here and land on the side of good docs, which provide what you must create (if you have no permissions set) or add (if you do) to safely store the key in S3.

@adamedx
Copy link

adamedx commented Oct 5, 2014

@eherot, thank you very much for the contribution! We've rebased and merged this with #250.

@adamedx adamedx closed this Oct 5, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants