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

show-physical backup (aws): extract devices encryption keys #1080

Closed
wants to merge 2 commits into from

Conversation

PsyanticY
Copy link
Contributor

In general we use nixops show-physical -d test backup xxxxxxx to get the mapping between the devices and the snapshots then we use the output to deploy a new env using these snapshot, but when using encrypted volumes, another manually (and tedious) steps to extract and put the keys in that file is needed.
This pr Aims to include that automatically.
Not sure if this can be considered bad practice from security perspective but since the keys are already in the state file and we are just extracting and formatting them, i don't think thats an issue.
Tested this with non encrypted and encrypted volumes created as separate/non separate resources.

@PsyanticY PsyanticY closed this Jan 17, 2019
@PsyanticY PsyanticY deleted the exporting_backups branch January 17, 2019 11:01
@PsyanticY PsyanticY restored the exporting_backups branch January 17, 2019 11:02
@PsyanticY PsyanticY reopened this Jan 17, 2019
@PsyanticY
Copy link
Contributor Author

@AmineChikhaoui Addressed the concerns you raised. The key is now stored with the snapshot each time a backup operations run. Also added backward compatibility that i think should be removed after some a release or so.

@PsyanticY
Copy link
Contributor Author

@edolstra Any thoughts on this.

@tewfik-ghariani
Copy link
Contributor

Any updates regarding this?

@grahamc
Copy link
Member

grahamc commented Mar 26, 2020

Hello!

Thank you for this PR.

In the past several months, some major changes have taken place in
NixOps:

  1. Backends have been removed, preferring a plugin-based architecture.
    Here are some of them:

  2. NixOps Core has been updated to be Python 3 only, and at the
    same time, MyPy type hints have been added and are now strictly
    required during CI.

This is all accumulating in to what I hope will be a NixOps 2.0
release
. There is a tracking issue for that:
#1242 . It is possible that
more core changes will be made to NixOps for this release, with a
focus on simplifying NixOps core and making it easier to use and work
on.

My hope is that by adding types and more thorough automated testing,
it will be easier for contributors to make improvements, and for
contributions like this one to merge in the future.

However, because of the major changes, it has become likely that this
PR cannot merge right now as it is. The backlog of now-unmergable PRs
makes it hard to see which ones are being kept up to date.

If you would like to see this merge, please bring it up to date with
master and reopen it
. If the or mypy type checking fails, please
correct any issues and then reopen it. I will be looking primarily at
open PRs whose tests are all green.

Thank you again for the work you've done here, I am sorry to be
closing it now.

Graham

@grahamc grahamc closed this Mar 26, 2020
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.

None yet

3 participants