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

delete ssh-private-key from yaml after processing #58

Closed
schaefi opened this issue Jul 6, 2018 · 4 comments
Closed

delete ssh-private-key from yaml after processing #58

schaefi opened this issue Jul 6, 2018 · 4 comments
Assignees
Labels
P1 Prio 1 indicates next issue to work on

Comments

@schaefi
Copy link
Collaborator

schaefi commented Jul 6, 2018

Once processed the ssh-private-key should be deleted from the yaml file. This imho can be done as part of the cleanup service

@schaefi schaefi changed the title delete ssh-private-key from yaml delete ssh-private-key from yaml after processing Jul 6, 2018
@schaefi
Copy link
Collaborator Author

schaefi commented Jul 6, 2018

alternative the key reading can be changed such that the key is not stored in the yaml file but as a file on the external location where the yaml file itself resides. The yaml file would then only contain a reference to that location.

@schaefi schaefi added the discussion Things still needs to be discussed label Jul 6, 2018
@schaefi
Copy link
Collaborator Author

schaefi commented Jul 9, 2018

So this is basically a question for @jeffaco

  1. do we want to handle the key as extra file on lun (or iso)
  2. do we want to handle the key as element in the config file

I would prefer 1.

@jeffaco
Copy link
Collaborator

jeffaco commented Jul 16, 2018

If I'm already creating a LUN with the YAML (or a DVD with the YAML), then it seems easy enough do provide the key as an extra file.

It shouldn't be any harder for me, and it eliminates the cleanup issue for you (copy the YAML, don't otherwise worry about it).

So my vote would be for 1 as well.

@schaefi
Copy link
Collaborator Author

schaefi commented Jul 17, 2018

👍 great I'll change the code to reflect this. Thanks

@schaefi schaefi added P1 Prio 1 indicates next issue to work on and removed discussion Things still needs to be discussed labels Jul 17, 2018
@schaefi schaefi self-assigned this Jul 17, 2018
schaefi added a commit that referenced this issue Jul 17, 2018
Instead of specifying a base64 encoded private ssh key
string as part of the key element in the config file,
we now just read a file path reference which is expected
to exist on the storage location from where the config
file was read. The referenced file is copied as the
ssh private key of the configured user. This sets the
config file free from any secret data and Fixes #58
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
P1 Prio 1 indicates next issue to work on
Projects
None yet
Development

No branches or pull requests

2 participants