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

adding support for backing up and restoring of KeyVault secrets #3787

Closed
wants to merge 1 commit into from

Conversation

dragav
Copy link
Contributor

@dragav dragav commented Apr 17, 2017

Description


This checklist is used to make sure that common guidelines for a pull request are followed. You can find a more complete discussion of PowerShell cmdlet best practices here.

General Guidelines

  • Title of the pull request is clear and informative.
  • There are a small number of commits, each of which have an informative message. This means that previously merged commits do not appear in the history of the PR. For more information on cleaning up the commits in your PR, see this page.
  • The pull request does not introduce breaking changes (unless a major version change occurs in the assembly and module).

Testing Guidelines

  • Pull request includes test coverage for the included changes.
  • PowerShell scripts used in tests should do any necessary setup as part of the test or suite setup, and should not use hard-coded values for locations or existing resources.

Cmdlet Signature Guidelines

  • New cmdlets that make changes or have side effects should implement ShouldProcess and have SupportShouldProcess=true specified in the cmdlet attribute. You can find more information on ShouldProcess here.
  • Cmdlet specifies OutputType attribute if any output is produced - if the cmdlet produces no output, it should implement a PassThru parameter.

Cmdlet Parameter Guidelines

  • Parameter types should not expose types from the management library - complex parameter types should be defined in the module.
  • Complex parameter types are discouraged - a parameter type should be simple types as often as possible. If complex types are used, they should be shallow and easily creatable from a constructor or another cmdlet.
  • Cmdlet parameter sets should be mutually exclusive - each parameter set must have at least one mandatory parameter not in other parameter sets.

@msftclas
Copy link

@dragav,
Thanks for your contribution as a Microsoft full-time employee or intern. You do not need to sign a CLA.
Thanks,
Microsoft Pull Request Bot

@azuresdkci
Copy link

Can one of the admins verify this patch?

@markcowl markcowl changed the base branch from dev to preview April 19, 2017 17:00
OutputFile = GetDefaultFileForOperation("backup", VaultName, Name);
}

var filePath = ResolvePathFromFilename(OutputFile, throwOnPreExisting: true, errorMessage: KeyVaultProperties.Resources.BackupSecretFileAlreadyExists);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Two things:

(1) You should be using AzureSession.DataStore when interacting with the file system (checking for existence and the like), as this is mockable in tests
(2) The normal standrad would be to prompt for overwite if the file exists, which would mena having a ShouldContinue prompt asking if the user wants to overwrite and a Force parameter. Is there a reason why you wouldn't want to allow the user to overwrite the file?

[Cmdlet( VerbsData.Backup, "AzureKeyVaultSecret",
SupportsShouldProcess = true,
HelpUri = Constants.KeyVaultHelpUri )]
[OutputType( typeof( String ) )]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure the OutputType is useful. You should probably return nothing and implement a passthrough parameter so you can return true/false for success / failure

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The output of this cmdlet is the file path of the newly generated backup file.

{
#region Input Parameter Definitions

/// <summary>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You should consider having an alternate parameter set that takes a KeyVaultSecret so that users can more easily pipe get-AzureKeyVaultSecret to this cmdlet.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't quite see the value of this scenario - the piped-in object would only serve to extract the identifier, as that's what the server expects. The service must find/load/encrypt the object before creating a backup - the client can't upload an object to be backed up.

Another thing to consider is that the secret can be retrieved by id (ie a specific version) whereas the backup acts on the entire family (head secret + all versions). I'm concerned that the user expectation (on passing in a specific secret object) will be that an individual backup of that object will be generated.


private string ResolvePath( string filePath )
{
FileInfo secretFile = new FileInfo(this.GetUnresolvedProviderPathFromPSPath(filePath));
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please use the data store, as outlined above

[Cmdlet( VerbsData.Restore, "AzureKeyVaultSecret",
SupportsShouldProcess = true,
HelpUri = Constants.KeyVaultHelpUri )]
[OutputType( typeof( Secret ) )]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It looks like you are returnign the secret FullName, isn't that a string?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Restore returns the newly reinstated secret (or key, for existing cmdlets). It is similar in that sense with the Get command.

Position = 1,
HelpMessage = "Input file. The input file containing the backed-up blob" )]
[ValidateNotNullOrEmpty]
public string InputFile { get; set; }
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would be nice to take a list of files in this parameter, and process each one

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will add this to the backlog for a future release :)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds good, this would be a non-breaking change

@markcowl markcowl assigned dragav and unassigned markcowl Apr 21, 2017
@dragav dragav requested a review from amitbapat April 22, 2017 00:49
@cormacpayne
Copy link
Member

@dragav please pull the latest changes from the preview branch - these changes remove dll-Help.xml files from the repository, so you will no longer need to update this file in your PR

@dragav dragav closed this Apr 27, 2017
@dragav
Copy link
Contributor Author

dragav commented Apr 27, 2017

Addressed feedback and ported these changes to the corresponding preview branch. Will resubmit the PR shortly.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants