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

Add practical use-case example #3

Open
C-Duv opened this issue Feb 25, 2018 · 5 comments
Open

Add practical use-case example #3

C-Duv opened this issue Feb 25, 2018 · 5 comments

Comments

@C-Duv
Copy link

C-Duv commented Feb 25, 2018

I like the GPG key based ACL of this tool and can see how it prevents leaks.

But I fail to imagine the real-world usage in a team of developers and I cannot find one in the documentation.

Is is something like:

  1. Alice, Bob and Charlie are working on a software source code versioned by git repository (and shared amongst them via GitHub, GitLab or any other central git repository).
  2. Alice want to store MySQL password into software's git repository but doesn't want neither Bob nor Charlie to have access to this secret.
    1. Alice creates a secrets directory into software's source code directory on it's computer, cd into it and run sy vault init to initialize the sheesy vault "secrets".
    2. Alice runs git add . ; git commit -m "Created a secrets sheesy vault" to commit the vault creation.
    3. Alice adds the MySQL password to the vault with: echo s3cre7 | sy vault add :mysql-password.
    4. Alice runs git add . ; git commit -m "Added MySQL password to the secrets vault"; git push origin for the changes the sy vault add command did on the sheesy vault ("secrets") are saved to the git repository.
  3. After some time, Alice trusts Bob to read secrets, so Alice asks Bob to run (on it's computer): cd secrets ; sy vault recipient init to add it's GPG key to possible recipients and git add . ; git commit -m "Adding Bob's key to the secrets vault" ; git push origin to persist the changes to the git repository.
  4. Alice can now run cd secrets ; sy vault recipient add 7DF95D5E and git add . ; git commit -m "Granting Bob's key access to secrets sheesy vault" ; git push origin and tells Bob that she granted him access to the "secrets" vault.
  5. Bob can now cd secrets and finally read the MySQL with sy vault show mysql-password.
  6. Charlie see the commits, see the list of secrets (using sy vault) but can never read them.

Notes:

  • I am intentionally omitting the parts where Alice, Bob and Charlie runs their git fetch and git merge commands.
  • On point 2., if Alice wants to store the password into software's git repository, could it be because software's deployment script will need it (in which case a other recipient should be added)?
@Byron
Copy link
Collaborator

Byron commented Feb 25, 2018

Wow, this example is downright fantastic! So great that I will indeed add this very example, including git interaction, to the documentation.
The usage you describe is exactly what is anticipated for sheesy, and it's correct that tooling (e.g. deployment scripts) will need access to the vault as well. For that there should be a practical example as well.

@C-Duv
Copy link
Author

C-Duv commented Feb 26, 2018

Glad to hear I got it right :)
Feel free to add the example (or do you want a PR?).

@Byron
Copy link
Collaborator

Byron commented Feb 26, 2018 via email

@C-Duv
Copy link
Author

C-Duv commented Mar 1, 2018

Well, on second thought, I think I'll leave you this part, I am not really sure I want to get into the documentation system (I initially thought it would be a simple patch to apply to an .md file).
But if you want deployment script example of the same spirit, I'll try to write some.

@Byron
Copy link
Collaborator

Byron commented Mar 2, 2018 via email

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

No branches or pull requests

2 participants