k8s-ci-robot
commented
3 months ago This issue is currently awaiting triage.
SIG CLI takes a lead on issue triage for this repo, but any Kubernetes member can accept issues by applying the triage/accepted label.
The triage/accepted label can be added by org members by writing /triage accepted in a comment.
Instructions for interacting with me using PR comments are available [here](https://git.k8s.io/community/contributors/guide/pull-requests.md). If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes/test-infra](https://github.com/kubernetes/test-infra/issues/new?title=Prow%20issue:) repository.
mpuckett159
What would you like to be added:
When working with secrets using kubectl there are scenarios where you would like to view and edit the value of the secret in place as a string. Kubectl already includes a way to create secrets conveniently from files and other sources. It would be really convenient if it also included subcommands to view and edit secrets in place without having to do multiple extra steps with base64 encoding and decoding.
I don't have a very specific proposal for the design, but I think https://github.com/rajatjindal/kubectl-modify-secret is a fairly good implementation of this idea. If something similar could be integrated into kubectl then that would be useful.
Why is this needed:
Currently viewing and especially editing secrets is fairly inconvenient and error-prone, requiring piping together multiple commands that may or may not include subtle errors that break on things such as newlines in the secret value. This is especially problematic if you need to edit one part of the secret while keeping others intact (for example if the secret value contains JSON or another structured format). I can't say for sure how common such scenarios are in general, but it comes up somewhat often with the work that I do.
Having a well supported way to do this using kubectl itself without external tools would be preferable to external plugins given the sensitive nature of secrets. I don't think the kubectl-modify-secret plugin I linked beforehand is malicious, but I still feel a little uncomfortable giving this responsibility to a fairly unknown third-party plugin.