Removes the risk of sending decrypted EJSON secrets to output. #431
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
NB: This addresses a security issue with application secrets
What are you trying to accomplish with this PR?
Presently, if a 'kubectl apply' fails when updating EJSON secrets, it's
possible that the decrypted secrets payload can be output as part of the
error message.
This should be avoided since it can expose all secrets of your application.
For e.g, GKE had an incident on February 26th which caused
intermittent errors when calling
kubectl
. We happened to see a failureat the step when secrets are updated. Because
kubectl apply
failed, theexception was bubbled up and logged to output.
How is this accomplished?
This change takes a simple approach by not including the error message in
commands where it is possible to display the payload. The 'Kubectl' class
does not log messages if the sensitive flag is set to true, however the
EjsonSecretProvisioner class raises EjsonSecretError which is logged
further up the stack.
What could go wrong?
The error that is displayed is generic and will not show specific error information
returned from
kubectl
. This might be problematic.We would like some feedback on this PR specifically whether this is the best approach.
Either way, this addresses a significant security risk that should be looked at ASAP.
Pinging @dturn on the advice of a colleague who formerly worked at Shopify.